‍

阅读本文你将收获：

1、从生产管理推导出简化的研发效能度量模型

2、几款有赞研发效能团队正在采用的创新度量指标

3、如何借助效能度量来改进研发实践

‍

前言：我们邀请到有赞研发效能团队负责人费解老师参与 DevData Talks 直播活动，分享了《有赞研发效能度量实践》。以下是干货内容整理。

‍

嘉宾介绍：费解，有赞研发效能团队负责人，程序员出身，2016年加入有赞，用友PMP、PRINCE2、CSM、LeSS、六西格玛黄带、ITIL等多项认证和职业资格，正在国企、外企、外包和互联网企业等不同环境下从事项目管理和效能改进工作。

‍

研发效能度量模型

‍

『科学管理』之父泰勒提出，科学管理的根本目的是谋求最高劳动生产率，重要手段是用科学化、标准化的管理方法代替经验管理。

‍

在软件研发行业，生产资料包括了人和机器两大类，这两类生产资料各有长处：

• 人的特点：具备业务的理解和创新能力

• 机器的特点：能快速无误地执行既定命令

‍

从生产资料的视角，我们可以思考如何使人与机器各自发挥优势，实现生产率提升。可以简单分为三个思路：

1. 挖掘人的创造力，帮助开发者做得更好

2. 提高机器的执行效率，保障基础设施合理、方便、易用

3. 让机器分担部分原先需要人力投入的重复性工作，进一步释放开发者的创造性

基于这三个思路，我们可以梳理出一个全局框架，涵盖每个思路下的度量对象与相应度量方法。再从全局框架中挑选出适合业务与工程现状的对象，搭建起研发效能度量体系。

‍

有赞团队的创新指标

‍

研发浓度

项目浓度指标的计算公式是：项目浓度 = 项目工作量人日 /（研发周期*参与人数）。这个指标的侧重是某个项目中的资源利用率。

‍

相比需求吞吐量，研发浓度是一个过程性指标，可以在项目进程中持续被度量，先验性地反映研发效率；相比研发交付周期（流动效率，价值接收方视角）和资源利用率（员工的工作饱和度，资源效率，价值输出方视角），研发浓度处于二者之间，既能反映研发资源是否有效利用，也能在某一项目的视角下预判交付情况。

开发者掌握的功能模块和技能全面、外界打扰少、工作流简洁无依赖，都会带来更高的研发浓度。但在实践中，追求 100% 的研发浓度是不现实的。

‍

这个指标的意义在于帮助研发团队寻找典型案例，发掘可复用的优秀实践，以及协作行为、能力、项目管理、工具集等方面的提效机会。

‍

需求波动

需求波动指在一定时间范围内的，研发团队的需求总量与交付需求数量趋势与离散程度（用样本标准差来反映）。这个指标可以用于部门或项目级的横向对比，寻找生产平稳程度较差的关键下钻点。

如果研发团队进行工程改进试点，需求波动可以作为反映改进效果的指标之一。例如某团队正在试点敏捷转型，那么需求波动可以反映交付模式调整是否给需求管理、项目管理带来了正向的变化。

‍

研发效能度量指导改进落地的三条原则

‍

基于有赞的研发效能实践，以下总结三条原则，能够帮助研发效能团队与业务研发团队达成共识，共同推进度量落地。

‍

透明现状

效能度量源头是数据观测，呈现>评价。客观现象的呈现本身就有价值，避免呈现之上附加太多判断评价，引起业务研发团队抵触

感知问题

度量抓手是指标被共同看见后的价值，我以为>你觉得。效能团队与业务研发团队应达成共识，以专业知识提供支持，引导业务团队主动发现问题，避免单向输出。

激发改进

度量是反映自管理效果的镜子，意愿>命令。在感知问题的基础上，效能团队应引导业务团队主动思考改进策略，让最了解上下文的角色去主导改进。

‍