文章来源：https://zhuanlan.zhihu.com/p/151814549
一、现状与困境
各大互联网厂商期待通过建立快速迭代和持续交付的能力，提升研发效能，快速响应市场的变化，纷纷在研发效能的提升上投入大量的人力物力和财力，提升研发效能成为他们本年度的重要目标之一。对于什么是好的研发效能，却很少能被清晰定义。如此，我们又如何去提升它呢？
针对这个问题，我们通过3个维度5组指标来度量研发效能，分析什么是好的研发效能，同时回答团队已具备怎样的持续快速交付价值的能力。
二、阿里巴巴研发效能3个维度5组度量指标
管理学之父德鲁克说：“如果你不能度量它，就无法改进它”。度量帮助我们更深刻认识研发效能，设定改进方向，并衡量改进效果。那什么是好的度量能？
产品开发过程中会产生大量的数据，但数据不是度量。好的度量的标准是：它要为回答一个根本的问题讲述完整的故事，不但能快速反馈的向外度量，而且要能引导出行为的正确改变。
效能度量要回答的根本问题就是：一个组织“持续快速交付价值的能力”怎么样？
三个维度五组指标
为回答这个问题，应该提供怎样的一个完整故事呢？基于阿里内部多部门持续实践和探索，我们发展并验证了系统的研发效能指标体系。如上图所示，它由5组指标构成，分别是：
第一：持续发布能力。具体包含两个细分指标，分别是：
- 发布频率。 团队对外响应的速度不会大于其交付频率，发布频率约束团队对外响应和价值的流动速度。它的衡量标准是单位时间内的有效发布次数。
- 发布前置时间（也被称为变更前置时间），也就是从代码提交到功能上线花费的时间，它体现了团队发布的基本能力。如果时间开销很大，就不合适加大发版频率。
第二：需求响应周期。具体包含两个细分的指标，分别是：
- 交付周期时间。指的是从确认用户提出的需求开始，到需求上线所经历的平均时长。它反映团队（包含业务、产品和技术等职能）对客户问题或业务机会的响应速度；
- 开发周期时间。指的是从开发团队理解需求开始，到需求可以上线所经历的平均时长。它反映技术团队的响应能力。
区分交付周期和开发周期，是为了解耦并明确问题，以做出针对性的改进。其中，交付周期是最终的目标和检验标准。
第三：交付吞吐率。指的是单位时间内交付需求的数量。关于这一点，常见的问题是，个数能准确反映交付效率吗？这是个问题。所以，我们更多强调单个团队的需求吞吐率的前后对比，统计意义上它足以反映趋势和问题。
第四：交付过程质量。它包含两个细分的指标，分别是：
- 开发过程中缺陷的创建和修复时间分布。我们希望缺陷能够持续和及时地被发现，并且在发现后尽快修复；
- 缺陷库存。我们希望在整个开发过程中控制缺陷库存量，让产品始终处于接近可发布状态，奠定持续交付的基础。
交付过程质量的核心是内建质量，也就是全过程和全时段的质量。而非依赖特定的阶段，如测试阶段；或特定的时段，如项目后期。内建质量是持续交付的基础，关于其具体度量方法，下文会给出详细实例。
第五：对外交付质量。 它包含两个细分的指标，分别是：1)单位时间的故障（线上问题）数；2）故障平均解决时长。这两者共同决定了系统的可用性。
如上图所示，这5组指标，从流动效率、资源效率和质量三个方面讲述了一个完整的故事，回答了组织持续交付价值的能力如何这个核心问题。其中，持续发布能力和需求响应周期这两组指标反映价值的流动效率；吞吐率反映资源效率；交付过程质量和对外交付质量这两组指标共同反映质量水平。
三、什么是不好的度量
好的度量指标可以引导出行为的正确改变，不好的度量指标会引导出不良的行为。
下面用三个例子，来看看不好的度量指标引导出了哪些不良行为：
3.1 把按时完成率设成了KPI
这是去年做咨询时碰到的一个Case，该团队跑双周迭代，刚好碰到该团队做需求排期，排期结束后，测试同学很为难的告诉我，她感觉研发团队只接了团队容量60%的需求，其实还可以做更多的需求。
好奇害死猫，对该现象进行了刨根到底地追问，最后发现是该团队的成员都背了一个KPI：需求按时完成率。为了确保需求能按时完成，一方面估算的时候留了尽量多的Buffer，另一方面，尽量少做一些需求，按时完成率更容易达成了，所以就出现上面的情况。
后来找HR和研发负责人去沟通，当初设定按时完成率的KPI，期待需求和项目都能按时按质量的交付，可是效果恰恰相反，不但无法鼓舞团队的士气，反而多做需求的同学会吃亏。后来就把该指标给去掉了。
所以把按时完成率设成KPI是不推荐的，后面有专门的文章来分享如何设定研发团队的目标
3.2 追求高单元测试覆盖率的后果
很多公司为了提升代码质量，会从单元测试入手。说到单元测试，肯定会想到要提升单元测试的覆盖率，用单元测试的覆盖率去驱动团队多做单元测试。
这是一个通讯行业的团队，要求单元测试覆盖率在90%以上，要做到90%的覆盖率相当不容易的，而该团队的单测覆盖率基本能保持在90%以上，并且单测成功率很高，成为了大家的榜样。
后来做审查的时候发现，该团队的很多单测里面居然没有Assert，也就是没有判断，只是跑了覆盖率，而且返回也是成功的。这样的单测基本发挥不了价值，而且浪费大量的人力物力。
关于单元测试覆盖率，建议逐步提升，让覆盖率能做到逐步提升，每次Push后，确保覆盖率不下降。
对于没有单测的团队，是否要先从单测入手，这个要看具体情况，一般不建议从单元测试先开始。
3.3 英国窗户税引发的问题
英国曾有窗户税，它的前身是壁炉税。1696年前，税款以每户的壁炉数量来衡量，这需要税务员进屋查看，民众不可能欢迎税务员进门，故收税很不顺利，也异常辛苦。
1696年，窗户税取代了壁炉税，征税标准以窗户数量来计算，税务员们松了一口气，他们只需要在街道上轻轻松松清点即可。所有房子都有2先令的基本费，若窗户达10到20扇，则基本费升到4先令。1747年，规则又发生变化，房子若有10扇以上的窗户，每多开一扇窗就得交税6便士。
1696年，英格兰开征窗户税―理由是房屋的大小和豪华程度与采光的窗户的数量和大小密切相关，因此税务官只需要在外面数数窗户的数量就可以确定房主应当缴纳的税款。面对如此“天才的发明”，房主也没闲着 -- 除了买油灯、堵窗户以外，开天窗逐渐流行了起来。结果，除了在阴暗的房屋里培养出了一大批早早丧失劳动能力的近视眼并刺激了照明工业的发展外，英格兰的收税官所获无几。
四、两个度量指标实例
前面讲了3个维度5组指标，接下来用周期时间控制图和缺陷趋势图来看团队的效能情况。个人特别喜欢这两幅图，因为通过它们基本可以看出团队的研发模式、现状和趋势。
4.1 周期时间控制图
周期时间控制图示例
如上图，一个蓝色的点代表一个已经发布的需求，横坐标是日期，纵坐标是天数，其中红圈中的点代表是7月8日发布的，交付周期为11天。
我们要从5个方面去看周期时间控制图
1）纵向上，这些点越向下越好，周期时间越短，代表需求响应能力越快，可预测性越好；
2）横向上，这些点分布越密越好，越密代表需求交付地越频繁，也就是发布频率越高；
3）横向上，这些点分布越均匀越好，越均匀代表持续均匀的交付，更趋向于持续交付；如果分布的比较集中的，基本就是批量地发布。
4）纵向上，85%的控制线代表团队当前交付周期的一个水位，让该水位越低越好；
5）随着时间的推移，这些点是否在逐步往下走，往下走的趋势代表团队的响应能力在逐步提升。
所以，通过周期控制图可以基本看出团队是否已具备持续快速交付需求的能力。
下图是我之前辅导过的一个天猫新零售团队的需求交付周期分布情况。从一个开始的大批量长周期的发布，到小批量短周期的发布。该图在云效上自动生成。
从大批量长周期到小批量短周期
4.2 缺陷趋势图
团队不但要能持续快速交付需求，同时也需要高质量的交付需求。缺陷趋势图中缺陷的视角看来团队的协作模式和质量情况。
缺陷趋势图示例
如上图所示，图形的横坐标是日期，竖坐标是数量，横坐标上方红色柱子代表这一天发现缺陷数量；横坐标下方绿色柱子代表这一天解决的缺陷数量；橙色曲线代表缺陷存量。图中左右两个部分比较了两种交付模式。
左半部分，团队属于小瀑布的开发模式。“迭代”前期，团队集中设计、编码，引入缺陷，但并未即时地集成和验证。在1号到20号期间，团队一直在引入缺陷（写缺陷），而未能及时的发现它们。缺陷一直掩藏在系统中，直到项目后期，团队才开始集成和测试，缺陷集中爆发，越到后期发现的缺陷，修复困难度大幅提升，修复成本大幅增加。
小瀑布模式下，过程质量差，带来大量的返工、延期和交付质量问题。该模式下，产品的交付时间依赖于何时缺陷能被充分移除，当然不能做到持续交付，也无法快速响应外部的需求和变化。并且，这一模式通常都导致后期的赶工，埋下交付质量隐患。
右半部分，团队开始向持续交付模式演进。在整个迭代过程中，团队以小粒度的需求为单位开发，持续地集成和测试它们，即时发现和解决问题。缺陷库存得到控制，系统始终处于接近可发布状态。这一模式更接近持续发布状态，团队对外的响应能力随之增强。
缺陷趋势图从一个侧面反映了团队的开发和交付模式。它引导团队持续且尽早发现缺陷并及时移除它们。控制缺陷库存，让系统始终处于接近可发布状态，保障了持续交付能力和对外响应能力。
下图是一个团队缺陷趋势图的实例，该图在云效效能洞察上可自动生成。
缺陷趋势图实例
五、研发效能的愿景目标
建立了明确的度量体系，什么样的效能指标是研发效能的愿景目标呢？
“2-1-1”最初来自天猫新零售，其后在闲鱼和研发中台、阿里云等团队完善和采用。什么是“2-1-1”呢？
- “2"指的2周的交付周期，85%以上的需求可以在2周内交付；
- 第一个“1”指的是1周的开发周期，85%以上的需求可以在1周内开发完成；
- 第二个“1”指的是1小时的发布前置时间 - -提交代码后可以在1小时内完成发布。
如下图所示，在持续交付能力的指标体系中选择这三个指标作为目标的。
要达成“2-1-1”的愿景并不容易。1小时的发布前置时间，需要持续交付流水线，产品架构体系和自动测试、自动部署等能力的提升。1周的开发周期，涉及更多的能力和实践，如：需求的拆分和管理，开发团队的分工协作模式，以及持续集成和持续测试实践；最困难的则是2周的交付周期，首先它要以另外两个指标为基础，同时还涉及整个组织各职能和部门的协调一致和紧密协作。
六、总结
本文定义了研发效能，它指的是一个组织持续快速交付价值的能力，可以从流动效率、资源效率和质量三个方面来衡量。其中流动效率是改进研发效能的核心抓手，它带来系统和全局的改进。
如上图所示，研发效能最终为组织效能服务，必须体现到利润、增长、客户满意度等组织效能上；同时，研发效能的提升要落实到具体技术和管理的实践中，才可能发生。
关于如何落地的更多方法和实践，后续会有文章逐步介绍。
感谢阅读至此，欢迎评论
如你期待进一步沟通和交流，或者有咨询的诉求，可添加微信“waterhong2010”，暗号“研发效能211”
七、致谢
感谢阿里巴巴阿拉丁团队的所有成员，要特别感谢是何勉和张燎原两位老师的耐心指导。
八、参考资料
[1] 阿里巴巴 阿拉丁团队 精益产品开发方法与解决方案
[2] 何勉 《精益产品开发:原则、方法与实施》
[3] 何勉 微信公众号：精益产品开发和设计
[4] Klubeck, Martin. Metrics: How to Improve Key Business Results