只要五步，研发效能度量就能成功落地！

研发效能度量的成功落地需要一个相对完善的体系，其中包含数据采集、度量指标设计、度量模型构建、度量产品建设、数据运营等多个方面，我把它们整理出来形成一个实践框架，称为“研发效能度量的五项精进”。1. 构建自动采集效能数据的能力

通过度量系统分层处理好数据接入、存储计算和数据分析。比如，小型团队通过 MQ、API 等方式把数据采集起来之后，使用 MySql（存放明细数据和汇总数据）、Redis（存放缓存数据）、ES（数据聚合和检索分析）三件套基本就够用了；而大规模企业由于数据量庞大、汇聚和分析逻辑复杂，建议使用整套大数据分析解决方案，比如流行的一体化大数据分析架构。

2. 设计效能度量指标体系

选取全局结果指标用于评估能力，局部过程指标用于指导分析改进。比如：需求交付周期、需求吞吐量就是全局结果指标，可用于对交付效率进行整体评估；交付各阶段耗时、需求变更率、需求评审通过率、缺陷解决时长就是局部过程指标，可用于指导分析改进。

通过先导性指标进行事前干预，通过滞后性指标进行事后复盘。比如：流动负载（在制品数量）是一个先导性指标，根据利特尔法则，在制品过高一定会导致后续的交付效率下降、交付周期变长，所以识别到这类问题就要进行及时干预；而线上缺陷密度就是一个滞后性指标，线上缺陷已经发生了，我们能做的就只有复盘、对缺陷根因进行分析，争取在下个统计周期内能让质量提升、指标好转。

3. 建立效能度量分析模型

这里的模型是指对研发效能问题、规律进行抽象后的一种形式化的表达方式。比如流时间（需求交付周期）、流速率（需求吞吐量）、流负载、流效率、流分布这五个指标结合在一起，就是一个典型的分析产品 / 团队交付效率的模型，通过这个模型可以讲述一个交付交付价值流完整的故事，回答一个关于交付效率的本质问题。

模型还有很多种，比如组织效能模型（如战略资源投入分布和合理性）、产品 / 团队效能模型、工程师效能模型等，我们还要合理采用趋势分析、相关性分析、诊断分析等方法，分析效能问题、指导效能改进。

4.  设计和实现效能度量产品

将数据转化为信息，然后将信息转化为知识，让用户可以自助消费数据，主动进行分析和洞察。

简单的度量产品以展示度量指标为主，比如按照部门、产品线等维度进行指标卡片和指标图表的展现；做的好一点的度量产品可以加入各种分析能力，可以进行下钻上卷，可以进行趋势分析、对比分析等；而做的比较完善的度量产品应该自带各种分析模型和逻辑，面向用户屏蔽理论和数据关系的复杂性，直接输出效能报告，并提供问题根因分析和改进建议，让对效能分析不是很熟悉的人也能自助地使用。

5.  实现有效的效能数据运营体系

也许放在最后的其实才是最重要的，我们有了度量指标、有了度量模型、有了度量产品，但一定要注意的是：要避免不正当使用度量而产生的负面效果，避免将度量指标 KPI 化而导致“造数据"的短视行为。根据古德哈特定律，度量不是武器，而是学习和持续改进的工具。

正所谓“上有政策，下有对策"，“度量什么就会得到什么"，为了避免度量带来的各种副作用，我们首要的度量对象应该是工作本身，而不是工作者。另外，效能改进的运作模式也很重要，只是把数据报表放在那里效能不会自己变好，需要有团队或专人负责推动改进事宜。

研发效能度量的指标体系设计

根据研发效能度量的七大原则，我们确定了从全局性出发，以结果产出为牵引的一系列研发效能度量指标 。这些指标也反映出了研发效能改进的关键点，即以端到端的流动效率（而非资源效率）为核心。这里的流动效率是指需求（或用户价值）在整个系统中跨越不同职能和团队流动的速度，速度越快则需求交付的效率越高、交付时长越短。当然我们并不是只关注流动效率、不关注资源效率（如工时、资源利用率等），而是 在确保前者效率足够高的情况下再逐步提升后者，最终追求的是二者的协同优化。

