如何衡量研发效能？阿里资深技术专家提出了5组指标

导读：新的一年，相信很多产品技术团队把研发效能提升列为重要的目标，甚至还有团队为此专门成立了项目组。然而，到底什么是好的研发效能，却很少有人能够表达清楚。标准不清晰，又何谈提升？

今天，阿里研发效能部资深技术专家何勉老师，将与大家分享他多年的思考与观点，希望对你有所启发。

本文将明确定义研发效能，并提供度量的五大指标，为研发效能的提升指明目标，并衡量提升的效果。本文也是关于研发效能提升及产品交付方法系列文章的开篇，为之后介绍的产品交付方法是否有效设立了标准。

效率竖井是研发效能改进的最大问题

产品交付需要前后职能（如：产品、开发、测试等）和平行部门（如：前端、后端、算法等）的协作。传统方法更多关注各个职能和部门的独立改进。然而，过度局部优化，往往导致效率竖井，反而损害整体效率。

什么是效率竖井呢？上图描述了传统开发方式下，产品交付面临的普遍困境——各职能和部门局部优化带来一系列问题，如：

基于局部信息的工作优先级安排，造成不同部门和职能间相互等待，让需求无法顺畅流动。比如前、中、后台对工作的优先处理不一致，进度无法对齐，让已经开始的需求不能及时交付。

批量式的工作移交，带来进一步等待。为了最大化单个环节的效率，各职能往往倾向于批量接受和移交工作，如批量的集成，批量的转测等。进一步造成需求在过程中的积压和等待。

跨部门的问题，经常得不到及时和有效的处理。公共环境的维护，就是一个典型的问题，是影响用户需求的顺畅交付。过程中需求跨部门的有效澄清、接口对齐、问题排查是另一些常见的公共问题，它们都会造成需求无法顺畅进展。

以上只是一部分问题，它们共同作用，结果是：站在各自的视角，每个部门都觉得自己繁忙且“高效”；然而，站在全局和业务的视角，系统对外的反应却非常迟缓。这就是所谓效率竖井。

效率竖井：由局部优化导致，表现为：各个环节和部门繁忙而“高效”，但总体的效率和响应速度却很低。它是研发效能提升的普遍症结所在。

上图的折线反映了效率竖井下，单个需求的交付过程。绿色线表示需求正在被处理，红色线则表示需求在等待中。工作量不大的需求，交付周期却很长。因为大部分时间需求都处于等待状态。各个局部一片繁忙，外部却抱怨连连，相信很多人会感同身受。

“持续快速交付价值的能力”是效能改进的核心目标

要改进研发效能，我们必须走出效率竖井。为此组织必须把改进的焦点从关注各个资源环节，转向关注整个系统。

上图反映了效能改进的关键——从以局部资源效率为核心，转变为价值流动效率为核心的改进。

资源效率指的是，各环节的资源利用率和产出情况，如：资源的忙闲程度、使用率、代码产出和测试执行速度等。流动效率指的是，用户价值在系统中的流动速度，如：用户需求从提出到交付的时长，它越短越好；或者是过程中等待时间的占比，它越小越好。

用户价值的流动是串起整个系统，促进整体优化的不二选择。为了提高价值的流动效率，组织就必须关注用户价值在系统中端到端的流动过程，改进整个系统，而不仅仅是局部环节。以此为基础，效能改进的目标是：持续快速交付价值的能力。这也是对研发效能的基本定义。

持续快速交付价值的能力，是研发效能的核心定义。为此我们必须把改进的焦点从局部资源效率，转向价值流动效率，以保证全局和系统的优化。

研发效能的度量——五组指标回答研发效能的根本问题

以上定性的定义了研发效能。管理学之父德鲁克说：“如果你不能度量它，就无法改进它”。度量帮助我们更深刻认识研发效能，设定改进方向，并衡量改进效果。

产品开发过程中会产生大量的数据，但数据不是度量。好的度量的标准是：它要为回答一个根本的问题讲述完整的故事。效能度量要回答的根本问题就是：一个组织“持续快速交付价值的能力”怎么样？

为回答这个问题，应该提供怎样的一个完整故事呢？基于在天猫新零售、闲鱼、优酷、阿里健康、研发中台、阿里云等部门持续实践和探索，我们发展并验证了系统的研发效能指标体系。如上图所示，它由5组指标构成，分别是：

第一：持续发布能力。具体包含两个细分指标，分别是：

