‍

阅读本文你将收获：

1、如何系统性建设研发效能度量体系

2、怎么降低研发效能度量带来的额外成本？

3、避免研发效能度量的平均值陷阱；

4、如何把研发效能度量引导到正确的方向上

‍

作者简介

张乐，腾讯 DevOps 与研发效能资深专家，曾长期工作于拥有数万研发的互联网大厂（百度、京东等），专注于敏捷与 DevOps 实践体系、DevOps 平台产品设计、研发效能度量体系建设等方向，历任资深敏捷教练、DevOps 平台产品总监、集团级研发效能度量标准化联盟负责人等岗位。长期活跃于技术社区，目前是 DevOps 起源国际组织 DevOpsDays 中国区核心组织者，同时也是国内多个技术峰会的联席主席、DevOps/ 研发效能专题出品人、特邀演讲嘉宾。

‍

本文来源：转载张乐老师的研发效能系列文章内容之：《如何在中大规模企业成功落地研发效能度量？》

‍

研发效能度量的出发点虽然很好，但是如何正确、有效的度量却是一个颇有难度的技术活儿。近期围绕如何进行研发效能度量的讨论不绝于耳，但如何构建研发效能度量的体系化框架、如何进行度量指标的选取、如何进行度量分析、如何进行落地运营，却鲜有文章具体阐述。

‍

在之前的文章中，我们分别讨论了研发效能度量的难点和误区、业界案例和关键原则、度量实践框架、度量指标体系设计、度量常用分析方法，但在中大规模企业中成功落地研发效能度量还有很多因素需要考虑，本篇文章我就结合近期落地经验，来介绍一下落地过程中具体的实施建议。

‍

如何系统性建设研发效能度量体系

‍

在企业研发效能度量体系建设的初始阶段，大家的关注点可能都聚焦在度量什么样的指标、如何采集和计算、如何展示报表等问题上，这只是在做一些单点能力的建设，但并没有形成体系。随着持续深入的推进，需要更加系统性地思考，对于研发效能度量体系也会有不同的理解。下图给出了某互联网大厂研发效能度量体系的架构图。

‍

在图中，有以下5部分内容需要重点关注：

‍

研发效能度量的用户场景

‍

研发效能度量指标是统计出来用来给人来看的，我们首先要找准用户和场景，没有目的性的堆砌指标没有任何价值。

‍

比如，高层管理者一般关注组织级的效能评估结果，包括整体的研发投入产出、战略的资源分配和达成情况、业务满意度、各事业部北极星指标的横向对比、研发效能月报等，但可能不会关注特别细节的指标数据。团队级管理者不仅会关注团队交付效率、交付质量、交付能力等全方位的效能指标，并且希望度量平台具备问题自动化诊断和分析能力，能够结合趋势、下钻、关联分析等多种手段帮助识别效能瓶颈。工程师也会关注一些效能指标，用于对个人工作进行需求、任务、代码、缺陷等维度的统计和反馈。

‍

研发效能度量的指标体系

‍

我们在之前的章节中讲到了很多度量指标，但只有指标的定义是不够的。我们还需要明确指标价值、指标说明、指标公式、指标采集方式、指标优先级、指标健康度等内容。研发效能度量的根本要求之一就是数据的准确性，那么度量指标的健康度就显得尤为重要了。我们曾经发现在推广度量体系时，某部门的需求交付周期小于 0.1 天的占比为 8.6%（290/3374），经排查，这些需求通常为研发完成后补录，这些数据的存在会影响交付周期度量结果的准确性，需要格外引起重视。另外，指标体系及其详细说明应当尽量公开透明，这样用户在得到指标度量结果的时候也可以更清晰理解其计算口径和与其他指标的逻辑关系。

‍

研发效能度量的模型设计

‍

模型是对某个实际问题或客观事物、规律进行抽象后的一种形式化表达方式，一般包括目标、变量和关系。在研发效能度量领域，模型有很多种，比如组织效能模型、产品 / 团队效能模型、工程师效能模型等。研发效能度量的领域专家可以建立模型，并通过度量平台屏蔽其复杂性，提供给用户自助化分析使用。

‍

