本文主要内容目录：

1、研发效能度量指标体系定义及价值

2、研发效能度量指标体系的设计原则、思路与建议

3、研发效能度量指标体系设计的误区

作者简介

熊玉辉，10余年互联网测试开发与质量管理经验。曾就职于腾讯，带领团队进行Devpos实践，致力于工程效能提升。在移动端自动化测试、工具平台建设、研发效能度量等有非常丰富的经验，多次在MTSC、TICA等行业大会上进行专题分享。2020年加入快手，现任快手多媒体质效中心快影质量负责人，负责团队质量与研发效能度量建设，旨在通过合理的效能度量驱动研发效能提升。

本文来源：转载熊玉辉老师的研发效能系列文章，本文全篇收录于QECon组委会发布的白皮书之《研发效能实践指南》

‍

研发效能度量指标体系概述

‍

研发效能度量指标体系，是指一系列可量化研发效能水平的指标集合。 在实际的研发效能度量活动中，需要使用多个指标从不同维度来综合评估与分析。简单来说，指标体系包括两个方面：

‍

●指标：一般包括结果指标和过程性指标；结果指标是指最终反映研发效能状态的指标，过程性指标是指与研发过程息息相关，对最终研发效能产生重要影响的指标。您需要对指标进行定义，并给出计算方法

‍

●体系：围绕研发效能度量目标，对指标进行系统化、结构化的梳理，避免针对单一维度进行度量与分析评估您可以将研发效能度量指标体系，用于任何软件研发团队的效能度量与改进活动中，包括：

‍

●移动终端App

●传统PC软件

●Web应用

●小程序

●基于硬件驱动的软件研发

‍

研发效能度量指标体系的价值

‍

一套合理、优秀的指标体系，可以帮助您的团队：

‍

●借助客观的结果度量数据，使研发产出更加直观

●找到痛点，推动研发流程改进，并衡量改进的效果

●引导研发团队做真正能解决问题的行为，而不是为了追求“数据”上的“好看”

‍

研发效能度量指标体系的设计

‍

为了帮助您的团队能够更客观、有效的度量研发效能，请参考以下建议设计研发效能度量指标体系：

‍

指标设计原则：

‍

●全局最优，而不是局部最优

●指标服务于度量目标： O-KR-指标定义（逐步拆解）

●指标不反映问题，那就没必要设计这个指标

●分层级设计，从三个层面逐层设计：结果（高层关注）<-过程（中层关注）<-操作（一线人员）a结果指标：用于衡量团队研发效能水平b过程指标：用于分析与发现效能改进点c操作指标：指导一线团队如何正确提升效能

‍

指标设计思路与建议：

‍

以“更高效、更高质量、更可靠、可持续地交付更优的业务价值”作为研发效能改进的核心目标来说，研发效能指标体系一般分为3个维度：价值、质量与速度，整体图示如下：

图1：研发效能指标体系架构图

‍

●价值：

‍

研发交付价值应该是需求背后的客户/公司战略价值(1)。对于研发侧而言，假设产品/业务提出的需求是具备充分的客户价值，且经过了准确的优先级分析，那么“需求量”+“业务满意度”基本可以代表“交付价值”，价值指标则可以设计如下：

‍

●质量：

研发交付质量，应该是指用户感受到的质量，但交付过程质量会对交付质量产生影响。 质量的指标建议参照以下方法来设计：

○交付质量：

○交付过程质量：

在设计交付过程质量指标时，常规设计思路是根据研发阶段“需求-开发&测试-发布”来组织，建议可以从以下指标中进行选取：

‍

除以上会影响交付质量的过程指标外，一些公司也希望针对“开发工程师”、“测试工程师”等各个角色的产出质量进行度量，比如“需求提测通过率”、“线上缺陷漏测率”等等。此处将“产出质量”作为交付过程质量的补充，定义如下：

‍

‍

需要注意的是：这些产出质量指标统计存在很大主观因素影响。比如，需求提测通过率中，“提测通过”的判定并没有统一的标准，实践中经常以“测试提供的Case”通过率来计算，统计结果严重依赖测试提供的Case范围，且每个测试工程师圈定标准也存在较大差异。

‍

因此，对于产出质量指标，本指南建议仅在度量分析时做参考使用，不应该作为单一维度指标来进行衡量和考核。

