11.6 价值流映射与延迟成本

概述与动机

如果你问交付团队里的十个人，从一个想法到生产环境中的成果之间时间都去哪了，你会得到十种不同的猜测。其中大多数都是错的，而且大多偏乐观。原因在于，每个人都清楚地看到自己负责的那一步，却完全看不到各步骤之间的等待。开发者知道一个功能写了两天代码。但没有人追踪它随后在评审队列、测试环境排期、变更审批委员会和发布窗口里又躺了十一天。工作本身以小时计完成，却在队列中以更长的时间损耗。本章给你两种视角来看清整幅画面并据此行动：价值流映射，它让从想法到价值的流动变得可见；以及延迟成本，它为等待赋予一个经济代价，让你能用金钱而非意见来排定优先级。

这两种视角是第 11 部分其余内容的补充。第 11.1 章描述了决定构建什么的发现流水线，第 11.2 章描述了交付它的交付流水线。价值流映射则横跨两者，把从最初的想法到可度量的结果的整条路径，当作一个需要被看见和改进的系统。第 11.3 章给出了队列的数学原理；本章给出的是在你的组织中实际找出这些队列形成之处、以及它们代价几何的实践方法。第 11.4 章（OKR）和第 11.5 章（KPI）告诉你「好」是什么样子，而延迟成本告诉你追求它的先后顺序。

对大型团队而言，回报是巨大的。跨越数十个团队的协作会成倍增加交接次数，而每一次交接都是工作等待的地方。在企业环境中，一个功能可能要经过产品团队、平台团队、安全评审和发布管理职能，才能到达客户手中，而这些团队之间的等待时间往往远超团队内部的实际工作时间。在政府部门，跨年度的计划要根据立法期限动用公共资金，未经映射的价值流会让对支出负责的人看不到其中的浪费与风险。让流动可见、诚实地为延迟定价，正是大型组织停止凭轶事争论、开始依据证据决策的方式。

关键原则

看清从想法到价值的整个流动过程，而不仅仅是你负责的那一步。
将处理时间（真正的工作）与等待时间（纯粹的延迟）区分开来；两者之间的差距就是你的机会所在。
度量流动效率，并预期在改进之前它会低得惊人。
找到那个决定吞吐量的唯一瓶颈，停止在其他地方到处优化。
用金钱为延迟定价，让优先级成为一个经济决策，而不是声量的比拼。
按延迟成本除以持续时间来排序工作，而不是按谁的声音最大。
把价值流管理当作一项持续的实践，而不是一次性的工作坊。

建议

映射从想法到价值的价值流

价值流是你的组织把一个请求转化为已交付价值所执行的完整步骤序列。映射它意味着走一遍这个序列，写下每一步、由谁执行，以及针对每一步的两个数字：处理时间（正在积极开展工作的时间）和交付周期（从该步骤可以开始到它交接出去为止的总耗时，包括所有等待）。针对一个有代表性的工作项完成这项工作，从想法被接受的那一刻，到其效果在生产环境中被度量的那一刻为止。要包含第 11.1 章的发现步骤和第 11.2 章的交付步骤。得到的结果是你真实系统的一张单一图示，而不是组织架构图上的那一张。

要抵制住映射「理想化流程」的冲动。映射最近三四个工作项实际发生的情况，使用工具里的时间戳而不是记忆。你要寻找的是真相，而真相就藏在步骤之间的缝隙里。团队第一次诚实地完成这项工作时，总会有人说出类似「我完全不知道它在那里躺了一周」这样的话。这种反应正是重点所在。你无法改进一个你从未整体看过的流程。

区分处理时间与等待时间，计算流动效率

一旦你有了这些数字，把它们加起来。流动效率是增值时间与总交付周期之比：处理时间之和除以从开始到结束的总耗时。如果一个功能实际耗费 40 小时工作，但在整条价值流中走了 20 个工作日，其流动效率大约是 40 除以 160，即 25%，而这已经算是相当不错的水平。许多真实的价值流落在 5% 到 15% 之间。其余的都是纯粹的等待：工作躺在队列里、被某个依赖阻塞，或搁置在某人的收件箱中。

