打开软件研发的黑盒子：一文读懂研发效能洞察的五大流动指标

数字化时代，软件研发本身也要数字化

你是否已经感受到，我们已经身处数字化时代的关键节点上。

这里首先抛出一个有趣的问题：一辆普通的小轿车里面的代码规模，与桌面操作系统的代码规模，哪个更大？

也许你已经猜到了答案。

多年以前，一辆小轿车里面大概只有 100 万行的代码，用于基础驱动功能（如牵引力控制）；随后不久就增长到了 1000 万行代码，以满足越来越多的数字化、电子控制单元的增长，以及电动汽车所带来额外控制软件的复杂性；随着汽车互联和信息娱乐的发展，在几年前，一辆宝马汽车中已经达到 1 亿行代码；随着自动驾驶技术的普及，也许很快将会有 10 亿行代码。相比之下，我们的桌面电脑上安装的操作系统有多少代码呢？有资料显示，微软 Windows 操作系统大概有 6000 万行左右的代码。

所以，汽车已经变成了轮子上的计算机。

图 1：现代化的汽车已经成为轮子上的计算机

这还只是一个小例子，我想说的是，我们真的，已经身处在数字化时代的关键节点上。

但有点讽刺的是，在数字化的时代，作为 IT 从业者，我们的研发管理方式，有时还处于相对落后的状态。

很多企业还在使用上次技术革命所使用的方法，延续了旧的行为和过时的思维方式。比如使用近百年之前衡量体力工作者的方法，过度关注工作的时长、人力资源饱和度，过度要求工作活动的标准化和整齐划一；过度关注工作产出的代理指标（开发人员写了多少行代码、测试人员测出来多少 Bug），而不是最大化业务结果；过度关注局部优化（某个研发环节的自动化程度、使用了哪些 DevOps 工具），而不是全局优化（端到端的交付效率和质量）…

以至于到了现在，软件研发过程在很多情况下还是一个黑盒，缺乏端到端的可见性，哪里有拥堵、哪里有浪费、哪里有风险，管理者可能并不清楚，产品、开发、测试、运维各自的真实痛点，也容易被埋没在无穷无尽的需求和工作当中，更可怕的是，时间一久大家也就习以为常了。

但是，我们还是有追求的，我们要想办法，让软件研发本身也实现数字化。而数字化就是从物理世界中，开采出数据，粗炼出信息，精炼出知识，聚合出智慧，最终提高生产力。

按照这个逻辑，研发的数字化，我们可以从建设有效的研发效能洞察体系开始。

研发效能洞察体系的话题很大，涉及到研发的基础设施的建设、度量指标体系的设计、洞察分析模型的构建、洞察工具产品的实现、基于数据驱动和实验思维的运营等等。限于篇幅，本文只展开其中的一小部分，即重点聚焦于通过软件交付价值流管理方法中的五大流动指标，对研发过程进行有效洞察，并分析其中潜在的问题和瓶颈。

图 2：研发效能洞察体系

流框架及五大流动指标

在 2018 年底有一本名为《Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework》著作出版，书中指出业务与 IT 之间的脱节是数字化转型失败的根本原因之一，并进一步提炼出了一个称为“流框架”的全新模型，用来建立业务驱动的数字化转型与支撑它们的技术转型之间所缺失的那一层连接。

记得当时是何勉老师向我推荐了这本书，我看到后真的有一种相见恨晚的感觉，我认为书中的内容对于整个行业有很强的指导意义和很高参考价值，随即我决定要与朋友们一起将它翻译成中文版本（即将出版，敬请期待）。

本文我们就先聚焦于流框架中的五大流动指标。

图 3：五大流动指标

大家可能要问，为什么要称为“流动”指标呢？

这是因为，精益思想是流框架及其相关流动指标设计的底层逻辑，正如精益思想的五大原则所强调的，我们要应该按照具体产品精确地定义价值、为每款产品定义价值流、使价值不间断地流动、让客户从生产商拉动价值，以及追求尽善尽美。

所以，基于精益思想，流动指标度量的就是价值的流动，它们共同指征了一个组织交付价值过程中的效率水平和健康程度。流动指标共有五个，分别是流动速率、流动时间、流动负载、流动效率和流动分布。综合利用好这五个指标，我们就可以讲述一个关于软件研发价值流完整的故事，回答关于研发交付效率如何的本质问题。

1. 流动速率

图 4：流动速率

• 指标定义：

在给定时间内完成的流动项（如需求、缺陷或其他各种类型的工作）的数量，流动速率可用于衡量生产力。

• 如何使用：

