如何衡量研发效能？阿里资深技术专家提出了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”是源自特定的团队，并非所有团队都要使用同样的值，比如对于涉及硬件开发的团队，两周的交付周期通常过于挑战。组织应根据自己的上下文设定恰当的目标，重要的是，它要指明改进的方向。

总结

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

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

定义和度量是提升研发效能的基础，相信你更关心提升研发的具体实践和方法。

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!