企业如何度量研发效能？

 研发效能度量是当下软件研发领域最火热话题之一，互联网企业和传统软件企业都在关注研发效能度量领域。尤其在数字产业化和产业数字化的大背景下，研发效能更被视为一家科技公司的核心竞争力，也被部分管理者奉为圭臬。

然而研发效能度量虽好，但要在团队中真正实施落地起来，却不是那么容易。

总结起来有以下几个原因：

• 偏离了效能度量的正确方向

• 缺乏系统性的思考与设计

• 缺乏优秀高效的效能度量产品

那么到底什么是研发效能度量？如何避免落入效能度量的误区？如何进行系统化的设计效能度量指标体系？以及如何在团队中有效的实施落地研发效能度量？优秀的效能度量产品应该具备哪些要素？

这些问题都是本文将要探讨的话题。

01 什么是效能度量

研发效能并没有一个官方的标准定义，从字面意思来理解，所谓的研发效能就是软件研发的效率和能力。

提到研发效能，很多人第一时间想到的是快速的完成开发工作，原本需要一周完成的需求，提高了研发效能之后，能在一天内完成。而这个场景只能算是研发效能的一个指标，并不全面。

个人看来研发效能可以概括为：高效率、高质量的持续交付有效业务价值的能力。

这句话里有几个关键点需要特别强调一下：

• 高效率：交付的效率要高，交付周期要尽可能的短

• 高质量：交付的质量要高，如果交付的质量太差，系统随时面临崩溃，不是我们所追求的效能。

• 持续交付：交付的过程必须是可持续的，而不是只高效高质量交付一次。

• 有效业务价值：交付的内容必须关注业务价值，关注业务是否成功。

这几个关键点缺一不可，缺少哪个都够不成完整的研发效能的定义，了解清楚什么是研发效能之后，我们来看看研发效能是否可以进行度量。

关于研发效能度量，业界有两种截然相反的观点：

一种观点以现代管理学之父 Peter Drucker 的理论为依据，主张研发效能是可以度量的；

另一种观点以世界级软件开发大师 Martin Fowler 为代表，主张研发效能是不可度量的。

我的看法是研发效能可以度量，但落地实施起来并不那么容易，要避免落入研发效能度量的误区。

02 效能度量的误区

然而研发效能度量虽然可度量，在团队中真正实施落地起来，却不是那么容易。

大部分团队在推行研发效能度量的过程中，落入了效能度量的误区。总结起来在研发效能度量的过程中，常见的误区有以下几个：

误区 1：

效能度量的目的是为了绩效考核。把研发效能度量与绩效考核关联起来，是国内团队常见的做法，也是效能度量最大的误区。

效能度量是一种达成目标的手段，而非绩效考核的手段，它在于帮助团队找出团队活动中的瓶颈，分析瓶颈产生的原因，从而改进并不断反馈，以保证更快更高质量的交付业务价值。

如果把效能度量等于绩效考核，注定会变成数字游戏，效能度量也一定会失败。

误区 2：

效能度量等同于数据报表。效能度量并不等同于数据报表，数据报表更多的是通过数据加工清洗，以可视化的方式呈现出来，从数据中得出有用的信息，所以数据报表只是研发效能度量活动中的一个工具，一个手段。

效能度量除了需要可视化的数据报表之外，更重要的是识别出瓶颈，进行改进优化，并不断的反馈改进。

误区 3：

关注局部效率，而忽视了全局。在研发效能度量中过度关注局部效率，并不会带来全局效率的提升。

整个研发活动是一个非常长的链条，我们要把着眼点放在那些真正出现瓶颈的地方。如下图中蓝色线条代表实际的研发时长，红色线条代表是阻塞时长。

所谓关注局部效率，就是缩短蓝色部分的时长，而对整个周期来看红色部分的影响远大于蓝色部分的影响，所以提升研发效能最有效的是缩短红色部分的时长。

误区 4：

关注效能度量本身，而忽视了业务价值。研发效能的提升，最终是要为业务价值服务的，关注研发效能的改进过程成功与否，是要看最终为业务成功带来了多大的提升，而不是只关注研发效能自身的数据。

如在研发管理活动中引入一套新的研发管理工具，从效能度量角度看，引入该系统后从开发到测试交付的周期是不是缩短，发布的质量和频率是不是提升；从业务价值角度看，引入该系统后是否为业务价值带来了真正的成功。