这个数字重构了每一次改进对话。当流动效率为 15% 时，把工作本身加快 20%，总体也只能提升三个百分点，而消除一半的等待则几乎能让速度翻倍。团队本能地会尝试写代码更快、评审更快、测试更快。而这张图告诉你，杠杆几乎从不在工作步骤本身，而几乎总是在它们之间的等待中。追逐空白，而不是方框。

找出交接点与返工循环

图上有两种结构值得特别关注。交接点是工作从一个人或一个团队传递到另一个人或团队的地方，每一个交接点都是一个队列，工作项在此等待下一方腾出产能。每一次交接也会丢失上下文，所以接收方要花时间重建发送方原本已经知道的信息。返工循环则是指向后方的箭头：一次失败的测试把代码打回给开发者，一次被拒绝的变更被打回评审委员会，一次澄清请求把故事打回产品部门。返工循环的代价是双重的，因为它既消耗产能，又使被返工的工作项重新排到队列末尾。

把两者都数一数。一条有九个交接点和三个返工循环的价值流，无论人员多么熟练，流动效率都会很糟糕，因为这种结构本身就在制造等待。减少交接点（通过让一个团队拥有端到端的所有权）和消除返工的根源（按第 11.2 章所说，把质量检查前移），通常比任何加快单个步骤速度的努力都更有效。

找出瓶颈，尊重约束理论

每条价值流都恰好有一个限制其吞吐量的步骤，就像管道中最窄的地方限制水流一样。艾利·高德拉特（Eliyahu Goldratt）提出的约束理论为此提供了一套方法：识别约束、挖掘约束（确保它永不闲置，也从不在做错误的工作）、让其他一切服从约束（不要以超过它能吸收的速度向它输送工作）、提升约束（增加产能），然后重复，因为约束会随之转移。这条关键且反直觉的规则是：改进除约束之外的任何步骤都不会带来任何改进。加快一个非瓶颈步骤的速度，只会让库存在瓶颈前堆积得更快。

在图上找出你的约束：它是前面排队最长、最持续存在的那一步。在软件领域，它常常是一种共享的、专业化的资源，例如唯一的安全评审职能、唯一的数据库专家，或稀缺的测试环境。一旦你知道它是谁，就要保护它。不要让它闲置等待输入，不要让它去做更便宜的步骤本可以完成的工作，并且在优化它上下游的任何东西之前要三思。整个系统的节奏，都由那一个步骤决定。

用延迟成本以经济学方式排定优先级

延迟成本是指一项工作每延迟交付一个单位时间，你所损失或未能获得的金钱。它是「以后再说」的经济代价。一个每月能带来 10 万美元收益的功能，延迟两个月，就会造成 20 万美元的损失，无论这个数字是否出现在预算表里。把这一点讲清楚，是对困扰大型待办事项列表的「一切都是最高优先级」病症最有力的解药。当每个利益相关者都坚持自己的事项是紧急的，你无法用比拼声量来解决它；你要通过问每个人「延迟一个月对我们意味着多少损失？」，并把答案摆在一起来解决它。

估算延迟成本并不需要精确。由理解价值所在的人给出的一个粗略数字，胜过一种「一切都同等重要」的虚假共识。要考虑三个组成部分：价值本身（收入、成本节约、风险降低）、时间敏感性（如果我们等待，价值会不会衰减？），以及任何硬性截止日期（法规、合同、季节性窗口）。这与第 10.15 章的估算与预测方法直接相关：你在预测的是处于风险中的价值，而不仅仅是工作量。这个数字不需要精确到美元，只需要足够正确，能够改变你工作的先后顺序。

用 CD3 和加权最短作业优先排序

延迟成本告诉你什么东西延迟的代价高昂，但它本身并不能告诉你应该先做什么，因为一个价值巨大、却需要六个月才能完成的事项，可能不如一个价值适中、但本周就能完成的事项更值得优先。解决这个问题的规则是延迟成本除以持续时间，写作 CD3。你为每个事项计算延迟成本，再除以完成它所需的时间，然后优先做比值最高的那一个。这是加权最短作业优先（WSJF）在软件领域的应用，这是一个调度学结果，证明了用延迟成本除以作业长度能使整个工作队列的总经济成本最小化。

