软件研发效能需求价值流分析专题

本文正文内容共计 3560 字，建议阅读时间：7 分钟。

本文主要内容：

1、需求价值流分析概述

2、需求价值流分析的五大核心指标

3、需求价值流具体分析过程

4、 需求价值流分析的注意事项

作者简介

张乐，腾讯技术工程事业群 DevOps 与研发效能资深技术专家，多年一线互联网大厂工程效率领域工作经历（百度、京东等）历任埃森哲、惠普等全球五百强企业资深咨询顾问、技术专家长期工作在一线，专注于研发效能提升、敏捷与 DevOps 实践落地、万人研发规模 DevOps 平台设计、研发效能度量体系建设等方向；

本文来源：张乐老师的研发效能系列文章，本文全篇收录于 QECon 组委会发布的白皮书之《研发效能实践指南》

研发效能度量有很多难点和误区，我们要尽量多吸取行业经验、少走弯路，同时也要更加重视度量体系的系统性建设，并通过适当的方式进行运营，把度量引导的正确的方向上。

01. 需求价值流分析概述

研发效能度量指标可以很多，但如何用好这些指标分析研发过程中的具体问题才是关键。如果一种度量真的很重要，那是因为它可以对决策和行为产生一些可以想象的影响。

在本文中，我们就详细讲解一下如何通过需求价值流分析全面评估需求研发交付的效率，发现其中隐藏的问题和瓶颈点，并针对数据反馈出的信息采取针对性的行动，从而促进效能提升。

‍

02. 需求价值流分析的五大核心指标

图 1：某大型互联网公司典型的需求价值流上图展示了某大型互联网公司的需求价值流，我们可以通过对其进行梳理，形成对需求交付过程清晰的认识。我们可以看到存在两层价值流。

●第一层是需求价值流。

流动的单元是业务需求，这是业务人员的核心关注点，目标是业务需求交付的效率和效果。主要节点包括：需求创建、需求受理、需求拆分和处理、需求开发测试并发布上线、需求发起验收，业务验收通过。

●第二层是产品交付价值流。

流动的单元是业务需求拆解到叶子节点后形成的产品需求，目标是提高产品需求的持续交付能力，包括效率、质量和可预测性。产品需求由具体的敏捷交付团队承接，经过准备、评审、就绪、设计、开发、测试、发布等状态，直到完成。两层价值流之间存在承接和对齐的关联关系，产品需求的研发状态会回溯到业务需求层面进行信息同步。根据这个典型的价值流，我们可以定义五个核心的度量指标，分别是：流时间（需求前置时间）、流速率（需求吞吐量）、流负载、流效率、流分布。这五个指标结合在一起，就是一个典型的分析产品/团队交付效率的模型，通过这个模型可以讲述一个需求交付价值流完整的故事，回答一个关于需求交付效率的本质问题。●流时间：也称为需求前置时间，是指从需求提出，到完成开发、测试，直到完成上线的时间周期。反映了整个团队（包含业务、产品、开发、测试、运维等职能）对客户问题或业务机会的交付速度，依赖整个组织各职能和部门的协调一致和紧密协作。从数据统计的角度来看，需求前置时间指标通常符合韦伯分布，我们要尽量避免度量的平均值陷阱，建议使用 85 百分位数进行统计分析。

●流速率：单位时间内流经交付管道的工作项数量就是流速率，也就是我能常说的需求吞吐量。

●流分布：单位时间内流经交付管道的需求中，不同工作项类型的占比（包括需求、缺陷、风险、技术债等）就是流分布，这个指标可以衡量团队工作量是花在开发新需求、被动救火还是主动解决技术债上，对于工作计划的合理分配有一定指导意义。

●流负载：在交付管道中已经开始、尚未完成的工作项的数量就是流负载，其实就是我们经常说的在制品数量。流负载是一个关键的先导性指标，流负载过高一定会导致后续的交付效率下降、交付周期变长，所以识别到这类问题就要进行及时干预。

●流效率：在交付管道中工作项处于活跃工作状态的时间（无阻塞地工作）与总交付时间（活跃工作时间 + 等待时间）的比率就是流效率。调查表明，很多企业的流效率只有不到 10%，也就意味着需求在交付管道中有大量时间都处于停滞、阻塞、等待的状态，以至于看似热火朝天的研发工作，很可能只是虚假繁忙。大家只是因为交付流被迫中断，所以切换到其他工作，从而并行开展了很多不同的工作而已，从业务和客户的视角来看，需求交付效率其实很低。

‍

03. 需求价值流具体分析过程

‍

下面我们分别看下流时间、流负载、流效率这三个核心指标是如何进行具体分析和问题排查的。

3.1 流时间分析

首先我们来看流时间的分析。在度量领域有个关键实践，即趋势比绝对值更能说明问题。每个组织、每个部门、每个团队、每个人都有不同的起点和上下文背景，对度量指标的绝对值进行横向比较很可能有失偏颇。针对每个独立的个体来说，度量其随时间推移的变化趋势更能获取到有效的信息。

图 2：流时间的趋势图上图是某个部门推进需求交付效率分析时绘制出来的趋势图。可以看到，在 2019 年 7 月份之前，随着时间的推移，交付周期持续处于上升趋势，即交付需求越来越慢。在进行复盘时，当时的管理者识别到了这一问题，虽然大家工作看起来很繁忙（资源利用率很高），但从业务或客户的角度来看，研发效率的体验却在持续下降（流动效率降低）。

‍

于是，当时管理者就决定指派专人负责研发效能的诊断分析和提升工作，对交付周期问题直接进行干预，通过一系列改进措施扭转这个趋势。在图中红圈位置是一个转折点，交付周期在 2019 年 8 月之后有了明显下降，说明所采取的干预措施是有效果的，在度量的指导下发现并处理了问题，最终该部门效能得到了提升。在对流时间这个指标进行针对性优化的过程中，我们为了能够进一步发现问题，采用了多种下钻分析的方法。

