2.8 精益价值流指标

概述与动机

本部分迄今涵盖的每一个指标（流动时间、流动负载、周期时间、利用率）都源自一套古老得多的工具包：经典精益价值流映射的五项基线衡量，这套方法诞生于丰田，并在软件采纳它们之前很久，就已在制造业、运营与服务交付中被普遍推广。交付周期（LT）是从工作被请求到被交付的总时钟时间。加工时间（PT）是花在处理单一单元上的实际动手时间。周期时间（CT）是完成价值流中单一节点或阶段所需的平均时间。完成且准确率（%C/A）是下游团队无需返工就能处理的单元百分比。节拍时间是完成一个单元、以干净匹配客户需求所能接受的最长时间。

本主题的存在，是因为软件工程并没有发明这些概念，而是借用了它们，而这种借用有时对略微不同的事物沿用了相同的词语。本书自己的周期时间（主题 2.6）专门衡量一次变更的工程阶段（编码、评审、测试、部署），而精益的经典CT是应用于任何流程的更普遍的”每节点平均时间”。流动时间（主题 2.4）是本书对精益所称交付周期的叫法。了解这种映射关系很重要，因为一位来自精益六西格玛背景（在制造业、物流、医疗保健与政府运营中很常见）的读者，会以其原始含义使用这些确切术语，而一个不说同一种语言的软件团队，会白白放弃一座通往工程之外同事、易得且有证据支撑的桥梁。

对大团队而言，%C/A是本主题中最未被充分利用的指标。它捕捉到了主题 2.3 和主题 2.4 的流动指标所没有捕捉到的东西：一个阶段的产出中，有多少能真正被下一个阶段使用而无需被退回。当在一条多阶段价值流上累积起来时（制造业称这一概念为累积吞吐良率），%C/A揭示了返工如何在各次交接之间无形地累积，这种模式，拥有长而多团队流水线的企业组织和拥有多重审批关卡的政府项目尤其容易出现，却很少被直接测量。

核心原则

这五个指标早于软件存在，并且概括适用于软件之外。 它们是接受过精益六西格玛训练的利益相关方（在大型企业和政府运营中很常见）已经流利使用的共同词汇。
术语冲突是真实存在的，值得明确点出。 本书的周期时间（主题 2.6）与精益经典的CT相关但不完全相同；记录这种映射关系，让跨职能对话不至于悄悄各说各话。
%C/A必须在每一个阶段上累积计算，而不是只在最后测量一次。 在流中较早引入、又在较晚才被发现的返工，对一个只在最终交付点测量的指标而言是不可见的。
节拍时间围绕需求而不是努力，重新构造容量规划。 问题从”我们能走多快”转变为”我们需要走多快”，这直接与利用率（主题 2.7）和流动负载（主题 2.4）相连。
这些是诊断性指标，而不是虚荣指标。 每一个都是为了回答一个具体的运营问题而存在，而不是为了给仪表盘生产一个令人印象深刻的数字。

建议

在采纳一个软件专属框架之前，先用全部五个精益指标映射你的价值流

在流动框架自身的指标（主题 2.3 和主题 2.4）之上叠加之前，先为一批流经你价值流的有代表性工作，计算交付周期、加工时间、周期时间、%C/A与节拍时间。这给你一条任何有精益六西格玛素养的利益相关方都能立即理解的基线，而且常常会揭示出主题 2.5 所描述的同一种等待时间主导现象，只是用了一种早于并且比任何特定软件框架都更持久的词汇来表达。

在每一个阶段上，以相乘的方式累积计算完成且准确率

分别在每个阶段测量%C/A，然后把各阶段层面的百分比相乘，得出价值流的累积吞吐良率。三个各自独立以90%完成且准确率运行的阶段，累积起来大约是整体73%，这个数字与任何单一阶段自己的报告看起来都不一样，而且通常更诚实。这一项计算，是揭示一条多阶段流水线真正吸收了多少返工的最快方式。

明确根据真实的客户需求数据设定节拍时间，而不是根据容量

把节拍时间计算为可用工作时间除以该期间的客户需求，刻意与你的团队今天碰巧能以多快的速度工作无关。把你测得的加工时间和周期时间与这个数字进行比较：加工时间舒适地低于节拍时间，表明存在健康的余量，而周期时间超过节拍时间，则是容量短缺的具体、量化证据，而不只是一种事情落后了的感觉。

记录精益术语与本书自身词汇之间的映射关系

在你的组织已经在软件之外运营着精益六西格玛项目，或工程向精通那套词汇的领导层汇报的情况下，在你的指标章程（主题 1.4）中明确写下这种映射：本书的流动时间就是精益的交付周期，本书的周期时间（主题 2.6）是精益更普遍的CT的一种具体应用，而本书的活跃时间（主题 2.5）就是精益的加工时间。这一份文档，能防止一场关于”谁的数字才是真的”反复出现、价值低下的争论。

把%C/A作为流动速度的护栏，而不是它的替代品

把累积吞吐良率与流动速度（主题 2.3）配对，就像本书为每一个速度指标配对一个稳定性护栏一样。项目计数上升而累积%C/A下降，意味着价值流正在交付更多日后越来越需要返工的单元，这正是主题 1.2 警告每个指标家族都要防范的那种”速度而无质量”模式。