跟踪流动速率，以有效评估并预测团队可以交付多少工作。当流动速率过低时，需要及时调查原因，可能会存在资源紧缺、架构或基础设施等问题，也有可能存在大量等待导致的流动停滞。

• 指标解读

数值升高：

一般表明价值交付正在加速

数值降低，且流动时间很长：

一般表明交付存在阻塞、依赖，或在制品过多导致的工作切换浪费

• 常见问题

流动速率与敏捷的速率概念有什么区别？

流动速率从敏捷的速率概念改编而来，后者表明了团队在一个时间段内（例如，两周的迭代）交付了多少个工作单元（例如，故事点数）。但流动速率计算的是在给定时间内完成的流动项的数量，假如一个版本完成了 10 个需求和 5 个缺陷，则该版本的流动速率为 15。所以，这里的关键区别是，流动速率更简单，它不依赖于对工作量大小、范围或每个流动项优先级的估算。

• 流动速率为什么按需求个数来算，而不是按故事点来算？

诚然，流动项的大小可能会大相径庭，这会让人们倾向于用“故事点”或“T 恤”进行估算。

但是，使用故事点的估算会容易引发规模冲动（人为的多估算一些），反而可能会更不准确，也经常因此出现业务 / 产品与研发团队之间对数字的博弈。

所以，流动速率更倾向于用流动项的数量（而非故事点）来进行估算，根据大数定律（如果有足够的试验或实例，事件发生的可能性就是均等的），如果有足够多的流动项，那么在一个时间段内所有流动项都很大，而另一个时间段内的所有流动项都很小的情况，应该很少出现。

另外，对于工作项的合理拆分（如把需求分解为业务需求 - 产品需求 - 技术任务），一定程度上也会降低需求颗粒度的差异对指标准确性带来的影响。如果实在不放心，我们在度量流动速率指标的同时，也可以将需求规模（如开发 + 测试的工作量）作为辅助参考指标一起进行观测。

还需要注意的是，流动速率的度量更适合于跟踪一个价值流内的生产力和交付趋势，而非跨价值流进行比较。

2. 流动时间

图 5：流动时间

• 指标定义：

从流动项被接受并进入价值流，一直到其完成所花费的时间，包括了工作处于活跃状态的时间和等待状态的时间。

• 如何使用：

跟踪流动时间，通过概率思维让交付时间变得更可预测，并相对准确地回答一个核心问题：“工作到底什么时候可以完成?”。根据研究，交付周期类指标一般符合韦伯分布（Weibull Distribution），所以建议使用 85% 分位数（而非平均值）来对流动时间进行度量和预测。

• 指标解读

数值很低：

我们当然希望流动时间不断缩短。但是看到这个数值很低的时候，也别高兴的太早了，要多看看工作有没有被准确跟踪。比如我们在实际工作中，经常出现“后补”需求的情况，比如开发完成到了要上线的时候，因为上线单要关联一个需求单，这个时候再到看板中补上一个需求，然后从第一个阶段直接拖动到最后一个阶段。类似的情况会导致指标的失真，而指标的准确性是度量的根基，我们需要额外关注。在实践过程中，我们经常在观测主指标（如流动时间）的同时，增加一个关于数据健康度的辅助参考指标（如异常数据的比例），以确保主指标的置信度。

数值很高，且流动速率很低：

有可能是因为在制品过多导致的工作切换，或者工作被阻塞，产生了大量的等待时间，让流动时间被拖长。我们可以结合下面的流动负载和流动效率一起进行更细化的分析。

• 常见问题

前置时间、周期时间、流动时间有什么区别？

图 6：流动时间 vs 前置时间

在精益生产中，有两个关键指标用于流程改进，分别是“前置时间”和“周期时间”。前置时间侧重于度量整个流程的时间（工作从“新建”状态开始到“完成”状态之间的时间差），而周期时间则侧重于完成过程中某个步骤所花费的时间（如“开发”阶段的周期时间）。前置时间可以告诉我们端到端流程运行所花费的时间，周期时间可以帮助识别瓶颈（周期时间最长的步骤通常就是瓶颈所在）。

但为了避免混淆，流框架使用了名为“流动时间”的新指标。流动时间始于工作被显式接受（例如新需求评审通过并进入排期）或隐式接受（例如自动升级的事件）的时刻，这与前置时间从工作被提出就开始计时完全不同。流动时间可以作为对产品研发团队交付效率的观测指标，即从确定要做某项工作到完成所需的时间；而前置时间更多是从需求方视角进行观测，即从需求提出到完成所需的时间。