WSJF 蕴含的洞见是，短小而有价值的工作应该插队，因为快速完成它们能释放队列，让其价值更早开始产生，同时几乎不延误其他任何事项。而一项长期作业，无论多有价值，都会拖住它后面的一切。在实践中，你在简单的相对量表上估算延迟成本和持续时间，计算比值，让它来排定待办事项列表的顺序。许多规模化组织所使用的框架将 WSJF 表示为延迟成本（由业务价值、时间紧迫性和风险或机会赋能构成）除以作业规模，这是同一个思路，只是给各组成部分起了名字。

解读每个事项的紧迫性剖面

并非所有延迟成本随时间的变化方式都相同，其形状与其大小同样重要。紧迫性剖面描述了延迟成本随等待时间变化的方式。有些价值大致是线性的：你每周损失的金额大致相同，会一直持续下去。有些呈固定日期的阶跃函数：在截止日期之前延迟不产生任何成本，而截止日期一到就会一次性产生巨大成本（一次法规切换、一次合同上线）。有些会衰减：一个市场窗口，或一个竞争性的先发优势，现在价值连城，六个月后所剩无几。还有一些几乎是平的，无论何时交付，价值都相同。

了解这种剖面会改变你的排序方式。一个价值急剧衰减的事项应该现在就做，趁价值尚未流失。一个固定日期的事项可以等到刚好剩下足够的提前量时再做，然后绝不能延误。哪怕只是粗略地为你的主要举措绘制紧迫性剖面，也能告诉你延迟不仅代价几何，还告诉你这个代价何时到来，而这正是你在资源争用下进行排期所需要的信息。

把流动度量与 DORA 及利特尔法则连接起来

价值流映射会产生四项值得持续追踪的流动度量：交付周期（从开始到完成的总耗时）、周期时间（某个特定阶段的耗时，通常是活跃交付部分）、在制品（WIP，正在进行中的事项数量），以及吞吐量（单位时间内完成的事项数）。它们通过第 11.3 章的利特尔法则联系在一起：平均交付周期等于平均在制品除以平均吞吐量。这个方程是你最实用的杠杆，因为它说明，如果你无法轻易提高吞吐量，你可以立即通过降低在制品来缩短交付周期。少启动，反而能多完成。

这些流动度量还向上与 DORA 指标（来自 DevOps 研究与评估计划）相连：部署频率、变更交付周期、变更失败率，以及服务恢复时间。变更交付周期是你价值流的一个切片，映射会告诉你应该攻克哪些步骤来改进它。把 DORA 当作结果记分牌，把价值流地图当作解释这个分数的诊断工具，将两者都与第 1.10 章的工程效能视角联系起来。

有意识地管理队列、批量大小和在制品

你在图上发现的队列，正是交付周期产生的地方，而第 11.3 章解释了它们为何会在利用率逼近 100% 时急剧膨胀。有两个杠杆能驯服它们。第一是在制品限制：为每个阶段允许存在的事项数量设置上限，使工作只在有产能时才被拉入，这通过利特尔法则直接缩短了交付周期，并暴露出瓶颈，而不是把它掩埋在一大堆已开始但未完成的工作之下。第二是批量大小：大批量（季度发布、庞大的拉取请求、庞大的需求文档）会造成漫长的队列、延迟反馈、并增加每次交接的成本和风险。

更小的批量流动得更快、更可预测，这也是第 11.2 章的交付流水线偏爱小型、频繁、可逆变更的最深层原因之一。缩小批量和限制在制品，是你能做的两项最可靠、成本最低的干预措施，因为它们直接攻击等待本身，而不是试图让工作本身变得更快。

权衡：优点与缺点

实践	优点	缺点
价值流映射	揭示隐藏的等待；让团队围绕同一幅图达成一致	快照容易过时；若无后续行动则努力白费
流动效率度量	将精力重新导向等待所在之处，那正是杠杆所在	可能被重新定义「有效工作」而操纵
约束理论聚焦	把精力集中在真正能推动吞吐量的地方	在政治上很难让非瓶颈团队保持不变
延迟成本	把优先级变成经济学问题；打消「一切都紧急」	估算存在不确定性，可能被争论或夸大
CD3 / WSJF 排序	使总经济延迟最小化；偏爱速赢事项	每个事项需要两个估算值；存在虚假精确的风险
在制品限制	立即缩短交付周期；暴露瓶颈	感觉像强制闲置；在文化上会遭到抵制
小批量	反馈更快，单次变更风险更低	若自动化薄弱，单项开销会更高

