2.4 流动时间与流动负载

概述与动机

流动时间是从一个流动项（主题 2.2）进入价值流到被交付为止的总耗时，衡量的是从识别出一个业务需求到客户获得价值的整条路径上的响应速度。流动负载是在任意时刻，价值流中当前处于活跃或等待状态的流动项总数，这是流动框架对主题 2.5 所称”在制品”的叫法。这两者是流动框架中与排队数学关系最直接的两个指标，因为流动负载不只是与流动时间相关，它在数学上决定了流动时间。

这种关系就是利特尔法则，一个来自排队论的证明（主题 2.7 完整涵盖），指出一个稳定系统中项目的平均数量，等于平均到达率乘以每个项目在系统中所花的平均时间。应用到这里：流动负载等于到达率乘以流动时间。这是本主题中最有用的一个事实，因为它把一个过去只能定性的论点（“我们负荷过重了，事情花的时间太长了”），变成了一个可证明的、定量的论点，一个业务负责人不能轻易驳回：如果流动负载持续上升，而到达率保持平稳，流动时间在数学上必然也会上升，而不只是可能上升。

对大团队而言，这往往是整个框架中最具说服力的单一数字。一位因为每个请求单独看都显得合理，而抗拒对新工作说不这个想法的业务负责人，一旦流动负载被跟踪、且它与流动时间的关系被直接展示而不是抽象地论证，往往就会接受这样一个事实：让一条价值流超负荷，可以证明地拖慢了其中已有的每一个项目。同时应对许多并行战略计划的企业组织，以及运营着几十条并行工作流的政府项目，都依赖这个证明本身，而不仅仅是其背后的直觉，来为拒绝同时启动更多工作提供理由。

核心原则

流动负载通过利特尔法则，在数学上决定流动时间。 这不是相关性；这是一个对任何稳定价值流都成立的证明。
流动时间跨越整条价值流，而不只是工程环节。 它从一个业务需求被识别的那一刻开始，而不是从工程接手工作的那一刻开始，主题 2.6 的周期时间随后会对此进一步分解。
上升的流动负载是流动时间上升最早的预警信号。 因为这种关系是可证明的，流动负载可以被当作一个领先指标来观察，而不只是在流动时间已经恶化之后才被发现。
价值流的入口点必须是固定且有文档记录的。 流动时间计时从哪里开始，是一个定义性的选择，与本书中任何其他指标边界一样，暴露在同样的操纵风险之下。
业务负责人可以直接对流动负载采取行动。 与作为滞后衡量的流动时间不同，流动负载是一个杠杆：拒绝启动新工作，是今天就能采取的行动。

建议

在衡量流动时间之前，先固定并记录价值流的入口点

明确决定流动时间是从一个业务需求首次被识别开始，还是从它被正式批准开始，还是从工程开始工作开始，并按主题 1.4 为任何指标章程所建议的方式记录这一选择。这一个决定，决定了流动时间衡量的是真正的端到端响应速度，还是仅仅是工程所掌控的那个更窄的切片，而之后未经披露就改变定义，正是本主题核心的操纵风险。

持续跟踪流动负载，而不是周期性地跟踪

因为流动负载通过利特尔法则，是尚未到来的流动时间的领先指标，所以要把它当作一个实时、持续更新的数字来跟踪，而不是一份周期性快照。一个已经攀升了数周才被人查看的流动负载，早已在同样长的时间里，在这个指标追上之前，悄悄地、无形地延长着流动时间。

在为在制品限制或增加容量辩护时，明确使用利特尔法则

在为减少并行工作、或增加容量提出理由时，展示实际的方程式，而不只是建议本身：流动负载等于到达率乘以流动时间，所以如果到达率大致固定，减少流动负载在数学上必然会减少流动时间。相比一句未经量化的”我们太忙了”，这对一个持怀疑态度的利益相关方而言，是一个实质上更有力的论点，因为它是可证明的，而不是断言的。

在提出修复方案之前，把流动时间与流动负载背后的原因分开

当流动负载偏高时，调查究竟是哪种流动项类型（主题 2.2）在驱动它：是同时启动了太多并行功能、一批未处理的缺陷积压，还是卡在等待一次共享审批的风险工作。每一种原因都指向不同的修复方案，把”流动负载偏高”当作一个单一、未加区分的问题来对待，往往会产出一个笼统、无效的应对。

用周期时间交叉核实流动时间，以定位延迟真正发生的位置

由于流动时间跨越整条价值流，而周期时间（主题 2.6）只涵盖其中的工程部分，直接比较两者。流动时间与周期时间之间的巨大差距，意味着大部分延迟发生在工程甚至见到这份工作之前，存在于审批队列、优先级排序待办事项，或团队之间的交接之中，这指向一种与延迟集中在工程内部时截然不同的修复方案。