发布频率。 团队对外响应的速度不会大于其交付频率，发布频率约束团队对外响应和价值的流动速度。它的衡量标准是单位时间内的有效发布次数。

发布前置时间（也被称为变更前置时间），也就是从代码提交到功能上线花费的时间，它体现了团队发布的基本能力。如果时间开销很大，就不合适加大发版频率。

第二：需求响应周期。具体包含两个细分的指标，分别是：

交付周期时间。指的是从确认用户提出的需求开始，到需求上线所经历的平均时长。它反映团队（包含业务、开发、运营等职能）对客户问题或业务机会的响应速度；

开发周期时间。指的是从开发团队理解需求开始，到需求可以上线所经历的平均时长。它反映技术团队的响应能力。

区分交付周期和开发周期，是为了解耦并明确问题，以做出针对性的改进。其中，交付周期是最终的目标和检验标准。

第三：交付吞吐率。指的是单位时间内交付需求的数量。关于这一点，常见的问题是，个数能准确反映交付效率吗？这是个问题。所以，我们更多强调单个团队的需求吞吐率的前后对比，统计意义上它足以反映趋势和问题。

第四：交付过程质量。它包含两个细分的指标，分别是：

开发过程中缺陷的创建和修复时间分布。我们希望缺陷能够持续和及时地被发现，并且在发现后尽快修复；

缺陷库存。我们希望在整个开发过程中控制缺陷库存量，让产品始终处于接近可发布状态，奠定持续交付的基础。

交付过程质量的核心是内建质量，也就是全过程和全时段的质量。而非依赖特定的阶段，如测试阶段；或特定的时段，如项目后期。内建质量是持续交付的基础，关于其具体度量方法，下文会给出详细实例。

第五：对外交付质量。 它包含两个细分的指标，分别是：1)单位时间的故障（线上问题）数；2）故障平均解决时长。这两者共同决定了系统的可用性。

如上图所示，这5组指标，从流动效率、资源效率和质量三个方面讲述了一个完整的故事，回答了组织持续交付价值的能力如何这个核心问题。其中，持续发布能力和需求响应周期这两组指标反映价值的流动效率；吞吐率反映资源效率；交付过程质量和对外交付质量这两组指标共同反映质量水平。

一个度量指标实例：缺陷趋势图

针对这些指标，云效提供了丰富的度量图表，后续云效产品团队还会进行场景化的梳理，提高其可用性。我会及时跟进，用专门的文章介绍云效的完整度量方案。在这里我先介绍一个例子——关于过程质量的度量图表。

“缺陷趋势图”是云效新设计的度量图表，它反映交付过程中缺陷发现和移除的时间分布，以及缺陷的库存趋势。

如上图所示，图形的横坐标是日期，横坐标上方红色竖条代表这一天发现缺陷数量；横坐标下方绿色竖条代表当天解决的缺陷数量；橙色曲线代表缺陷存量。图中左右两个部分比较了两种交付模式。

左半部分，团队属于小瀑布的开发模式。“迭代”前期，团队集中设计、编码，引入缺陷，但并未即时地集成和验证。缺陷一直掩藏在系统中，直到项目后期，团队才开始集成和测试，缺陷集中爆发。

小瀑布模式下，过程质量差，带来大量的返工、延期和交付质量问题。该模式下，产品的交付时间依赖于何时缺陷能被充分移除，当然不能做到持续交付，也无法快速响应外部的需求和变化。并且，这一模式通常都导致后期的赶工，埋下交付质量隐患。

右半部分，团队开始向持续交付模式演进。在整个迭代过程中，团队以小粒度的需求为单位开发，持续地集成和测试它们，即时发现和解决问题。缺陷库存得到控制，系统始终处于接近可发布状态。这一模式更接近持续发布状态，团队对外的响应能力随之增强。

缺陷趋势图从一个侧面反映了团队的开发和交付模式。它引导团队持续且尽早发现缺陷并及时移除它们。控制缺陷库存，让系统始终处于接近可发布状态，保障了持续交付能力和对外响应能力。

缺陷趋势图是云效研发效能度量图表中的一个。后面，我会用专门的文章系统地解读这些图表的使用。

效能改进的目标设定：部分团队的2-1-1愿景

以上，我们介绍了研发效能度量。基于这样的度量体系，应该设定怎样的目标呢？我们在多个团队的实施过程中，逐渐沉淀出了可供参考的目标体系，它可以总结为三个数字——“2-1-1”。