在建设初期，我们把研发效能度量指标分为三个维度，分别是交付效率、交付质量和交付能力。这些指标的提升需要组织进行管理、工程、技术等多方面的系统性改进

1. 交付效率

目标是促进端到端、及早的交付，用最短的时间顺畅地交付用户价值。具体可细分为以下指标：

• 需求前置时间：也称为需求交付周期，是指从需求提出，到完成开发、测试，直到完成上线的时间周期。反映了整个团队（包含业务、产品、开发、测试、运维等职能）对客户问题或业务机会的交付速度，依赖整个组织各职能和部门的协调一致和紧密协作。从数据统计的角度来看，需求前置时间指标通常符合韦伯分布，我们要尽量避免度量的平均值陷阱，建议使用 85 百分位数进行统计分析，相关细节将在后续文章中展开说明。
• 产研交付周期：从需求被产研团队确认，到完成开发、测试，直到完成上线的时间周期。反映了产研团队的交付速度，依赖需求的拆分和管理，研发团队的分工协作。
• 需求吞吐量：统计周期内交付的需求个数 / 统计周期，即单位时间交付的需求个数。需要注意的是，需求颗粒度要保持一定规则（如约定业务需求、产品需求的颗粒度上限），避免需求大小不统一导致的数据偏差。

2. 交付质量

目标是促进端到端高质量交付，避免不必要的错误和返工。具体可细分为以下指标：

• 线上缺陷密度：统计周期内线上或单个版本严重级别 Bug 数量 / 需求个数。
• 故障恢复时间：线上系统和应用如果发生故障，多长时间可以进行恢复。
• 变更成功率：上线部署成功，且没有导致服务受损、降级或需要事后补救的比例。

3. 交付能力

目标是建设卓越的工程能力，实现持续交付。具体可细分为以下指标：

• 部署频率：单位时间内的有效部署次数。团队对外响应的速度不会大于其部署频率，部署频率约束了团队对外响应和价值的流动速度。

• 变更前置时间：代码提交到功能上线的时长。反映了团队的工程技术能力，依赖交付过程中高度自动化以及架构、研发基础设施的支撑能力。

我们落地的任何研发效率提升实践，推动的任何敏捷或 DevOps 转型，其目标都应该要促进交付效率、交付质量、交付能力中一个或多个要素的提升，而其中交付能力的提升通常需要一定的周期沉淀和积累，所以是延迟反馈的，但最终还是会体现在效率或质量的提升上。

交付效率、交付质量、交付能力的提升会推动软件研发效能的提升，而研发效能的提升最终会助力组织效能的提升和业务结果的优化。所以，我们在设计度量指标体系时，还应该增加业务结果维度的考量，包括业务价值、交付成本和满意度（包括客户满意度 NPS 及员工满意度 eNPS）。这样的指标体系才更完整，才更能体现出研发效能提升对于组织效能提升的贡献。所以，完整的指标维度设计应该是“3+1”的形式，即三个研发交付的维度，再加上一个业务结果的维度。

研发效能度量指标体系的设计还要结合组织中实际的研发价值流，并且在三个研发交付指标维度的基础之上，更多地考虑到价值的流动性，并增加相关的度量指标。下图展示了某互联网大厂典型的研发价值流，并且由此扩展出来一些新的度量指标项。