核心张力在于度量所需的努力与它所强迫的诚实之间。价值流地图和延迟成本模型都需要投入工作才能建立，两者也都可能被操纵，或在组织不认真对待时被搁置腐烂。其失败模式是：一场映射工作坊产出了一张精美的图，却没有带来任何实际流程的改变；或者一个延迟成本数字被每个利益相关者不断夸大，直到它再次变得毫无意义。要解决这个问题，就要把这项实践与行动，以及一小组被持续追踪的流动度量绑定起来。一张地图只有在你真的会去攻克它揭示的瓶颈时才值得绘制，一个延迟成本估算只有在它真的会重新排定待办事项列表时才值得争论。目标不是精确，而是更好的决策。

与团队讨论的问题

如果我们为最近三个功能映射出真实的价值流，从想法到生产环境，我们的流动效率实际上会是多少，最大的等待池又在哪里？ 大多数团队从未计算过这个数字，一旦看到答案都会大吃一惊，因为他们看到的工作步骤感觉很忙碌，而步骤之间的等待却是不可见的。带上工具里的时间戳而不是记忆，走一遍最近某个工作项的端到端过程，为每一步写下处理时间和总交付周期。你要寻找的证据，是工作本可以推进和实际推进之间最大的那个缺口。这个缺口，而不是任何个人的速度，才是你的第一个目标，把它大声说出来通常就足以让团队产生修复它的意愿。
我们真正的唯一约束在哪里，我们是否在无意中优化了除它以外的一切？ 约束理论指出，只有瓶颈才决定吞吐量，然而团队常常把精力倾注在已经很快的步骤上，因为那些步骤是他们能掌控的。要找到前面排队最长、最持续存在的那一步，并诚实地反思：最近的改进究竟触及了它，还是只是让某个非瓶颈变得更快了。一个令人不安但有价值的结论往往是：一种共享、稀缺的资源（一位评审人、一个环境、一位专家）决定了所有人的节奏，保护并提升这一资源，比其他任何局部提速都更重要。
当两位利益相关者都说自己的工作是最高优先级时，我们今天是如何决定的，延迟成本会不会给出不同的顺序？ 现在的答案大概是资历、声量，或者谁升级得最猛，这些都没有反映经济价值。带上两个真正有争议的事项，尝试估算（）即便只是粗略地（）延迟一个月各自的代价是多少，以及各自需要多长时间，然后计算延迟成本除以持续时间。重点不在于精确的数字，而在于它们所迫使的对话：一旦要求利益相关者为自己的请求附上延迟成本，他们的思考方式就会突然不同，而在经济学上胜出的事项，往往并不是在声量上胜出的那一个。看看这会给会议室带来什么变化。
我们的价值流中，哪些交接点可以取消或合并，谁又需要放弃控制权才能做到这一点？ 每一个交接点都是一个队列和一次上下文损失，因此交接点的数量往往比任何团队的技能水平更能预测流动效率，然而交接点之所以存在，是因为它们承载着所有权、审批权，以及某人对问责的认知。对大型组织而言，这正是地图变得政治化的地方：合并一个交接点通常意味着把端到端所有权交给一个团队，并要求某个控制职能信任一个自动化关口，而不是人工签核。带上逐个交接点的等待时间、每个交接点触发的返工循环，以及一份诚实的说明，指出哪些交接点是出于真实的风险原因，哪些只是历史习惯。在企业和政府场景中，为每一个有争议的交接点指明控制职能的负责人，以及什么样的证据（一项通过的自动化检查、一条审计轨迹、一项被授权的权限）能让他们接受移除它，因为一个没有人愿意放手的交接点，就是你交付周期上一项永久性的税负。
我们用来排定工作顺序的延迟成本数字，我们有多大信心，又是什么阻止每个利益相关者简单地夸大自己的数字？ 只有在估算带有一定纪律的情况下，延迟成本才能真正打破「一切都是最高优先级」的僵局；一旦每一方都发现数字越大越能获胜，他们就都会给出更大的数字，你又会回到一场披着经济学外衣的声量比拼。与之相对的考量是，要求精确会扼杀这项实践，因为由理解价值的人给出粗略数字正是这项实践的全部意义所在，所以你需要足够的严谨来比较各个事项，而不必假装拥有虚假的精确度。带上几个分解成各组成部分（价值、时间紧迫性、截止日期压力）的真实估算，找出那些可疑地整齐、或缺乏依据的数字。对于企业投资组合或动用公共资金的政府计划而言，要决定谁来仲裁有争议的数字，以及估算之后是否会与实际结果进行核对，因为一个无人校准其与现实差距的延迟成本模型，终将被所有人操纵。
我们是否真的在有意识地管理在制品和批量大小，还是任由两者不断上升，直到交付周期悄然翻倍？ 利特尔法则让这个杠杆变得具体：交付周期等于在制品除以吞吐量，所以失控的在制品会拉长每个事项的等待时间，即使没有人工作变慢；而大批量会叠加这种效应，把你已经在图上发现的队列进一步撑大。这种张力是文化性的，因为限制在制品感觉像是强制闲置，小批量感觉像是额外开销，所以团队会抵制这两者，即便它们是现成的、最廉价的干预措施。带上你目前每个阶段的在制品数量、你典型的批量大小（发布、拉取请求、需求文档），以及与之相伴的交付周期趋势。在大型组织或公共机构中，把这一点与你受合同或流程约束的发布及变更审批节奏联系起来，因为一个季度发布窗口或一个月度委员会可能会迫使你采用大批量，说出这个约束是把它谈判下来的第一步。