误区 5：

忽略效能度量的长周期性。效能度量是具有周期性的，而且周期也带有一定的不可预测性，不是每引入一项研发效能度量改进计划，都会产生正向的收益。

很多时候需要不断的尝试，识别问题，并制定详细的改进计划，经过一段周期后才会看到效能真正的提升。

所以在研发效能度量过程中，不可操之过急，不可以忽略它的的长周期性，只要设定的度量目标正确，通过不断的改进与反馈，最终会达到想要的目标。

误区 6：

效能度量的指标设计过于单一。效能度量的指标体系需要具有科学且系统性的思维以及全局思考，切不可以偏概全，如果设计的度量指标体系过于单一、片面，会把研发效能度量引到错误的方向上去。

以需求交付周期为例，如果在研发活动中以需求交付周期作为一个指标，就需要同时设计关于需求交付质量的指标，因为需求的交付不仅仅只是快，有效高质量的需求交付才有价值。

误区 7：

效能度量必须是精确的。这可能是大家经常会陷入的一个误区，认为效能度量的数据必须精确才有意义，其实在效能度量中我们经常采用的是统计度量，而非精确度量。

所谓统计度量是以统计样本为基础，在观察样本的基础上得出近似精准但科学的推断，统计度量常用趋势、分布、均值等手段。

03

效能度量指标体系

整个研发管理链条，本质上是两条工作流。

一条管理侧以需求特性的全生命周期为核心的需求价值流，涵盖需求收集、规划、开发、测试、发布到上线环节；

一条工程侧以代码提交为线索的研发工作流，涵盖启动开发、开发中、开发完成、持续集成、持续部署到线上发布环节：

 这就要求我们在效能度量的指标体系设计中，充分考虑这两条流之间信息的流转与状态的同步，从而设计出一套覆盖端到端交付的效能度量体系。

根据效能度量的目标，我们要实现高效率、高质量的持续交付有效业务价值的能力，可以把效能度量指标分为如下三个体系：交付效率、交付质量和交付能力。

 交付效率

目标是促进端到端及早的交付，用最短的时间顺畅的交付用户价值，包括：

• 平均需求交付周期：需求从提出到最终发布上线的时间周期；

• 需求吞吐量：统计单位时间内交付需求的个数；

• 平均开发交付周期：需求从开发到提交测试的时间周期；

• 平均测试交付周期：需求从开始测试到测试完成的时间周期。

交付质量

目标是促进端到端高质量交付，避免不必要的错误故障和返工，包括：

• 构建成功率：构建成功的次数在全部构建次数中的比例；

• 严重缺陷占比：线上严重缺陷在所有缺陷中的比例；

• 测试覆盖率：判断测试用例的执行情况以及测试执行是否充分；

• 测试通过率：判断测试用例的执行结果，衡量软件的质量。

交付能力

目标是建设卓越的工程能力，实现持续交付，包括：

• 代码提交频率：单位周期内提交代码的频率；

• 每日构建次数：每日能够完成的构建次数；

• 持续集成时长：单位周期内持续集成所花的时间周期；

• 部署时长：单位周期内部署版本所花的时间周期。

完整的效能度量指标体系，可以用下图来表示，通过这些指标体系，可以从不同层面找到影响效能的因素，进而制定详细的效能改进计划，达到提升研发效能的目的。

04 

效能度量分析方法

在探讨效能度量的误区时，我们提到了效能度量中经常采用的是统计度量，而非精确度量。统计度量是以统计样本为基础，在观察样本的基础上得出近似精准但科学的推断。

那么采用哪些度量分析手段，才能使得效能度量更有意义和价值呢？

我们经常采用的效能度量分析方法有如下几种：

趋势分析

相比较于绝对值趋势分析更有价值，在研发效能度量过程中，因为业务不同，团队成员的配比不同、成员的能力有个体差异等因素的影响，关注绝对值意义不大，更应该关注某个对象随着时间的推移而形成的趋势变化。

均值分析

使用均值分析可以确定每个组的均值是否与总体均值存在差异，分析的数据可以服从正态分布、二项分布或泊松分布。如分析每个小组严重缺陷占比或者缺陷重开率，与团队整体严重缺陷占比或缺陷重开率的均值之间的对比。