权衡取舍：利与弊

方案	优点	缺点
只从工程接手开始衡量流动时间	简单，与现有周期时间埋点相符	错过工程之前的延迟，低估真实响应速度
从真正的业务需求识别开始衡量流动时间	捕捉真正的端到端响应速度	需要为工程直接掌控之外的阶段埋点
周期性的流动负载快照	偶尔计算成本低	错过领先指标的价值；上升的负载可能太久无人察觉
持续的流动负载跟踪	实时、可行动的领先指标	需要持续的工具集成，而不只是偶尔的报告

核心张力是范围与埋点覆盖能力之间的张力。只从工程接手开始衡量流动时间要容易埋点得多，因为它复用了主题 2.6 已经收集的周期时间数据，但它通过忽略工程见到工作之前发生的一切，悄悄低估了真正的响应速度。解决之道是：如果今天只能埋点这个范围，就先从更窄的、工程范围内的衡量开始，但要把把流动时间的起点向上游延伸（延伸到业务需求识别和优先级排序）当作一项近期优先事项，而不是一种永久性的局限。

与团队讨论的问题

我们的流动时间计时今天究竟从哪里开始，组织中的每个人都同意这是正确的起点吗？ 利益相关方假定计时从哪里开始，与它实际从哪里开始之间的错配，是这个指标不受信任的一个常见、悄然存在的根源。确认文档化的定义与共享的理解相符。
我们是否曾检查过我们所衡量的流动负载、到达率与流动时间是否真的满足利特尔法则？ 如果它们大致不平衡，说明三个数字中有一个正被不一致地衡量。一起走一遍实际数字，而不要假定这项检查会通过。
流动负载是被持续跟踪的，还是一次稳定的上升可能会在数周内无人察觉？ 一个领先指标，只有在真的有人近乎实时地关注它时才能保护你，而不只是在季度报告中审查它。
当流动负载上升时，我们能说出是哪种流动项类型在真正驱动它，还是它只表现为一个未加区分的数字？ 一个笼统的”我们负荷过重了”诊断，会产出一个笼统的、往往无效的应对。检查一下你目前的埋点是否真的能把上升的负载归因于一个具体的原因。
我们的流动时间与周期时间之间的差距有多大，这个差距暗示大部分延迟发生在工程见到工作之前还是之后？ 这种比较，往往揭示出改进的最大机会完全存在于工程自身掌控之外。
是否有人曾悄悄收窄我们流动时间的起点、让数字看起来更好看，而这个变化未经记录或披露？ 这正是本主题核心操纵风险的直接陈述。诚实地问一问，你们的定义是否曾以这种方式漂移过。

行业视角

初创公司。 流动负载通常较低，仅仅是因为没有足够的人手同时启动太多工作，但一旦创始人或首席工程师成为许多并行计划的个人瓶颈，同样的数学关系依然成立。即便没有专门的工具，也要非正式地跟踪流动负载，因为利特尔法则无论规模大小都成立。

小型企业。 一份简单、共享的当前所有活跃事项清单，通常足以计算流动负载，无需专门的价值流管理软件。有用的习惯，是足够频繁地检查它，以便及早发现上升的数字，而不是等到流动时间已经明显恶化之后才发现。

企业。 这正是利特尔法则作为一种论证手段（而不仅仅是一个指标）发挥价值的地方：一个同时应付几十项并行战略计划的大型组织，可以用流动负载与流动时间之间可证明的关系，为排列工作顺序提出一个基于证据的理由，而这是一句纯粹定性的”我们太忙了”在面对坚定的利益相关方压力时很少能做到的。

政府。 多年期项目常常在许多工作流中积累起庞大、隐性的流动负载，每一条工作流单独看都合理，却没有对总量的全组织可见性。直接展示利特尔法则，展示项目自身流动时间的增长可以用其自身不断上升的流动负载在数学上完全解释，往往是为排列工作流顺序、而不是无限期地并行运行所有工作流，所能提供的最清晰、最有说服力的证据。

案例

企业。 一家媒体技术公司的平台组织，正在同时运行二十二项战略计划，而其容量现实上只能支撑大约十二项，这种错配，直到一位新任工程副总裁直接索要流动负载数据，才第一次被量化。中位数计划的流动时间在前一年增长了40%，领导层曾将这一趋势归因于”工作变难了”。把利特尔法则与实际的流动负载和到达率数字并列展示，显示这种增长完全可以由不断上升的流动负载单独解释，而无需假定底层工作难度有任何变化。该组织把计划排序削减到一个可持续的流动负载，两个季度内，中位数流动时间下降了近三分之一。