一个典型的应用场景是研发效能度量的体检模式，即度量平台根据领域专家总结出来的效能指标和既定模型，对产品线某个时间段的研发过程进行分析体检并推送体检报告，相关干系人都可以定期收到报告。在报告中标识了的正常 / 异常的研发效能指标项，并带有初步分析结果和问题改进的建议。然后，如果想对其中的某个指标进行详细分析，则可以切换到问题诊断模式，这样可以基于模型对相关的指标及报表组合进行专项分析，包括各种趋势、下钻和关联分析等，帮助排查具体问题。在积累了足够的历史数据后，也可以通过模型进行风险预警，当发现某些指标有异常波动或相不好的方向发展的趋势后，及时给出风险提示。

‍

研发效能度量的产品建设

‍

研发效能度量的过程实际上是要把数据转化为信息，然后将信息转化为知识，这样就可以让用户自主消费数据，进行分析和洞察。一个优秀的研发效能度量产品要做到自动化的数据采集，自动化的数据聚合，让用户可以自助化的查询和分析，甚至自定义报表，从而获得研发效能的有效洞察。度量产品应该是可以被整个组织的团队和管理者访问到的，效能数据也应当被更加透明地使用，不宜设置过多的数据访问权限，人为地制造信息不对称。

‍

度量平台也应该被作为一个产品而不是项目来运作，包括度量什么、如何分析、如何对比实验都是需要持续演进的，而且作为一个产品我们要多听取用户的反馈，这与建设其他产品的过程都是一样的。另外，度量产品一定要注重易用性，使用平台的用户往往不是这个方面的专家，应该避免使用复杂的公式定义和晦涩难懂的专业术语进行描述。例如下图就是度量平台对交付周期类指标的一种可视化的展示视图，用户可以在页面上进行点选操作，关于指标范围、说明都动态展示，让用户可以一目了然进行快速理解。

‍

‍

研发效能度量的运作模式

‍

成功的研发效能度量落地离不开组织的有力支撑，很多企业会采取虚拟的研发效能度量委员会来进行度量体系的设计和落地。在度量体系建设的初期，委员会的主要职责就是进行指标的定义和对齐，要考虑各种可能的场景和边界情况，让指标明确、有意义、无歧义。

‍

随着度量体系的逐步落地发展，委员会成员也会迅速扩充，这些成员就成为了各个部门推进研发效能度量的种子选手。当然，在一线落地过程中免不了遇到各种问题，那么委员会就要进行整体规划的对齐和疑难问题的决策。

‍

随着度量体系逐渐成熟，委员会可以把重心放到效能分析和效能提升的实践分享上来，形成研发效能度量指导手册、效能提升案例库和专项解决方案知识库，沉淀过程资产，让效能的度量、改进和提升成为日常工作的一部分。

‍

通过自动化降低度量带来的额外成本

‍

研发效能的度量不是免费的，为了做到准确、有效的度量，各种成本加在一起是很高的。研发效能度量的准确性依赖流程的规范性，需要明确研发流程、制定相应规范，并确保相关的活动都在系统中进行及时、完整的记录。为了能在减少研发过程中各个角色时间和精力投入的基础上提升研发效能度量的准确性，可以通过统一工程效能平台固化研发流程与活动，并通过自动化的手段减少工程师繁琐的额外手工操作（如在多个系统进行状态更新同步等）。

‍

在研发过程中，我们要同时关注管理侧的需求价值流和工程侧的研发工作流。管理侧的价值流以需求特性为核心，贯穿就绪、设计、开发、测试、发布等阶段。工程侧的研发工作流以代码提交为线索，会执行分支创建、代码提交、编译、扫描、测试、代码合并、部署、发布的等一系列活动。我们可以通过效能工具平台的建设，让这两条流之间实现联动，自动完成状态的流转和信息的同步。

‍

下图就是一个自动化状态流转和信息同步的案例，部门选用了特性分支开发的分支模型，当特性分支拉出并关联需求的时候，或者代码提交 Commit 信息关联了需求 ID 后再进行 Push 的时候，就会触发对应需求的状态更新，从”就绪”更新为”开发中”。

‍

当代码 Merge Request 合并到 remote/dev 分支时，会触发对应需求的状态更新为”测试中”。当代码合并到 remote/master 分支时，会触发对应需求的状态更新为”发布中”。直到最终发布完成后，需求的状态自动更新为”已完成”。这种自动化的状态流转让系统中记录的研发过程元数据更为准确，也在较低成本的情况下给度量提供了有效的研发基础数据。

‍

‍

避免研发效能度量的平均值陷阱

‍