●速度（效率）：

‍

研发交付速度指标，则是用来体现“持续“与“快速”的，即单位价值的交付时长越短，交付速度越快。从结果与过程两个方向来拆分，指标设计建议如下：

‍

●操作指标：上面针对与效能相关的结果与过程指标做了详细介绍。三层体系中的操作指标，因与各个团队所采取的研发模式、基础平台建设成熟度，以及组织模式有很大相关性，本指南不做详细阐述，但操作层面的效率与质量，最终影响的是过程与结果指标。这里将业界常见的操作指标简单列出，供大家参考：

●持续集成成熟度相关：编译与构建时长/稳定性、部署时长/稳定性等等

●自动化测试相关：1）代码全量/增量自动化覆盖率。从自动化类型可区分单元测试、接口测试、验收测试等；从覆盖率计算角度，可分为行覆盖率、分支覆盖率、条件覆盖率等 2）自动化稳定性与拦截Bug能力等

●代码质量相关：代码可维护性（重复率、圈复杂度、注释率与可读性等）、代码依赖与制品规范等

●开发效率相关：本地编译时长、服务启动时长等等

●部署与架构相关：容灾能力、监控能力、故障自愈能力、资源调度能力等等3. 案例研究：国内某互联网大厂的研发效能指标体系

图2：某互联网大厂研发效能指标体系图如上图所示，该研发效能度量体系分为12个维度方向超过100个指标，指标体系有以下特点：

‍

●从设计思路上：它遵循持续交付的理念，对组织管理机制、软件系统架构与软件基础设施建设三个方面进行度量，针对需求、代码、环境、制品等提出了详细的研发效能度量指标，改进对象包括产品团队、开发团队、测试团队以及运维团队。

‍

●它的优势是：覆盖维度特别广，几乎涵盖了软件研发的各个层面，可以全方位推动研发底层能力的改革；此外不仅对最终结果指标有要求，同时也聚焦一线操作层面，可用于指导一线人员实践。

‍

●它的不足有：

a、部分维度指标选择不合理，如自动化测试维度追求代码覆盖率，但未综合考虑自动化拦截问题的能力。所以在实践上可能会出现“为了追求覆盖率，对非活跃但很好写测试Case的代码进行了自动化补充“、“代码覆盖率很高但实际拦截问题很弱的自动化手段”这样违背初衷的情况

‍

b、指标太多且层次不明显，结果指标、过程指标与操作指标没有很好的区分。在实际执行过程中容易形成过于关注“操作层面达标”，而忽视了“结果指标”。因为操作指标达标并不代表团队研发效能水平达标，前者并非后者的充分条件，也因此容易引发各角色之间的相互“甩锅”当然，根据业务效能所处的阶段，应该持续对研发效能指标体系进行更新，这一点也是本指南推荐大家参考的。

‍

研发效能度量指标体系设计的误区

‍

关于研发效能度量指标体系的设计，一般情况下存在以下误区：

‍

1、交付价值==需求数。

需求数越多交付价值就越多吗？因为需求有大小，拆分标准也不一定一致，所以需求数越多不代表交付价值越多

2、交付质量==缺陷密度——缺陷数/案例数、缺陷数/需求数、千行Bug率等都不适合用来度量交付质量。原因如下：

a、“案例”与“需求”的数量都依赖于拆分粒度，拆分粒度没有统一标准，依赖具体拆分执行的人。在实际度量中，很容易出现“粉饰”指标的现象

b、代码重复度、代码圈复杂度、架构设计是否合理等能更客观衡量代码质量的，并不能通过这一类指标体现出来。千行Bug率还有一个很经典的反例：同样的功能，同样的Bug数，代码写的更长的开发者千行Bug率更低。

3、交付价值，不建议使用 Average“均值”计算方式，建议使用中位数或分位数，如P50、P90等等。对于平均值，只需有一个点无穷大，均值就会无穷大量，从而使得均值失真，失去了度量的意义。以常见的效率过程指标“缺陷修复时长“为例：假设有100个缺陷，前99个各花费1小时，修复最后1个花了99个小时，那么平均时长就是1.98小时。平均值是99%的Bug修复时长的1.98倍，很显然产生了失真。请注意：如果研发效能度量指标的量化结果，跟大部分人主观感受不一致的话，就需要考虑下指标设计与定义是否合理了。