为什么没有采用 DevOps 社区中常用的变更前置时间？

每年的 DevOps 全球调查报告和 DevOps 社区中，经常使用名为“变更前置时间”的度量指标，英文是 Lead time for changes，即代码提交到部署的前置时间。虽然我们也经常采用这个指标进行效能度量和分析，但它并没有被流框架所采纳。

图 7：变更前置时间变更

前置时间更多的是以开发人员为中心的视角，而不是以客户为中心或以价值流为中心的视角进行设计的，所以它并不足以封装业务价值，虽然是团队工程能力的重要指示器之一，但本质上是更偏局部、更偏过程性的指标。而流动时间的视野更广，观测的是工作项在软件交付管道中端到端的流动，是更偏全局、更偏结果性的指标。

流动时间是按自然日来算还是工作日来算？

上文已经讲到，流动时间是一个以客户为中心设计的指标，因此它是以“自然”时间而非“工作日”来进行计算和度量的。

3. 流动负载

图 8：流动负载

• 指标定义：

价值流中在制品的数量（已开始、未完成，即正在进行中的工作），包含了状态为活跃或等待的流动项的数量。

• 如何使用：

流动负载是一个先导性指标，可以用来发现在制品过多对速度类指标和团队满意度的影响。我们可以通过不断调整和实验，找到产品价值流最优的流动负载，此时流动速率较高，并且流动时间较短。流动负载可以让产研团队与业务需求方更好地进行协作，在需求与产能之间寻求平衡。

• 指标解读

数值较低：

可能只有少量的工作正在完成，可能出现了闲置的情况。

数值较高：

过多的流动负载（在制品）很可能会导致交付延迟、成本增加、质量下降、员工抱怨，长期超过团队产能安排工作将导致职业倦怠。还可以进一步分解为以下两种情况。

数值较高，并且流动时间很短：

可能有很多的工作被忽略或搁置了，即存在很多“僵尸需求”，一直停留在交付管道中却又因为优先级一直没有时间处理。这时需要清理在制品，评估真正需要完成的工作。如果真的重要就让工作继续及时推进，如果不重要就干脆把工作移出交付管道。

数值较高，并且流动时间很长：

在制品过多导致的工作切换可能是罪魁祸首，过高的流动负载直接影响了交付效率。这时可以采用精益实践，限制在制品并采用拉动模型（如采用精益看板的方法）。可能还要为资源不足的角色 / 岗位增加容量，或提升自动化的水平。

图 9：基于利特尔法则的流动时间预测

特别需要注意的是，根据利特尔法则，流动时间 = 流动负载 / 流动速率，当流动负载的当前值已经高于（流动速率 * 流动时间）的预测值，则预示未来会有工作无法如期完成。这时就已经发现了未来交付计划及周期的风险，需要对流动时间的预测进行修正，进而实现更准确的承诺 / 决策，这正是先导性指标的价值所在。

• 常见问题

流动负载应该从何处开始计算？尚未开始的工作要计算么？

如果将价值流想象为一条管道，其中所有尚未开始或已经完成的流动项都在管道的两端，而流动负载就是管道内正在进行的工作单元数，包括所有部分完成的流动项。当流动负载过大，由于队列时间过长，价值流的过度利用会极大地影响交付速度。

流动负载有没有绝对数字来说明好坏？

业界很难有一个绝对的数字来说明流动负载应该是多少，不同业务类型、处于不同发展阶段的团队，对流动负载的承受能力都有很大差别。所以，建议采用实验思维，关注流动负载的高低，导致了流动速率和流动时间怎样的变化，从而找到一个适当的平衡点。追求过高的资源饱和度对产品开发而言并没有任何好处。百分之百资源利用率对于制造业和软件交付都存在同样问题，都会对流动速率和流动时间产生很大的负面影响。

流动负载如何进行有效下钻找到具体问题？

可以通过停滞项工作报告，展示在交付管道中有哪些未完成的工作，以及它们在当前阶段已经停滞了多久的时间。

图 10：停滞项工作报告

通过查看系统中指定天数（如 10 天）没有进展的工作，可以发现系统中的问题和瓶颈，一方面找到并消灭较低价值的 “僵尸需求”，减少被搁置的工作；另一方面识别出被阻塞的工作，通过当前阶段及上下游的协同优化，促进它们尽快恢复流动。关于研发过程中的常见瓶颈，我会在下一小节中进行讨论。

4. 流动效率

图 11：流动效率

• 指标定义：

流动项处于活跃工作状态的时间占总消耗时间的比例。

• 如何使用：