在图中，我们可以看到存在两层价值流。第一层是需求价值流，流动的单元是业务需求，这是业务人员的核心关注点，目标是业务需求交付的效率和效果。主要节点包括：需求创建、需求受理、需求拆分和处理、需求开发测试并发布上线、需求发起验收，业务验收通过。第二层是产品交付价值流，流动的单元是业务需求拆解到叶子节点后形成的产品需求，目标是提高产品需求的持续交付能力，包括效率、质量和可预测性。产品需求由具体的敏捷交付团队承接，经过准备、评审、就绪、设计、开发、测试、发布等状态，直到完成。两层价值流之间存在承接和对齐的关联关系，产品需求的研发状态会回溯到业务需求层面进行信息同步。

根据图中不同阶段的起始点，我们定义了多个周期类指标，包括端到端的交付周期和某个分段的交付周期。我们之前用文字描述的需求前置时间、产研交付周期在图中就可以展示的非常清晰。另外，我还特别绘制了一个虚线的管状图形，覆盖从需求受理到发布上线的过程，这就是我们重点要关注的交付管道。除了交付周期类指标（也称流时间）外，这里还有几个指标值得单独说明下：

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

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

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

流时间、流速率、流分布、流负载、流效率这五个指标结合在一起，就是一个典型的分析产品 / 团队交付效率的模型，通过这个模型可以讲述一个关于研发价值流完整的故事，回答一个关于交付效率的本质问题。

截止到目前，我已经介绍了研发效能度量的一些比较关键的指标，这些指标通常已经能够用来评估产研团队的整体交付效率、交付质量和交付能力了。但是，我们不满足于可以评估效能，还要从宏观到微观一层层地下钻下去，找到那些影响效能的阻碍因素，这样才能针对性采取改进措施，让组织获得效能提升。因此，我整理了一张研发效能度量指标的“全景图”，希望对你有所帮助。

在图中，我以一种矩阵的形式来组织研发效能度量指标。纵轴是软件研发生命周期的各个阶段，横轴是研发效能度量的三大维度，矩阵中罗列了相关指标及其适用范围。图中实心的方框是偏结果性的指标，其他是偏过程性的指标。在落地过程中，我们的指标全集持续累积，实际上要多于图中展示的这些内容，这里只是给出一个示例，你可以结合所在组织的上下文进行进一步的增减和调整。

除了以上指标，还有很多实践中常用的指标，这里选取一部分介绍下：

• 需求规模。 用于描述需求的颗粒度，计算公式为：统计周期内交付的需求总研发工作量 / 需求个数。这个指标反映了产研团队需求拆分情况。对于单一团队来讲，需求规模保持相对稳定，需求吞吐量指标才具备参考意义。
• 需求变更率。 统计周期内，发生变更的需求数与需求总数的占比。这个指标通过度量开发、测试过程中变更的需求数来达到衡量需求质量的目的。注意，这里的需求变更统计的是需求达到了就绪状态之后才发生的变更，主要用于反馈开发活动中实际发生的摩擦，这与敏捷拥抱变化的原则并不冲突。
• 需求按时交付率。 统计周期内交付的需求中，满足业务方期望上线日期的需求个数占比。这个指标反映了在用户的视角下，产研团队是否在全力为满足业务方的上线需求而努力。
• 技术债率。 技术债率是仓库维度的统计数据。计算公式为：预计技术债务修复时长占开发所有代码所需时间的比例。这个指标是有效衡量代码质量的一种方法，反映了因快速开发暂时不顾代码质量所产生的技术债比率，而技术债会不断降低开发效率。技术债本身无法在不同仓库之间比较，因为各个仓库大小各不相同，但技术债率就可以进行横向比较，因为比率是相对的。根据技术债率可以进行仓库的评级，对于直观体现仓库状况非常有帮助。关于这个指标更详细的信息可以参考：SQALE (Software Quality Assessment Based on Lifecycle Expectations) 相关方法。
• 单元测试覆盖率。 通过统计单元测试中对功能代码的行、分支、类等场景覆盖的比率，来量化说明测试的充分情况。
• 平均缺陷解决时长。 用于描述研发修复线下缺陷的平均时长，计算公式为：统计周期内缺陷的总解决时间 / 缺陷数量。这个指标体现了研发解决线下缺陷的效率。
• 代码评审覆盖率。 在主分支上，代码评审覆盖的提交数 / 总提交数。这个指标体现了研发质量内建活动中代码评审的总体执行情况，即有多少比例的提交被代码评审所覆盖。
• 项目收益达成率。 收益指标全部完成的项目数 / 收益指标验证时间在所选周期内的项目数。这个指标衡量了项目的各项预期收益指标的达成情况。