政府。 一家联邦补助金管理机构的现代化项目，在几十条并行工作流中积累了流动负载，却没有任何单一的跟踪总量，每条工作流的发起人都认为自己的计划在单独考虑时资源是合理的。一次使用利特尔法则的项目办公室分析显示，该项目的汇总流动时间（从一条工作流获批到交付的时间）几乎完全可以单凭其汇总流动负载预测出来，这一发现说服了一年多来一直抵制降低优先级论点的发起人们。该项目随后采纳了一个明确的流动负载上限，新的工作流现在会进入一个队列，而不是无论当前负载如何都立即启动。

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

一起跟踪流动负载与流动时间的回报，是为排列工作顺序而不是把一切都并行运行，提供一个可证明、而不仅仅是有说服力的理由。上面的媒体技术案例，仅凭流动负载就解释了整个流动时间的倒退，正是这种组合稳定产出的模式：一个具体的、定量的论点，在一句”太忙了”的定性诉求，此前在面对要求启动更多工作的真实组织压力时失败的地方，取得了成功。

相对于其说服力，总拥有成本很低：流动负载只需要一个对活跃和等待项目的实时计数，而流动时间需要为价值流的入口点埋点，这项工作在它第一次阻止组织承诺超出其实际容量所能支撑的并行计划数量时，就已经收回了成本。

反模式与陷阱

悄悄收窄流动时间起点以美化数字： 本主题核心的操纵向量。把计时起点从真正的业务需求识别，移到一个更晚的点（工程接手、正式批准），会在完全不改变真正响应速度的情况下缩小流动时间，而且这可以逐渐发生，缓慢到没有任何一次单独的变更看起来像是刻意的操纵。护栏是在指标章程（主题 1.4）中明确记录入口点，并定期依据文档化的定义对其进行审计，这正是本书对每一个指标边界都要求的同一门自律。
只周期性地衡量流动负载： 放弃了它作为领先指标的价值，因为一次稳定的上升可能数周无人察觉。
把流动负载当作一个未加区分的单一数字： 错过了究竟是哪种流动项类型在真正驱动超负荷，产出一个笼统而非有针对性的应对。
忽视流动时间与周期时间之间的差距： 错过了延迟究竟集中在工程之前还是之后，而这暗示着截然不同的修复方案。
在没有明确展示利特尔法则的情况下主张减少并行工作： 一个利益相关方驳回一句定性诉求，要比驳回一个定量的、可证明的关系容易得多。
假定利特尔法则只在大规模下适用： 它对任何稳定系统都成立，无论规模大小，包括一个超负荷的个人。

成熟度模型

第一级，启动： 流动时间和流动负载都不被跟踪；延迟只是被轶事性地讨论，没有支持数据。
第二级，发展： 流动时间只从工程接手开始跟踪，流动负载被周期性地检查，而不是持续检查。
第三级，标准化： 流动时间从一个有文档记录的、全组织的价值流入口点开始衡量，流动负载作为领先指标被持续跟踪。
第四级，管理： 利特尔法则被明确用来证明容量和排序决策的合理性，上升的流动负载在提出修复方案之前会被归因于一种具体的流动项类型。
第五级，协奏： 组织在其各条价值流上设定明确的流动负载上限，并能指出由利特尔法则支撑、可衡量地改善了流动时间的具体排序决策。

讨论思路

我们的流动时间计时实际上从哪里开始，这个定义是否曾在没有文档记录的情况下漂移过？
我们所衡量的流动负载、到达率与流动时间，是否大致满足利特尔法则？
流动负载是否被足够持续地跟踪，以便一次稳定的上升能在数天而不是数月内被发现？
我们的流动时间与周期时间之间的差距有多大，这个差距告诉了我们延迟实际发生在哪里？

要点回顾

流动负载通过利特尔法则在数学上决定流动时间：对任何稳定价值流而言，流动负载等于到达率乘以流动时间。
流动时间跨越整条价值流，从业务需求识别到交付，比周期时间仅限工程的范围（主题 2.6）更宽广。
本主题核心的操纵向量是悄悄收窄流动时间的起点；护栏是一份有文档记录、经过审计的入口点定义。
持续跟踪流动负载，而不是周期性地跟踪，让它发挥真正领先指标的作用，而不是滞后的事后发现。
在为在制品限制、增加容量或排列并行工作顺序辩护时，明确地使用利特尔法则，而不仅仅是作为一种直觉。

参考文献与延伸阅读

Kersten, Mik. Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework. IT Revolution Press, 2018.
Little, John D. C. “A Proof for the Queuing Formula: L = λW.” Operations Research, 1961.
Reinertsen, Donald G. The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009.