下钻分析

下钻分析指沿着特定属性维度的层次下降，获取更详细的数据。通常用于对某数据的不断细分，以分析在各种细分情况下的数据关系，找出影响该数据的根本原因。在实际度量过程中，我们可以采用按阶段下钻、按部门下钻、按聚合维度下钻等。

累计流图

累计流图（CFD: Cumulative Flow Diagram)经常被用在看板方法度量中，可以很好地反映工作项在每个流程环节的流动问题。累计流图的使用场景远不止看板方法，在研发效能度量中累计流图可用于分析在制品、分析平均前置时间、需求吞吐量、需求范围变化、预测需求交付时间等。

累计流图本质上就是团队交付过程的回放，引导团队回顾发生了什么，从而改进价值流动过程。

这里只是列出了几种常见的度量分析方法，其他的还有相关分析、交叉分析、聚类分析、矩阵分析、负载分析等各种度量分析方法，感兴趣的可以自行检索。

05

效能度量产品设计

研发效能度量的过程实际上是把研发活动中产生的过程数据，进行加工与清洗，并且转化为可视化的信息，帮助团队进行效能分析与洞察。

其中，把数据转化为信息是这个过程中最有价值的环节，信息对用户是有意义的，而不是单纯的数据，这就是为什么我们叫 IT（Information Technology），而不是 DT（Data Technology）。

在实际业务中，知道了效能度量的误区，也了解了如何设计好度量指标体系，以及运用合适的效能度量分析方法，仅有这些还不够。

要在团队中更好的落地研发效能度量，还需要一款优秀有效的研发效能度量产品，工欲善其事，必先利其器。

选择一款优秀的研发效能度量产品可以让你的团队在落地效能度量时起到事半功倍的效果。

在我看来一款优秀的研发效能度量产品应该具备如下几个要素：

• 自动化的收集数据，而不是依赖于团队成员的手工输入；

• 能够根据团队度量的需要，进行自定义和个性化的配置；

• 能够根据团队成员角色的不同，对效能报表的访问设定不同的可见性；

• 效能报表支持筛选，从而筛选出对效能度量有价值的数据；

• 度量产品的成本要低，如果需要花巨大成本去建设一套效能度量平台，产生的收益并不会达到预期。

这里就以我们 PingCode 推出的研发效能度量产品 Insight 为例。

如果你的团队在研发管理过程中使用 PingCode 产品矩阵中的其他子产品进行管理。

如使用 Project 进行项目管理，使用 Testhub 进行测试管理，这些子产品中产生的过程数据将会通过自动化的收集至 Insight 中，并进行加工清洗，最终以可视化的效能仪表盘形式展现出来。

同时 PingCode 还将提供 Marketplace 和 REST API，帮助研发团队把其他工具的数据收集到 PingCode。这些数据和 PingCode 自身产品中产生的数据加以汇总融合，从而提供更多维度的效能度量。

PingCode Insight 产品设计原理如下图所示：

06

PingCode Insight

PingCode Insight 中的效能度量报表都以效能仪表盘的形式展示，每个团队可以定义多个不同的仪表盘，在每个效能仪表盘上支持添加不同的指标分析。

也可以针对每个效能仪表盘设定不同的可见性权限，以满足团队不同角色所关注的效能度量指标。

PingCode Insight 中根据以上效能度量指标体系，默认设计了大量的效能报表，减少用户定义报表的复杂配置。这些报表都可以直接添加到效能仪表盘中进行使用，后续还会根据实际业务场景需要，不断增加更多更有价值的效能报表：

在每一个具体的度量报表中，团队可以根据自己实际的业务场景，进行个性化的配置。

如定义效能报表展示的样式，对关注的指标进行进行设置，定义不同的对比维度，同时还可以在视图界面对要展示的数据定义筛选条件，以便过滤出对效能度量有价值的数据：

07

总结

研发效能度量本身是一个非常复杂的过程。

在这个过程中，一方面要避免陷入效能度量的误区；另一方面要有系统性思维和全局思考能力，设计完善的效能度量指标体系，运用科学的效能度量的分析方法，同时选择高效的研发效能度量产品，以达到事半功倍的效果。

在效能度量的过程中，只要最终达到的收益大于效能度量所付出的成本，这个付出就是值得的。

Pingcode官网

Worktile官网