• 项目满意度评价。 以项目为维度，对该项目的整体过程进行评价，评价分为两层：第一层为总体满意度评价，用于对团队的整体交付情况进行评价；第二层为具体分类评价，用雷达图进行呈现，分类评价可用于收集改进意见，发现短板从而进行改进；分类评价包括但不限于以下几方面：需求管理、进度管理、成本管理、沟通管理、风险与问题管理、验收测试、上线质量、上线后支持、开放性问题等。

实践者的常见困惑

在指导团队进行指标设计的过程中，经常会遇到一些实践者的疑问，这也代表了一些对指标选取的常见困惑，主要有以下几点：

• 需求吞吐量是按需求个数算还是按故事点计算？

针对这个问题，我建议还是应该按照需求个数来计算。敏捷中我们经常使用故事点来评估工作量的大小，大家已经使用的很成熟了。但故事点实际上是一种敏捷规划的工具，不建议作为需求吞吐量中关于需求规模的度量指标来使用。因为不同团队对于同样颗粒度大小的需求，所估算的故事点是不同的，所以不具备普适性和横向的可比性。

另外，如果使用故事点来作为需求规模的度量指标，还会导致让研发人员产生规模冲动，想办法来增加估算的点数。这种行为又会导致业务人员 / 产品经理与研发之间产生不信任，对故事点数进行讨价还价和合同谈判的行为，从而导致了更多的问题。所以，一种比较建议的方式是，由产品经理和研发人员一起将需求拆分成颗粒度相对均匀的需求条目，然后用需求个数来表示需求规模，计算需求吞吐量。

• 需求吞吐量计算时，需求大小不一怎么办？

这个问题其实紧接着上一个问题，如果使用需求个数来标识需求规模，计算需求吞吐量，那需求大小不一怎么办？这里的答案依然是需求的合理拆分，比如有的企业使用“业务需求 - 产品需求 - 技术任务”的三级需求层次模型来进行需求的分解，每一层的工作项条目都可以定义颗粒度范围，形成大小相对均匀的条目。比如业务需求最好能在一次发布中完成，产品需求最好在一个迭代内完成（如最多不超过 10 人天工作量），技术任务最好让研发能快速完成（如不超过 3 人天工作量）。

把需求拆分为不同层次、相对均匀的工作项条目，一方面解决了度量准确性的问题（每个不同的层次可以分别统计），另外还有一个附加的好处是，这个指标会促使研发人员更有动力去更细地拆分需求，但 这个副作用是对整个组织有利的，因为更小的需求可以更快地交付业务价值，这也是敏捷和精益思想中所提倡的。

当然，最终拆分出来的需求大小也不可能完全一样，但是根据大数定理，只要样本足够多就能屏蔽个体的差异性而体现出整体的规律性。再者说，我们也不会只使用需求吞吐量这个单一指标去度量研发效能，而是结合交付周期类等一系列指标进行综合评估，所以也不必对这个指标的计算过于纠结。

• 为什么度量变更前置时间，有什么意义？

前文中我们也提到，变更前置时间度量的是代码提交到功能上线的时长。这个指标的意义在于它反映了团队的工程技术能力。软件研发不同于生产制造行业，后者在设计和生产计划制定后，基本上都是大规模、重复性、机械性的生产过程。而软件研发过程实际上可以分为两类活动：（1）创造性活动，比如基于业务需求进行创造性的设计和编码；（2）重复性活动，比如代码提交后进行重复性的构建、测试和部署。而第二个部分就是工程实践擅长的领域。