度量流动效率，可以帮助团队从瓶颈中可视化等待时间，以便找出导致流动停滞的问题。流动效率越低，工作停滞在等待状态的时间就越长。此指标可以与其他流动指标结合使用，重点聚焦于减少等待时间。

• 指标解读

数值较高：

流动效率越高，一般表明交间，它涵盖了开发上下游的等待时间。如果开发团队在等待用户界面设计，而设计人员被分配到了其他工作，则流动效率会下降，因为相关需求处于等待状态，原因是这两个团队都没有处理它们。因此，可以通过追踪流动效率降低的原因来识别价值流的瓶颈。付过程越顺畅、越没有阻塞。但也要警惕指标过高的情况（例如超过 40%），这可能意味着状态映射错误或不准确，比如把实际上是等待的阶段映射成活跃状态了，这样就会导致这个指标虚高。

数值较低：

一般表明存在瓶颈、低效的流程、过多的依赖关系、资源匮乏等，这些问题会导致流动负载的增加，更长的队列，以及更长的流动时间。

• 常见问题

流动效率基于流动时间还是周期时间来计算？

流动效率是基于流动时间而不是周期流动效率是基于流动时间而不是周期时间，它涵盖了开发上下游的等待时间。如果开发团队在等待用户界面设计，而设计人员被分配到了其他工作，则流动效率会下降，因为相关需求处于等待状态，原因是这两个团队都没有处理它们。因此，可以通过追踪流动效率降低的原因来识别价值流的瓶颈。

流动效率的正常值应该多少合适？

我在行业中经常看到一些统计数据，很多企业的实际流动效率要比想象中低很多，有些采用传统研发模式、规模较大、流程较复杂的团队，流动效率甚至不到 10%。在能进行准确统计的情况下（指标没有虚高），对很多企业而言，如果流动效率达到 30-40%，就已经算是不错的水平了。

5. 流动分布

图 12：流动分布

• 指标定义：

通过显示在给定时间内完成的流动项（特性、缺陷、风险和债务）的比例，来衡量在不同价值创造类别中的实际投入。

• 如何使用：

利用流动分布来为价值流中不同类型的工作带来可见性，这样就可以从优先级的角度看到当前投入的重点在哪里。如果统计出来的流动分布（相当于资源的分配）与业务优先级不一致，则需要进行调整。流动分布通过使资源的分配可见，推动产研团队与业务需求方进行各类工作优先级的权衡，而这里的权衡是一种零和游戏。另外，流动分布随着时间的推移，根据产品所处的阶段，需要进行持续调整和演化。

• 指标解读

缺陷占比很高：

一般表明缺陷和未计划的工作降低了需求交付的能力，对于技术债务的投资可能需要加强。

缺少技术债务和风险的占比：

相关工作被忽视或延后，虽然短期看起来交付的需求多了，但未来可能会出现债务危机。

• 常见问题

每条价值流的流动分布应该如何设置？

流动分布会随着时间的推移，不断发生演化。新产品的价值流通常被调整为最大化需求交付的比例。一旦该产品上市并且有稳定用户，就有必要构建额外的能力来处理可能出现的支持工单和故障，并且还要安排一些工作来减少在随后发布周期中不断积累的技术债务。

以上分别展开介绍了五大流动指标的定义和解读方法，相信大家已经对如何使用它们有一些感觉了。但还有一点需要注意的是，这些指标还是停留在软件交付层面上的，我们还应该将研发工作映射到业务结果。将研发效能度量指标与业务结果关联在一起，可以使用真实的数据来确定相关性，并不断地学习和调整。

常见的业务结果指标包括价值（如收入、年度合同价值、业务活跃用户数等）、成本（如人力成本、运营和基础设施成本等）、满意度（如净推荐值、员工净推荐值）等，考虑到篇幅有限，关于如何将五大流动指标映射到业务指标的方法及案例，本文暂不展开，后面有机会再介绍。

研发过程中的常见瓶颈及解决思路

通过对五大流动指标，我们可以对软件交付过程进行有效的度量和分析，并透视出其中潜在的问题和瓶颈。下面，我们就简单讨论一下研发过程中的常见瓶颈及其解决思路。

1. 稀缺的专家或资源，导致流动受阻

图 13：瓶颈导致流动受阻

• 现象：

某个活跃状态阶段（如 “开发”）存在瓶颈，在此之前的等待状态阶段（如 “待开发”），出现大量堆积工作（在制品数高、周期长）。

• 解决思路：

在存在瓶颈的活跃状态阶段，增加有技能的资源（但临时加人可能会导致额外的负担，反而降低生产力）；对团队成员进行专业技能培训，或是跨专业的横向培训；通过自动化、自服务、流程优化或规范简化解决。