‍

‍●按照阶段下钻从约束理论的角度来看，交付管道中至少会存在一个约束因素，限制了全局流动效率的潜能。但这个约束具体是在哪个阶段，很可能与我们预想的完全不同。

图 3：流时间的按照阶段下钻在上图中，把流时间按照阶段下钻之后形成了一张柱形图。可以看到，需求的平均开发周期在 5 天左右，其实并不算很长，但前面有一个开发等待周期也接近 5 天，另外还有多个阶段的平均耗时接近甚至高于开发周期。比如测试阶段耗时超过 9 天，方案及 PRD 阶段耗时接近 6 天。

‍

在精益理论中，我们可以把活动分为三类：增值的活动（如写代码等）、非增值但必要的活动（如测试等）、浪费（如等待、缺陷导致的返工）。我们要最大化增值的活动，优化非增值但必要的活动，消除不必要的浪费。那么在这个案例中，我们就找到了改进的大致方向，再结合其他指标进一步进行问题排查，应该就可以得出有针对性的优化策略。

‍

‍●按照部门下钻在分析效能问题时，很多时候是自上而下进行的，比如先看到整个公司的效能情况、各个部门的横向对比，然后再进行逐层下钻，一直到子部门、团队层级，甚至下钻到数据明细，从而从宏观到微观进行问题根因分析。

图 4：流时间的按照部门下钻在上图中，我们可以得到把流时间下钻到所选部门的下一级部门、下两级部门、下三级部门的数据图表，最终钻取到具体的明细数据。然后可以按照交付周期的长短对所选范围内的需求进行排序，并查看这些需求的交付过程和状态流转的细节，针对性分析影响效率的问题所在，寻求改善的抓手。

‍

3.2 流负载分析

‍

流负载是在交付管道中已经开始、尚未完成的工作项的数量，也就是我们经常说的在制品数量。流负载是一个关键的先导性指标，流负载过高一定会导致后续的交付效率下降、交付周期变长，所以识别到这类问题就要进行及时干预。

图 5：流负载分析上图给出了我在一个团队中落地流负载度量和分析时的一个案例，可以看到产研团队流负载比上个统计周期提升了 43%，而相同周期内的产研交付周期环比提升了近 20%。从实际统计数据来看，这两个指标之间存在关联关系，流负载的升高影响了交付周期的上浮。但这两个指标之间并没有像公式一样存在那种精确的数学关系，这是因为影响交付周期的因素本来就很多，我们无法像在实验室中一样屏蔽掉所有其他因素的影响，而只观察这两个指标之间的关系。

‍

另外，流负载的升高对于交付周期的上浮存在延迟反馈，积压的需求可能并没有在当前统计周期内完成，也就并没有进入到交付周期的数据统计范围内。看到了流负载比较高，我们可以使用在制品下钻方法排查一下具体的工作项，是否有很多需求被阻塞住了。

图 6：在制品下钻分析上图中通过层层下钻，我们可以看到在制品的详细情况，它们目前分别处于什么样的阶段，在当前阶段已经滞留了多长时间。如果做得更好一些，可以计算出来工作项在每个阶段平均的滞留时长作为参考值，如果发现有些工作项滞留超过了平均时长，就需要特别进行关注，进一步分析是什么因素导致的阻塞，然后迅速采取行动，想办法恢复阻塞工作项的流动。

‍

3.3 流效率分析

‍

流效率就是在交付管道中，工作项处于活跃工作状态的时间（无阻塞地工作）与总交付时间（活跃工作时间 + 等待时间）的比率。经验表明，很多企业的流效率只有不到 10%，也就意味着需求在交付管道中有大量时间都处于停滞、阻塞、等待的状态。我们可以结合 DevOps 平台中的看板工具，将待评审、就绪（待开发）、待测试、待发布等阶段的属性设置为”等待”，而需求沟通、需求评审、方案设计、开发、测试、发布等阶段的属性设置为”活跃”，这样就可以得到研发过程的基础数据，对流效率指标进行计算。

图 7：流效率分析上图给出了我在某部门落地流效率度量和分析时的一些实施细节，通过对指定范围内团队的看板进行统一配置，明确各个阶段的准入准出，规范各个团队的操作规范，就可以得到流效率的度量数据。然后，我们通过对在制品数量进行控制、推进小批量交付和一系列最佳实践的引入，优化了研发阶段的等待时间，让流效率获得了一定的提升。

04. 需求价值流分析的注意事项

在这里有个问题需要特别注意，就是数据准确性的问题。需求价值流分析中的很多数据都是依据看板工具进行各个研发阶段耗时统计的，那么我们就要考虑看板中的工作项状态与实际工作状态如何保持一致。当然，办法还是有的。比如，我们可以依靠规范的宣贯和执行的监控，确保数据相对准确（例如至少在每日站会的时候确保工作项状态及时更新），但更为有效的办法是通过自动化的手段，在工作项与代码关联后，研发人员后续的一系列基于代码的提交、合并、提测、上线等动作可以自动联动更新工作项的状态等。本文主要是介绍需求价值流分析的方法，属于管理角度的度量分析。但对于研发效能来讲，从工程角度进行分析（如代码、CI、测试等专项的分析）也是非常必要的，在下一章节中我们会进行详细介绍。

——结束——

如果您想了解更多关于研发效能的内容，可查看思码逸网站获取；

思码逸 Merico 研发效能数据平台，致力于帮助研发团队解决研发效率、研发质量和人才发展三大痛点，提升研发效率与软件工程质量；

欢迎在评论区交流探讨！