2.5 流动效率与在制品

概述与动机

流动效率是一份工作中活跃时间占总时间的比例：如果一次变更总共花了十个小时被主动编码、评审和测试，但在整个旅程中，累计在队列里闲置了九十个小时，流动效率就是10%。据诚实测算，大多数软件交付流水线的流动效率落在10%到25%之间，这让期待努力占主导的人感到意外。大多数交付系统中最主要的成本，不是一项工作完成需要多久，而是它要等多久才能开始。

在制品（WIP）是在任意时刻，一个团队或一个系统中正被主动处理的项目数量，与主题 2.4 所称的”流动负载”是同一个量。本主题背后这个违反直觉的发现，由几十年运营管理研究支持，并通过看板和排队论为软件交付正式化，是限制在制品往往会提高吞吐量，而不是降低它，因为同时在制的工作越少，上下文切换就越少，队列就越短，每一项的完成也就越快，尽管感觉上同时做的事情更少，总产出理应更少才对。

对大团队而言，理解流动效率，会把几乎每一个交付问题的框架，从”人们需要更快地工作”重新构造为”工作需要减少等待”。这种重新构造很重要，因为前一种框架招致对个人的压力，正是主题 2.6 所警告的陷阱，而后一种框架招致对排队结构、评审容量，以及同时启动多少工作的调查，而真正、可持续的改善往往就在那里。同时应付许多并行计划、共用同一批团队的企业组织，特别容易出现高在制品和低流动效率，因为启动新工作总感觉像是进展，即便它正在悄悄拖慢所有已经在制的工作。

核心原则

等待时间，而不是主动的努力，主导着大多数交付流水线。 低于25%的流动效率是典型情况，而不是团队出问题的迹象。
限制在制品往往会提高吞吐量，而不是降低它，方法是减少上下文切换、缩短队列。
启动新工作感觉像是进展；完成工作才是真正交付价值的事情。 这两者不是一回事，而组织经常把它们混为一谈。
高在制品在被测量之前往往是不可见的。 一个团队同时应付的并行工作，可能远远超过任何一个人单独意识到的程度。
这是一个系统层面的指标，而不是个人层面的。 把在制品限制用来惩罚个人，误解了这项技术的全部意义。

建议

在假定努力是瓶颈之前，先测量流动效率

用主题 2.6 的周期时间阶段数据，为近期一批有代表性的变更，计算活跃时间与总耗时之比。大多数首次测量这一点的团队，都对这个数字之低感到惊讶，而这种惊讶本身就有价值：它把注意力从”更努力工作”重新引导到”减少排队”，而后者几乎总是更有成效的杠杆。

设定一个明确的在制品限制，并可见地执行它

对一个团队或个人在同一时间能主动处于进行中的项目数量设定上限，并在一块共享看板上可见（物理或数字看板是经典实现）。当达到限制时，团队接下来的行动，是帮忙完成一些已经在制的工作，而不是启动新工作。这项借鉴自精益制造、并由看板方法正式化的单一实践，是软件团队所能获得的最持续有效的流动改善之一，而且实施起来几乎不花钱。

把在制品限制当作系统约束，而不是个人配额

在制品限制管理的是系统（一个团队、一个共享评审队列、一个共享环境）同时在制的工作量，而不是任何一个人被允许触碰多少工作。把这个限制应用为一项个人绩效配额（“你只能同时打开两个工单”）误用了这项技术，并冒着本书通篇警告的那种个人层面操纵的风险。这个限制的存在，是为了保护整个系统的流动，其执行应当是一种团队规范，而不是一个个人上限。

调查工作为什么闲置，而不只是闲置了多久

当流动效率分析揭示出较长的等待时间时，具体地问一问为什么：是因为评审者不可用，还是因为共享测试环境已被占用，还是因为对另一个团队的依赖尚未落地。每一种原因都指向不同的修复方案。没有这种具体调查的笼统”减少等待时间”指令，往往产出笼统、无效的应对。

留意初步改善之后在制品悄悄回升

成功采纳在制品限制的团队，常常看到它随着时间推移，因启动新计划的压力回归而被侵蚀（“就这一次，我们也需要启动这件紧急的事”）。把每一次在制品限制例外，都当作一次刻意、可见、带有明确理由的决定来对待，而不是一次悄悄的、例行的覆盖，这样这项限制的自律就不会在无人刻意决定的情况下悄悄退回原状。

权衡取舍：利与弊