平均值陷阱，是指由于参与平均值计算的数据样本存在较大差异，平均值难以真实反映所有样本状态的情况。比如某个需求的交付周期是 1 天，第二个需求是 2 天，另外一个需求是 96 天，那么这三个需求交付周期的平均值就是 33 天，这明显无法反馈出真实的情况。

‍

在软件研发领域，从数据统计的角度来看，需求交付周期这类指标通常符合韦伯分布，这是一种连续的概率分布，类似于一种向左倾斜并带有长尾的正态分布。所以，对于需求交付周期，我们推荐的度量方法不是平均值，而建议使用第 85 百分位数。其原理就是将一组数值从小到大排序，处于 85% 位置的那个数值，就称为第 85 百分位数。而我们经常说的中位数就是第 50 百分位数。

‍

假如需求交付周期的第 85 百分位数是 21 天，那么这意味着，根据经验证据，任何大小相似的需求（理想情况下，所有需求都可被拆分为大致相似的颗粒度，并且应较小)，都有 85% 的概率在 21 天内完成，这可以成为我们基于统计规律对开发计划进行承诺的依据。我们可以定期画出这张图表，看看它的形状是如何变化的。当第 85 百分位数前移，那么你就能更快地向客户交付价值。

‍

不仅是需求交付周期，我们在多个团队的研发效能度量中也应该极力避免平均值陷阱。下图展示了某个部门在进行研发效能度量过程中发现的一种情况，即经过了一个季度的效能改进，这个部门的研发效能度量指标几乎没有变化，这就让管理者非常苦恼，时间花出去了但是看不到任何效果。但是，当我们把度量指标下钻到团队中后，发现其实已经有很多团队的效能获得了大幅提升，最多的一个团队甚至提升了 18%，而其他的一些团队由于各种原因，研发效能度量指标出现了下降，在平均值数据上抵消了高效能团队积极改进所带来的成果。这样，我们就可以分而治之，继续巩固先进团队的效能实践，排查低效团队的效能问题，细化的度量可以给每个团队带来明确的行动指引。

‍

‍

把研发效能度量引导到正确的方向上

‍

度量组织效能是企业中最敏感的领域之一，经常受到政治和各种职能障碍的影响。此外，由于度量不可避免地涉及到对度量数据的解释，也会受到认知偏差、沟通问题和组织目标对齐的影响。所以如果度量没有被引导到正确的方向上或没有被正确地实现，会导致重大的风险，即研发效能度量的结果可能弊大于利。

‍

我们要避免把度量武器化。根据古德哈特定律，当某个度量变成了目标，它便不再是一个好的度量。所有的度量都可以被操纵，而数字游戏式的度量会分散员工的注意力并耗费大量时间。把度量指标设置为 KPI 进行考核，只是激励员工针对度量指标本身进行优化，这通常比他们在度量之前所做的工作效率要更低。度量不是武器，而是指导我们进行效能改进的工具。

‍

我们也会碰到另一种情况，就是纯从数字来看，研发效能度量指标有了大幅提升，比如交付效率和吞吐量都在提高，但业务部门却仍不满意，他们的反馈是：”好像并没有什么变化!”那么这个时候，我们应该相信谁呢，是数据还是业务部门的声音？正如杰夫·贝佐斯 (Jeff Bezos) 的名言所说：“我注意到的是，当传闻和数据不一致时，传闻通常是正确的”。很可能是你研发效能度量的方法有问题，或是数据已经失真，这就需要进一步的检视和反思了。

‍

丰田的大野耐一曾经说过：”那些不懂数字的人是糟糕的，而最最糟糕的是那些只盯着数字看的人”。每个数字背后都有一个故事，而这个故事往往包含比数字本身所能传达的更重要的信息。现场观察 (Gemba) 是一个可以与度量结合使用的强大工具，管理者要到实际的研发交付过程中去，观察需求和价值的流转过程，看一下团队是如何满足客户需求的。正式的度量和非正式的观察是相辅相成的，可以对结果进行相互印证。

‍

‍

总结

‍

在数字化时代，每一家公司都是信息技术公司，研发效能已经成为核心竞争力。通过正确的研发效能度量方法，坚持数据驱动和实验性的精神，可以让研发效能可量化、可分析、可提升。

‍

通过研发效能度量方法与实践的系列文章，相信你已经对为什么要做研发效能度量、如何设计度量指标、如何进行度量分析、如何进行有效落地有了比较深刻的理解，也希望你能在实践中持续精进，我们一起多多交流，相互学习!

最后，祝你能拥有更高的研发效能！

‍