行业视角

初创企业。 只有寥寥几名工程师、跑道有限时，你的价值流很短，但你的约束通常是一个人：一位审批一切的创始人，或唯一负责部署的那位工程师。不要开展一场繁重的映射演练；花半天时间按时间戳追溯最近几个功能，找出这个人为瓶颈，然后围绕它进行授权或批量处理。跳过正式的延迟成本模型，用一个粗略的「延迟成本除以持续时间」排名来结束每周关于「接下来做什么」的争论，在你还在摸索市场需要什么的阶段，保持批量微小，让反馈保持快速。

小型企业。 你没有流动度量专家，预算也紧张，所以要依靠你已经在使用的工具：从你的工单跟踪系统和版本控制系统中提取时间戳，而不是购买一个价值流平台。映射一个有代表性的工作项，粗略计算流动效率，攻克最大的那一个等待池，它往往是搁在某位繁忙负责人手中的一项审批。把延迟成本当作一场对话，而不是要购买的电子表格产品，比起任何承诺按月付费可视化流动的工具，更应优先削减在制品和批量大小（两者都是免费的）。

企业。 价值在于看清跨越多个团队的全局，一个功能要经过产品、平台、安全和发布管理，团队之间的等待往往远超团队内部的工作量。把价值流映射标准化为一项可重复的实践，把延迟成本除以持续时间作为共享的优先级语言，让各团队不再凭声量争论，并强制执行在制品限制和更小的批量，以暴露真正的约束，而不是把它掩埋在已开始但未完成的工作之下。把流动度量与 DORA 和利特尔法则挂钩，让整个投资组合拥有一个诊断工具和一个记分牌，并围绕谁拥有该约束、谁来仲裁有争议的延迟估算建立治理机制。

政府部门。 采购规则、透明度义务和公共问责制塑造着每一个选择，一个立法规定的截止日期通常主导着一切的紧迫性剖面。跨政策、工程、安全认证和运营映射价值流，因为其硬性约束常常是一个以月计排队的认证或合规关口，而提升它（增加评审人员、把证据收集前移）所带来的收益，超过任何下游提速。把价值流管理变成一项定期评审的常态化实践，让监督机构获得可审计的证据，证明改进的是流动本身，而不仅仅是支出，并公开为延迟成本定价，以便公共资金的排序能够被解释和辩护。

示例

初创企业。 一家十五人的初创公司不断错过自己的路线图，并把这归咎于工程师。一次半天的价值流映射会议却讲出了另一个故事：功能的大部分生命周期都花在等待唯一一位审批每一项设计和每一次发布的创始人身上。流动效率不到 10%，而这位创始人就是约束。他们直接应用约束理论：创始人把低于某个规模阈值的设计审批权下放，把临时签核改成每日一次的批量发布窗口，并不再让自己接收超出她能处理量的决策。一个月内交付周期大约缩短了一半，且没有新增任何人手。随后他们为待办事项列表采用了一个简单的「延迟成本除以持续时间」排名，悄然结束了每周关于接下来该构建什么的争论。