方案	优点	缺点
没有在制品限制	感觉灵活；启动新工作时没有摩擦	上下文切换和排队悄悄拖慢一切
团队层面的在制品限制	可衡量地改善吞吐量与流动效率	需要自律来执行，尤其在截止日期压力下
个人层面的在制品配额	表述简单	误用了这项技术；冒着个人操纵的风险
严格、不留余地的在制品限制	流动效率收益最大	在真正紧急、例外的情况下可能显得僵化

核心张力是灵活性与流动之间的张力。每当感觉紧急时就启动新工作，感觉上很有响应力，但流动效率与在制品研究一致表明，这种灵活性是以快速完成任何事情为代价的，因为更多的并行工作，意味着所有已在制工作的队列更长、上下文切换更多。解决之道是默认采纳团队层面的在制品限制，为真正的紧急情况设置一个刻意、可见、罕见的例外流程，而不是采取要么严格不留余地、要么无限制的自由放任。

与团队讨论的问题

从真实的周期时间数据计算，我们实际的流动效率是多少，这个数字让我们感到意外吗？ 大多数团队从未计算过这一点，并假定它比实际结果高得多。在讨论本主题其他内容之前，先拉出一批近期变更，诚实地计算这个比率。
我们现在整个团队实际有多少在制品，在计数之前有人知道这个数字吗？ 高在制品往往在被明确测量之前不可见，因为每个人只看到自己那一小块。数一数当前所有进行中的工作，包括今天没人在主动触碰的工作。
如果我们采纳一个在制品限制，我们对新的紧急请求的应对方式需要发生什么变化？ 这个问题揭示出在制品限制旨在打断的那个真正的组织习惯：条件反射式地启动新工作，值得在尝试执行限制之前，而不是之后，进行讨论。
当工作在我们的流水线中闲置时，具体原因是什么，每次都是同一个原因吗？ 一种”事情就是会等来等去”的笼统感觉，不如一个具体、反复出现的原因有用：一位不可用的评审者、一个已被占用的共享环境、一项跨团队依赖。从真实的近期例子中，说出实际的模式。
我们是否曾采纳过一个在制品限制，然后眼看着它通过例外悄悄侵蚀？ 这种情况极其常见，值得诚实讨论：是什么压力造成了第一次例外，这些例外是否在无人明确决定的情况下，变成了新的常态。
在我们的情境下，在制品限制需要应用在个人、团队，还是共享资源（比如一个评审队列或测试环境）层面？ 不同的瓶颈需要在不同层面设限，而在错误的层面应用限制（个人配额而不是共享队列上限）可能误用整项技术。

行业视角

初创公司。 人少的时候，在制品往往自然就低，仅仅因为没有足够的工程师能同时启动太多工作。风险在于相反的方向：创始人或首席工程师个人同时应付的并行计划，远超他们自己的意识，这即便没有正式的看板工具，也值得测量。

小型企业。 一块简单可见的看板（物理的或基础的数字工具），配合一个明确的列限制，就足以获得大部分好处，无需投资于复杂的流动指标工具。从一个宽松的限制开始，随着团队适应这门自律逐渐收紧。

企业。 高在制品在这里尤其常见，也尤其代价高昂，因为许多并行战略计划争夺同一批共享工程能力，而对赞助人而言，启动一个新计划总看起来像是进展。让在制品在投资组合层面可见，而不只是团队层面，这样领导层就能在再启动一项计划之前，看清尚未完成的那些计划所付出的代价。

政府。 多年期项目常常在许多工作流中积累起巨大的隐性在制品，每一条单独看都合理，却没有对总量的全组织可见性。即便只是非正式地引入投资组合层面的在制品可见性，往往也是为排列工作顺序而不是全部并行运行所能提供的最有说服力的单一论据，因为一旦被测量，高在制品的流动效率成本就会明显地累积。

案例

企业。 一家金融服务公司的平台团队，只用十二名工程师同时应付十八项并行计划，这个在制品与容量之比，直到一位新任工程总监直接索要数据之前，从未被真正计算过。团队工作的流动效率测得不到12%。该团队采纳了一个明确的在制品限制：每两名工程师一项活跃计划，刻意暂停了若干较低优先级的计划，而不是继续把容量摊薄。以每季度真正完成的计划数衡量的吞吐量，在两个季度内翻了一倍多，尽管在任何给定时刻，团队看起来明显”做得更少”。