2. 缺乏自动化或工程能力落后，导致效率低下

图 13：缺乏自动化导致的效率低下

• 现象：

人工流程或者主要由人工完成的交互，成为流动的瓶颈；比如代码需要在预发环境测试，但测试资源紧缺，且资源申请不是自服务的，有大量需求堆积在"等待测试"阶段。

• 解决思路：

实现自动化流程，引入自服务机制，提升工程能力；通过自动化手段提升吞吐量，不依赖于资源或专家就绪，从而提升效率；不依赖于某个中心化的团队按优先级完成工作，如发布审批、环境申请等。

3. 繁琐的流程，导致等待和长耗时

图 14：繁琐的流程导致等待

• 现象：

变更审批委员会（如两周举办一次审批会议，无论前面交付多快都要等待）、安全审批、资金审批等；工作处于等待状态，如“等待审批”，处于这些状态的制品数很多，在选定时间范围到达高水位线，而后周期性下降。

• 解决思路：

以高水位线（最大制品数量）为线索，找到瓶颈点问题所在，即使当前数值已经回落。自动化变更审批流程，识别出高风险变更的标准，哪些是必须要走审批，哪些是低风险变更可以自动化验证、直接部署。

4. 过多的依赖，导致工作流动停

图 15：过多的依赖导致流动停滞

• 现象：等待某事或者某人完成后，才能继续工作。

架构依赖（软件或硬件）：一个部分的变更造成另一个部分的功能被破坏（例如 DB 变更导致对方的功能调用无法工作）

专业知识或专家依赖：需要特定专业知识的专家（如业务专家、安全专家）的输入，才能继续完成既定工作

活动依赖或事件依赖：需要等待其他的活动完成，否则流程无法进行。如甘特图里的几个前置任务之间的依赖关系

• 解决思路：

图 16：三种依赖及其解决思路

对依赖建模（如使用依赖矩阵），与依赖方沟通，探索解决方案；长期方案：要花时间去除依赖，而不仅仅是管理它们。架构层面：找到系统的断裂面，进行架构解耦；组织层面：建立跨职能团队，进行组织解耦。活动层面：提升自服务和自主性，进行活动解耦。

最后要说的是，对于研发过程中的瓶颈，我们要通过系统思考，以流动指标为牵引观测整个价值流，以整体的方式思考约束。找到瓶颈并明确解决思路后，在实施改进时，要注意一次只解决一个问题，而不能贪多、追求大而全，这样才能独立观察每项措施带来的效果和影响。

图 17：基于数据驱动和实验思维，一次只解决一个问题

总结

本文核心观点如下：

1. 数字化时代，软件研发本身也要数字化。

2. 研发的数字化，可以从建设有效的研发效能洞察体系开始。

3. 基于精益思想，流动指标度量的就是价值的流动，指征了一个组织交付价值过程中的效率水平和健康程度。

4. 流动指标共有五个：流动速率、流动时间、流动负载、流动效率和流动分布。

5. 综合利用好这五个指标，我们就可以讲述一个关于软件研发价值流完整的故事，回答关于研发交付效率如何的本质问题。

6. 研发过程中的常见瓶颈包括稀缺的专家或资源、缺乏自动化或工程能力落后、繁琐的流程、过多的依赖等，这些瓶颈都会导致流动受阻、让工作陷入停滞，导致等待和长耗时。

7. 对于研发过程中的瓶颈，我们要通过系统思考，以流动指标为牵引观测整个价值流，以整体的方式思考约束。

8. 实施改进时，一次只解决一个问题，这样可以独立观察每项措施带来的效果和影响。

作者介绍

张乐

腾讯 技术工程事业群 DevOps 与研发效能资深技术专家，前百度工程效率专家、前京东 DevOps 平台产品总监与首席架构师，曾任埃森哲、惠普等全球五百强企业咨询顾问、资深技术专家。长期工作在拥有数万人研发规模的一线互联网公司，专注于研发效能提升、敏捷与 DevOps 实践落地、DevOps 工具平台设计、研发效能度量体系建设等方向，是 DevOpsDays 国际会议中国区核心组织者，国内多个 DevOps、工程生产力、研发效能领域技术大会的联席主席、DevOps/ 研发效能专题出品人，是《研发效能宣言》发起人及主要内容起草者，EXIN DevOps 全系列国际认证授权讲师、凤凰项目沙盘授权教练。著作：《软件研发效能提升实践》、译著：《独角兽项目：数字化转型时代的开发传奇》