重要的是结果，而非过程、管理，或者你完成了哪些工作。

我缓缓点头，不上她的当。“我期待你提出的任何建议，莎拉。

流程是用来保护人的。我们得想出保护布伦特的办法。

你在把布伦特的工作标准化，让其他人能够执行。而且，因为你最终把那些步骤记录下来了，所以能在一定程度上保证稳定性和质量。你不仅减少了需要布伦特的工作中心数量，还生成了一些将来能够让其中一些工作中心自动化运行的文档。

凤凰似乎会随机丢失交易，而在其他情况下，它又会从客户信用卡上划走两倍乃至三倍的费用。

独坐此身缚吾力本可平众怒奈何众顽愚

除了前置时间和处理时间外，技术价值流中的第三个关键指标是完成时间和精确的总花费时间的百分比（%C/A）

对于‘复杂的中等变更’，我们决定，变更提交者有责任向可能受到影响的人员进行咨询并得到其认可。做完这些之后，他们就可以把变更卡片交给我们审核并安排操作日程。”

所谓一场不协调的婚姻，是假定业务部门和IT部门是两个分离的实体。IT要么融入到公司的日常运行之中，要么融入到公司的业务内容之中。瞧！就是这样。没有矛盾，没有婚姻，也许连IT部门也没有

布伦特看起来确实是在真心诚意地帮助所有依靠IT系统的人解决问题。但让我失望的是，大家似乎都把他当作免费的私人极客电脑特工。这是以损害凤凰项目为代价的。

四类工作中的三类：业务项目，内部项目，以及变更

那张图表显示的是，每个人都需要空闲时间，或者说松弛时间。如果大家都没有松弛时间，半成品就会卡在系统里。或者更确切地说，卡在队列里，只是干等着

但是技术工作者很容易被打断，因为对所有人而言，这个中断的后果似乎是不可见的，即便它对生产效率的影响比制造业更甚。例如，将一个工程师同时分配到多个项目里，他不得不在多个任务、认知规则和目标之间来回切换，付出重新进入角色的成本。

在发射的当口，他们还在往太空飞船上安装零件，这可不是个好兆头。

第一步帮助我们理解在工作从开发部移向IT运维部时该如何建立快速工作流，因为那就是业务部门与客户之间的衔接。第二步告诉我们如何缩短及放大反馈环路，从而在源头上解决质量问题，避免返工。第三步告诉我们如何建立一种文化，既能鼓励探索、从失败中吸取教训，又能理解反复实践是精通工作的先决条件。

也许你认为，有了订单输入系统和库存管理系统中的数据，我们就能做到这一点。但其实不能，因为数据几乎总是错的。

这里有一系列的命令：只可对上抱怨，不许对下牢骚。

我们的目标是提高整个系统的生产能力，不只是提高任务的完成数量

业务敏捷度并不单看生产的净速度，而是要看你捕捉和适应市场变化并为此承担更大风险的能力

在任何价值流中，总是有一个流动方向、一个约束点，任何不针对此约束点而做的优化都是假象。