政府。 一家国家基础设施机构的数字化转型项目，在其投资组合中积累了超过四十条并行工作流，每一条都有自己的赞助人和自己的理由，却没有对总在制品的单一视图。一次项目层面的流动效率审查发现，中位数工作流只把不到15%的耗时花在主动开发上，其余时间都在等待共享资源：一个小型中央架构评审团队、一个共享测试环境，以及跨机构签核。该项目引入了明确的投资组合层面在制品限制，排列工作流顺序，而不是让全部四十条并行运行，该机构自己的跟踪数据显示，保持活跃的工作流完成得明显更快，即便同时运行的总数大幅下降。

商业理由：动机、投资回报与总拥有成本

刻意管理流动效率与在制品的回报，是违反直觉但有充分文档记录的：当一个组织同时做得更少时，吞吐量往往会上升，而不是下降，因为更少的上下文切换和更短的队列，意味着每一份单独的工作完成得更快。上面的金融服务案例，通过刻意减少并行工作使吞吐量翻倍，是一旦组织真正测量并依据流动效率采取行动、而不是假定更多并行工作总意味着更多进展之后，常见的模式。

采纳这门自律的总成本主要是组织层面的，而不是技术层面的：一块可见的看板、一个达成一致的在制品限制，以及在达到限制时拒绝启动新工作的自律。这门自律维持起来比采纳它更难，这正是为什么上文”留意在制品悄悄回升”这条建议，与最初的采纳本身同样重要。

反模式与陷阱

未经测量流动效率就假定主动努力主导交付时间： 通常是错的，它把改善的努力误导向了错误的杠杆。
把在制品限制应用为个人配额，而不是系统约束： 误用了这项技术，冒着个人操纵的风险。
条件反射式地启动新工作，因为感觉像是进展： 正是流动效率和在制品限制旨在打断的核心习惯。
让在制品限制的例外变得例行、不可见： 在无人刻意决定的情况下，把这门自律悄悄侵蚀回原状。
只在团队层面测量在制品，错过投资组合层面的超负荷： 在运营许多并行战略计划的大型组织中很常见。
把一个低流动效率数字当作团队不好的迹象： 这对大多数交付流水线而言是典型情况，是调查的起点，而不是一个定论。

成熟度模型

第一级，启动： 在制品不被跟踪；团队条件反射式地启动新工作，对总的并行负荷没有可见性。
第二级，发展： 部分团队使用一块非正式的看板，但在制品限制没有被一致执行，流动效率也从未被计算过。
第三级，标准化： 团队在系统层面拥有明确、可见的在制品限制，流动效率定期从真实的周期时间数据中测量。
第四级，管理： 在制品限制的例外被作为刻意、可见的决定来跟踪；流动效率被监控是否随时间侵蚀，一旦下降就被调查。
第五级，协奏： 在制品在投资组合层面而不只是团队层面可见并被管理，组织能够指出因刻意减少并行工作而带来的具体吞吐量改善。

讨论思路

从真实数据诚实计算，我们实际的流动效率是多少？
在这次讨论之前，我们目前有多少在制品是从未被计数过的？
为了执行一个真正的在制品限制，我们需要对什么说不？
我们流水线中工作闲置最常见的单一原因是什么？
在我们组织中，投资组合层面的在制品在哪里是不可见的、也可能太高了？

要点回顾

流动效率，即活跃时间占总时间的比例，在真实交付流水线中通常低于25%；等待时间，而不是努力，占主导。
限制在制品往往会提高吞吐量，而不是降低它，方法是减少上下文切换、缩短队列。
把在制品限制应用为系统约束，绝不作为个人配额。
调查工作闲置的具体原因，而不是发布一条笼统的”减少等待时间”指令。
留意在制品限制通过例行例外而被侵蚀；把每一次例外都当作一次刻意、可见的决定。
主题 2.4 把这个量称为流动负载，主题 2.7 将这种关系正式化为利特尔法则：对任何稳定队列而言，在制品等于到达率乘以周期时间。

参考文献与延伸阅读

The Principles of Product Development Flow，Donald G. Reinertsen著（产品开发中的排队论、批量大小与在制品限制）。
Kanban: Successful Evolutionary Change for Your Technology Business，David J. Anderson著（软件团队在制品限制与流动的奠基性文本）。
Actionable Agile Metrics for Predictability，Daniel S. Vacanti著（流动效率测量与基于流动的预测）。
The Goal，Eliyahu M. Goldratt著（约束理论，以及局部忙碌与系统吞吐量之间违反直觉的关系）。