权衡取舍：利与弊

方案	优点	缺点
仅经典精益指标（LT、PT、CT、%C/A、节拍时间）	通用词汇；在软件和非软件团队中同样适用	不是软件专属的；需要为工程专属阶段做翻译
仅流动框架指标（主题 2.3、主题 2.4）	专为软件价值流和项目类型可见性打造	对工程之外接受过精益六西格玛训练的利益相关方而言不熟悉
两者兼用，配以明确记录的映射	两种词汇都会说；最强的跨职能桥梁	需要前期的自律来写下这种映射并保持其最新
%C/A只在最终交付时测量	简单，一个数字	隐藏了在流中较早引入、较早被发现的返工

核心张力是普遍性与专属性之间的张力。经典精益指标对任何有制造业、运营或六西格玛经验的人而言都能立即理解，但它们在设计时并没有考虑软件专属的阶段（代码评审、自动化测试、部署审批）。解决之道是把精益指标用作跨职能和高管对话的共享基线词汇，把流动框架自身的指标（主题 2.3 和主题 2.4）用于工程团队日常进行的软件专属诊断工作。

与团队讨论的问题

我们今天能为我们的价值流计算全部五个经典精益指标吗，还是我们只有其中一些？ 大多数软件团队有流动时间和周期时间的等价物，却从未明确计算过加工时间、%C/A或节拍时间。在假定缺口很小之前，先识别出五个中究竟有哪些是真正缺失的。
我们是否曾在价值流的每一个阶段上累积计算过%C/A，还是只在最终交付时测量过？ 单一的流末测量，恰恰隐藏了本主题累积吞吐良率计算所要揭示的那种累积性返工。用真实数据尝试这项累积计算。
我们是否知道从实际客户需求计算出的节拍时间，我们测得的周期时间与它相比如何？ 大多数团队从未明确做过这种比较，这意味着容量方面的对话依然是轶事性的，而不是量化的。
如果一位来自工程之外、接受过精益六西格玛训练的利益相关方问起我们的周期时间，我们有信心我们说的是同一件事吗？ 本书的周期时间（主题 2.6）与精益经典的CT相关但不完全相同。讨论一下这种区别是否曾在你的组织中造成过真实的误解。
我们的累积吞吐良率，是否曾有意义地低于任何单一阶段自己报告的%C/A？ 如果你从未计算过这种累积，讨论一下你预期会发现什么，然后用真实数据核对一下。
我们组织是否已经在软件之外运营着一个精益或六西格玛项目，而我们本可以与之对齐，却一直维持着一套独立、脱节的词汇？ 许多企业和政府机构已经拥有这套基础设施；检查一下工程是否真的曾与之建立过连接。

行业视角

初创公司。 在这个规模上，完整的精益价值流映射很少值得那份仪式感，但非正式地理解节拍时间是值得的：大致知道团队真正需要以多快的速度移动才能匹配真实的客户需求，而不是一个随意的内部节奏，能同时防止过早地过度建设容量，以及增长到来时容量建设不足。

小型企业。 %C/A是这五个指标中在这里最立即有用的一个，因为它直接回答了”我们交付的东西中有多少需要重做”，这是业主和小团队敏锐感受到、却不总有一个数字与之挂钩的问题。在投资于更复杂的东西之前，先为你的一两个关键流程非正式地跟踪它。

企业。 这正是经典精益词汇发挥价值的地方，因为大型企业很常已经在运营、制造业邻近部门或共享服务中运营着一个精益六西格玛项目，而说同一种语言的工程部门，能立即获得一座通往这些职能部门的可信桥梁，而不需要从零开始为一套独立的、纯软件的指标集辩护其合理性。

政府。 政府机构，尤其是那些根源于监管、制造业邻近或物流职能的机构，常常已经有现存的精益或流程改进指令。用一个机构流程改进办公室已经在使用的同一套经典术语（交付周期、加工时间、%C/A、节拍时间）来框定一项数字服务的价值流，往往是为软件现代化努力争取到真正的机构支持的最快方式。

案例

企业。 一家制造业公司的内部软件部门，多年来一直难以让一支从工厂车间成长起来、精通精益六西格玛的运营领导团队认真对待其工程指标。用同一套五项经典指标重新构造该部门的交付流水线，为其软件价值流计算交付周期、加工时间、周期时间、%C/A与节拍时间，让该部门的数字第一次立即让运营领导层看懂了。一次跨流水线四个阶段的累积吞吐良率计算，揭示出实际的%C/A为61%，远低于任何单一阶段自己报告的数字，这成为了一项返工削减计划的证据基础，运营领导层在同一个季度就为其提供了资金。

政府。 一家州交通部门的数字许可团队，向一个拥有长期精益流程改进办公室的机构汇报，却从未与该办公室接触过，因为它自己的指标使用了那个办公室不认识的软件专属语言。在把许可价值流翻译成交付周期、加工时间与%C/A之后，流程改进办公室发现，该团队真正的约束不是工程速度，而是一个下游法律审查阶段，其相对于许可需求的有效节拍时间，运行得远低于其应有水平，这是一个该办公室因为它被以熟悉的术语框定、而能够立即据此行动的发现。

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