软件研发同时受益于敏捷和精益方法。软件的二进制文件是敏捷方法创建的，而通往生产环境的路径是精益的，因为构建、测试、部署流程应该每天多次重复运行，并且具有高度的自动化。软件就是一种在精益流水线上，敏捷创建的盒子。

我们可以问自己一个问题，如果你只修改了一行代码，那么从代码提交到上线需要多少时间？是几分钟，一个小时还是数天的时间？如果我们还在采用大量手工部署、手工测试、手工配置、复杂的审批流程，即使一行代码的变更也需要很久才能上线。所以回到问题本身，我们为什么要度量变更前置时间？因为我们希望通往生产环境的路径是精益的，这条路是被工程实践优化过的。所以，这个指标可以很好反应出团队的工程技术能力，让我们持续追求工程卓越（Engineering Excellence）。

• 为什么度量平均故障恢复时间，而不是平均无故障时间？

在度量系统可靠性方面，有三个常见指标，分别是：MTTR、MTTF 和 MTBF。MTTF (Mean Time To Failure，平均无故障时间)，指系统无故障运行的平均时间，度量的是从系统开始正常运行到发生故障之间的时间段的平均值。MTTR (Mean Time To Repair，平均故障修复时间)，指系统从发生故障到修复完成之间的时间段的平均值，度量的是系统出现问题后恢复的速度。MTBF (Mean Time Between Failure，平均失效间隔)，指系统两次故障发生时间之间的时间段的平均值。MTBF= MTTF+ MTTR。

在这三个指标中，为什么我们选用的是平均故障恢复时间（即 MTTR）呢？因为我们知道，在快速变更的复杂系统中，出错和故障是在所难免的。软件研发和运维的复杂性已经不仅限于系统架构的复杂性，还有像大型成熟企业普遍存在的历史包袱，新旧系统之间大量的信息通讯，复杂业务连接的多个不同系统，海量数据的计算与管理，跨团队协同等都可能是未知故障的触发点。所以核心的问题不是系统多长时间才出现故障，而是出现问题后如何快速恢复服务。

所以，在接受了系统的复杂性与不确定性的前提下，业界一般优先选用平均故障恢复时间作为系统可靠性的核心度量指标。包括近年来流行的混沌工程，也是在追求如何实现复杂系统的韧性，这与我们度量指标的选择也是非常契合的。

小  结

以上我们介绍了度量指标体系的设计思路，也展开对一些指标进行了详细说明。但是，这些度量指标并不是孤立存在的，它们之前存在很多相关性关系。如何综合选取适当的指标，并运用一系列统计分析方法进行效能的分析，才是用好这些指标的关键。我们将在下一节中详细讲解效能度量分析方法相关的内容。敬请期待！

作者介绍：

张乐，DevOps 与研发效能资深实践者，长期工作于拥有数万研发的互联网大厂（百度、京东等），主攻敏捷与 DevOps 实践、DevOps 平台建设、研发效能度量体系设计等方向，历任资深敏捷教练、DevOps 平台产品总监、研发效能度量标准化联盟负责人等岗位。长期活跃于技术社区，目前是 DevOps 起源国际组织 DevOpsDays 中国区核心组织者，同时也是国内多个技术峰会的联席主席、DevOps/ 研发效能专题出品人、特邀演讲嘉宾。EXIN DevOps 全系列国际认证授权讲师、凤凰项目 DevOps 沙盘国际授权教练。历任埃森哲、惠普等全球五百强企业资深咨询顾问、技术专家，多年敏捷与 DevOps 转型、工程效率提升和大型项目实践经验。畅销书《独角兽项目：数字化时代的开发传奇》译者。

链接参考：

（双11到来，满100减50特惠开始）

（识别二维码，直接购买）