“2-1-1”最初来自天猫新零售，其后在闲鱼和研发中台、阿里云等团队完善和采用。什么是“2-1-1”呢？

“2"指的2周的交付周期，85%以上的需求可以在2周内交付；

第一个“1”指的是1周的开发周期，85%以上的需求可以在1周内开发完成；

第二个“1”指的是1小时的发布前置时间 - -提交代码后可以在1小时内完成发布。[1]

达成“2-1-1”的愿景并不容易。1小时的发布前置时间，需要持续交付流水线，产品架构体系和自动测试、自动部署等能力的提升。1周的开发周期，涉及更多的能力和实践，如：需求的拆分和管理，开发团队的分工协作模式，以及持续集成和持续测试实践；最困难的则是2周的交付周期，首先它要以另外两个指标为基础，同时还涉及整个组织各职能和部门的协调一致和紧密协作；

“2-1-1”的目标都是关于流动效率的，你可能会问，那资源效率和质量呢？我们专注于流动效率，是因为它是组织效能改进的抓手，能够触发深层次的和系统性的改进。就像上面分析的，为达成“2-1-1”目标，团队需要技术、管理、协作等方面的全面实践升级，而这些实践的落地，必然会带来资源效率和质量的提升，并体现到相应的度量指标上。

当然，“2-1-1”是源自特定的团队，并非所有团队都要使用同样的值，比如对于涉及硬件开发的团队，两周的交付周期通常过于挑战。组织应根据自己的上下文设定恰当的目标，重要的是，它要指明改进的方向。

总结

本文定义了研发效能，它指的是一个组织持续快速交付价值的能力，可以从流动效率、资源效率和质量三个方面来衡量。其中流动效率是改进研发效能的核心抓手，它带来系统和全局的改进。

如上图所示，研发效能最终为组织效能服务，必须体现到利润、增长、客户满意度等组织效能上；同时，研发效能的提升要落实到具体技术和管理的实践中，才可能发生。

定义和度量是提升研发效能的基础，相信你更关心提升研发的具体实践和方法。3月16日-17日，何勉老师将和阿里研发效能其他讲师一起，在上海为我们分享《企业数字化转型面临的研发效能挑战—阿里DevOps体系和实践》课程，有关于阿里DevOps体系知识都可以从他们那里得到答案。

报名地址：https://jinshuju.net/f/yPY1u1?from=singlemessage&isappinstalled=0

亮点&收获

亮点：

• 阿里DevOps体系化方法和实践，集阿里巴巴多年先进的管理理念和工程实践。

• 高匹配度的客户案例，分享案例来自阿里内部产品线和行业标杆客户案。

• DevOps沙盘实战，利用工具实战一站式研发生命周期管理服务，体验阿里巴巴交付方式。

收获：本课程从一个完备的精益和敏捷产品创新和交付方法体系，帮助学员掌握和系统应用，提升组织“顺畅、高质量交付有用价值的能力”，助力企业数字化转型和业务成功。

日程&嘉宾

3月16日AM

敏捷产品创新和交付方法体系

何勉  阿里巴巴集团研发效能事业部资深解决方案架构师

3月16日PM

阿里云效的敏捷方法项目实战

苗媛媛  阿里巴巴研发效能事业部解决方案工程师

3月17日AM

数字化时代，企业研发效能提升的挑战与展望

章屹 阿里巴巴研发效能事业部资深解决方案架构师

3月17日PM

阿里研发效能提升实践之路

章屹 阿里巴巴研发效能事业部资深解决方案架构师

面向人群&培训环境

面向人群：

• 互联网行业：研发中心CTO、技术经理 、架构师

• 数字化转型类的企业：研发中心CTO、技术经理 、架构师

• 中台业务建设的企业：研发中心CTO、技术经理 、架构师

培训环境：

注:

【1】最早云零售部门（天猫新零售的前身）提出的目标是2-1-3，前面的“2”和“1”的含义相同，不同的是最后一个“3”指30分钟——30分总完成发布前的回归测试，但不包含发布过程。天猫新零售的2-1-3是这一愿景的最初版本，后来阿里其他团队（最早是闲鱼）将30分钟改为了1小时，并包含了发布在内，这就是“2-1-1”目标的由来。

更多内幕知晓可报名参加线下培训：https://jinshuju.net/f/yPY1u1?from=singlemessage&isappinstalled=0