在本书的软件专属指标之外采纳经典精益词汇的回报，是通往流程改进专业知识和资金的一座可信、直接的桥梁，而这些往往已经存在于一个大型组织的其他地方。上面的制造业公司案例，在重新构造使这个案例变得可读的同一个季度就争取到了返工削减资金，正是本主题方法稳定产出的模式：洞见本身并不新鲜，但让它对正确的受众变得可行动的那套词汇却是新的。

总拥有成本很低：这五个指标除了主题 2.4 到主题 2.6 已经收集的东西之外，不需要任何新的埋点，再加上一项%C/A返工分类，这通常只是对现有缺陷和流动项跟踪（主题 2.2）的一个简单补充。主要的投资是翻译工作，把本书的术语与精益经典术语之间的映射写下来，而这项投资，在它第一次防止一场跨职能误解时，就已经收回了成本。

反模式与陷阱

只在最终交付时测量%C/A： 本主题核心的操纵向量。一个团队可以报告一个高的最终阶段%C/A，而更早的阶段却在悄悄产生返工，在任何人测量它之前就被修复了，让整条价值流看起来比实际情况更健康。护栏是在每一个阶段上以相乘的方式累积%C/A（累积吞吐良率计算），并定期审计每个阶段对”完成且准确”的定义，使其无法随时间悄悄收窄。
假定本书的周期时间与精益经典的CT意味着完全相同的东西： 当这两套词汇在没有文档化映射的情况下相遇时，会产生真实的跨职能困惑。
根据当前容量而不是真实客户需求设定节拍时间： 违背了这个指标的目的，即揭示需求与容量之间的差距，而不是确认无论现存节奏是什么都予以确认。
一旦采纳软件专属框架，就把经典精益指标视为过时： 抛弃了一座通往组织中可能已经存在的流程改进专业知识的可信、有证据支撑的桥梁。
忽视组织其他地方已经存在的精益六西格玛项目： 放弃了用共享语言重新构造交付指标本可解锁的资金、专业知识和机构信誉。
报告%C/A而不与流动速度配对： 让一个上升的吞吐量数字得以掩盖一个下降的返工率，这正是本书通篇警告的同一种护栏缺口。

成熟度模型

第一级，启动： 五项经典精益指标一个都没有被计算；交付被讨论时不参照交付周期、加工时间或%C/A。
第二级，发展： 交付周期和周期时间被非正式地跟踪，但加工时间、%C/A与节拍时间没有被计算，也不存在与本书自身词汇的映射。
第三级，标准化： 全部五项经典指标被一致地计算，与本书流动和周期时间词汇的映射被记录在一份共享的指标章程中。
第四级，管理： 累积吞吐良率在价值流的每一个阶段上被计算，节拍时间与测得的周期时间被比较，以明确量化容量差距。
第五级，协奏： 组织已经把其软件交付指标与业务中其他地方已经存在的精益或六西格玛项目连接起来，并能指出因共享词汇让一项洞见对非工程受众变得可行动而做出的具体投资或流程决策。

讨论思路

我们今天能为我们的价值流计算交付周期、加工时间、周期时间、%C/A与节拍时间吗？
如果我们把每个阶段的%C/A相乘，我们的累积吞吐良率会是多少？
我们组织是否已经运营着一个精益或六西格玛项目，而我们从未把工程指标与之连接起来？
我们测得的周期时间，与从真实客户需求计算出的节拍时间相比如何？

要点回顾

五项经典精益指标（交付周期、加工时间、周期时间、完成且准确率与节拍时间）早于软件存在，至今仍是接受过精益六西格玛训练的利益相关方的共同词汇。
本书自身的流动时间与周期时间，映射到但不完全等同于精益的交付周期和经典CT；明确记录这种映射，以避免跨职能困惑。
本主题核心的操纵向量是只在最终交付时测量%C/A；护栏是把它作为累积吞吐良率，在每一个阶段上以相乘的方式累积计算。
节拍时间围绕真实客户需求，而不是现有节奏，重新构造容量，并直接与利用率（主题 2.7）和流动负载（主题 2.4）配对。
用经典精益术语重新构造软件交付，往往是与一个大型组织中已经存在的流程改进专业知识和资金建立连接的最快方式。

参考文献与延伸阅读

Rother, Mike, and John Shook. Learning to See: Value Stream Mapping to Create Value and Eliminate Muda. Lean Enterprise Institute, 1999.
Womack, James P., and Daniel T. Jones. Lean Thinking: Banish Waste and Create Wealth in Your Corporation. Free Press, 1996.
Womack, James P., Daniel T. Jones, and Daniel Roos. The Machine That Changed the World. Free Press, 1990.
George, Michael L. Lean Six Sigma for Service: How to Use Lean Speed and Six Sigma Quality to Improve Services and Transactions. McGraw-Hill, 2003.
Ohno, Taiichi. Toyota Production System: Beyond Large-Scale Production. Productivity Press, 1988.