企业。 一家大型银行为一项面向客户的变更映射了价值流，发现它要经过九个团队，交付周期长达十一周，其中大约六天是实际工作。其余的都是队列：一个每月进行一次的安全评审、一个每周开会的变更审批委员会，以及以天计的环境预约。这家银行没有推动团队更快地工作，而是攻克等待本身：它把安全评审前移，并按第 11.2 章所述将其大部分自动化，把每周一次的委员会改为针对低风险变更的轻量级常设审批，并限制在制品，让团队先完工再启动新工作。延迟成本成为投资组合的优先级语言，把那份永恒的「一切都很关键」的待办事项列表变成了一份有排序的列表，变更交付周期（一项 DORA 指标）从十一周降到不足两周。

政府部门。 一家国家税务机关正在一项立法期限之下开展一场多年期的现代化改造。领导层看不到公共资金究竟带来了怎样的进展，因为该计划汇报的是活动，而不是流动。该机构跨政策、工程、安全认证和运营映射了自己的价值流，发现认证是一个以月计排队的硬性约束。它把认证当作需要提升的瓶颈，增加人手并把证据收集前移，使各事项在到达评审时就已准备就绪。它用每项任务各自的紧迫性剖面来为延迟成本定价：固定的立法截止日期主导着排序，而价值平稳的清理工作则被搁置等待。价值流管理变成了一项每季度评审一次的常态化实践，让监督机构获得可审计的证据，证明改进的是流动本身，而不仅仅是支出。

商业论证：动机、投资回报率与总拥有成本

这些实践的回报来自把不可见的等待转化为更早交付的价值。当流动效率为 15% 时，你的大部分交付周期都是浪费，你已经在以更慢的反馈、更晚的收入，以及对路线图失去信心的利益相关者的形式，为这份浪费买单。相较于招聘，消除等待几乎是免费的：在制品限制、更小的批量、更早的安全评审，以及下放的审批权，成本低廉，却常常能让交付周期减半。你消除的每一周交付周期，都是提前拉近的一周价值，而延迟成本让你能用领导层已经在追踪的同一种货币来量化这份收益。

以延迟成本排定优先级有其自身独特的回报：通过用 CD3 或 WSJF 进行排序，你可以证明地把整个待办事项列表的总经济延迟最小化，这意味着同样的团队、同样的工作时长，仅仅通过以更好的顺序做事，就能交付更多价值。这是你能获得的最廉价的改进，因为它完全不需要新增产能。采用成本是适度且大多是一次性的：几场映射会议、一个轻量级的延迟成本模型，以及持续追踪少数几项流动度量的纪律。持续的成本，是保持地图更新、抵制夸大延迟估算所需的诚实。

疏于治理的代价会悄然累积。未经映射的价值流会积累无人负责的交接点和返工循环，按声量排优先级的待办事项列表会逐渐偏离价值，而组织在按平均值规划的同时，队列却在接近满负荷利用率时急剧膨胀（第 11.3 章）。要向领导层论证，把这些实践与他们已经在关注的指标联系起来：DORA 的变更交付周期、吞吐量，以及每季度交付的价值。把价值流管理定位为解释这些数字的诊断工具，把延迟成本定位为改进这些数字的经济学逻辑。

反模式与陷阱

映射后就遗忘： 在工作坊中产出一张精美的价值流图，却没有带来实际流动的任何改变。
优化非瓶颈： 加快已经很快的步骤，只会让库存在真正的约束前堆积得更快。
西瓜式流动度量： 绿色仪表盘（高吞吐量）掩盖了红色的现实（庞大的在制品和不断拉长的交付周期）。
延迟成本膨胀： 每个利益相关者都给出一个巨大的数字，重新制造出你本想打破的「一切都是最高优先级」的僵局。
忽视持续时间： 纯粹按价值排序，让一个价值高但要耗时六个月的工作排在十个速赢事项前面，无视 CD3。
忽视紧迫性剖面： 把一个价值正在衰减的事项和一个价值平稳的事项当作可以互换的，结果先交付了错误的那个。
局部效率崇拜： 让每个团队始终保持 100% 的利用率，这只会最大化队列和交付周期，而不是流动。
大批量发布： 把变更捆绑成罕见的大批量投放，拉长队列、延迟反馈，并提高每次发布的风险。
只看平均值来规划： 只使用平均交付周期而忽视其变异性，之后又对那条长尾感到意外（第 11.3 章）。

成熟度模型

第一级，启动： 没有人能看到端到端的流动。优先级由声量、资历或升级来决定，「一切都是最高优先级」是常态。步骤之间的等待是不可见的，改进的精力落在任何团队感觉忙碌的地方，而通常并不是约束所在。没有人区分处理时间和等待时间，因此巨大的排队等待既未被察觉，也未被定价。
第二级，发展： 有一两个团队已经映射了至少一条价值流，能够指出最大的队列和一个大致的流动效率。一些流动度量（交付周期、在制品）在局部被追踪，优先级排序有时会考虑价值，但这种做法在各团队间并不一致：延迟成本是非正式的，地图是一次性的产物，各个团队各行其是，甚至根本不做。
第三级，标准化： 价值流映射是一项有文档记录、在全组织范围内可重复使用的实践，约束按约束理论被识别并加以保护，在制品限制和更小的批量是强制执行的标准，而不是局部试验。延迟成本除以持续时间（CD3 或 WSJF）是各团队之间排定待办事项顺序的共识方法，流动度量通过一套共享的交付周期、周期时间、在制品和吞吐量定义，明确地与 DORA 相连。
第四级，管理： 流动被度量，并根据基线用数据加以控制。流动效率、交付周期、在制品、吞吐量以及 DORA 的变更交付周期被持续追踪，对照商定的目标，并设有控制限，用以标记价值流何时出现偏离。延迟成本估算会与实际结果进行校准，以便及时发现夸大之处，约束的队列以真实数字被监控，流程变更的通过或否决决策基于证据而非意见。
第五级，协同： 价值流管理是持续的、在整个组织范围内集成的、且具有适应性的。紧迫性剖面为排序提供依据，约束在移动时被提升并重新识别，延迟成本模型根据真实结果不断精炼，映射、优先级排序和队列管理彼此互相反馈，并反馈给更广泛的投资组合。组织会随条件变化重新平衡流动，并能用可审计的证据证明这种改进。

讨论议题

你目前的流动效率是多少？如果你消除一半的等待，而不是加快工作本身的速度，你的速度会快多少？
你真正的唯一约束目前在哪里？要让它永不闲置、也永不去做更便宜的步骤本可以完成的工作，需要付出什么？
对于你待办事项列表中排名前五的事项，延迟一个月各自的代价是多少？按延迟成本除以持续时间排序会不会改变它们的顺序？
你的哪些主要举措具有衰减型紧迫性剖面，你是否有在其大部分价值已经流失之后才交付的风险？
如果你明天把在制品减半，利特尔法则会为你的交付周期预测出什么结果？你需要克服怎样的文化阻力才能尝试它？
你典型的批量（发布、拉取请求、需求文档）有多大？把它减半会对你的反馈速度和单次变更风险产生怎样的影响？

关键要点

映射从想法到价值的整个流动过程，计算流动效率；你的杠杆存在于步骤之间的等待，而不是步骤内部的工作中。
找到那唯一的约束，并尊重约束理论：优化其他任何步骤都不会带来任何改进，只会更快地喂饱瓶颈。
用金钱把延迟成本讲清楚，以打败「一切都是最高优先级」，并解读每个事项的紧迫性剖面，了解代价何时到来。
用延迟成本除以持续时间（CD3 或 WSJF）来排序，使总经济延迟最小化，让短小而有价值的工作得以插队。
用在制品限制和小批量管理队列，把你的流动度量与 DORA 和利特尔法则挂钩，把价值流管理当作一项持续的实践来运行。

参考文献与延伸阅读

Donald G. Reinertsen, The Principles of Product Development Flow: Second Generation Lean Product Development
Eliyahu M. Goldratt and Jeff Cox, The Goal: A Process of Ongoing Improvement
Mike Rother and John Shook, Learning to See: Value Stream Mapping to Add Value and Eliminate Muda
Karen Martin and Mike Osterling, Value Stream Mapping: How to Visualize Work and Align Leadership for Organizational Transformation
Mik Kersten, Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework
Nicole Forsgren, Jez Humble, and Gene Kim, Accelerate: The Science of Lean Software and DevOps
Dean Leffingwell, SAFe 5.0 Distilled: Achieving Business Agility with the Scaled Agile Framework