做了5年研发效能度量，我的6点思考

本文通过对研发效能度量领域6个常见问题的分析，阐述了作者对于研发效能度量的6点思考。因部分观点的抽象层次较高，建议收藏后细读，相信对帮助大家理清研发效能度量理念、建立度量体系会有所帮助。

随着近几年市场和政策对于数字化转型的重视，研发效能的话题也是铺天盖地而来，从百度指数可看出，从21年下半年开始，“研发效能”四个字开始成为了热门词汇。

业界里面也因此有了许多的研发效能标准，比如阿里的五组效能度量指标，百度的工程能力白皮书里包含的效能度量体系，腾讯PCG的EPC模型，以及最新出炉的由中国信通院牵头的《研发运营一体化（DevOps）通用效能度量模型》等等。

从这些度量体系的整体架构我们都可以看出整个度量体系的趋势都会是分层、分对象、分阶段，目标管理、动机驱动，从不同的维度去可视化、透明化研发这个黑盒子，回顾历史以期望可以得到预测性。

笔者曾参与国内多家金融企业度量体系建设过程，在此想和大家分享一些在研发效能度量体系建设过程中的思考。

问题一：我们公司想进行敏捷/DevOps转型，已经咨询过好多工具DevOps平台厂商，研发效能度量不就是引入一个工具就可以了么？

理念一：对抗复杂系统的演化需要熵减

虽然大多数组织都有研发的一系列流程、规范，甚至工具的支撑，本质上来说软件开发还是属于一个复杂的领域，而不是类似以往工业时代的有序的、生产线类型的系统。仅仅引入一个工具而不是做研发效能操作系统的整体升级，很有可能达不到最开始所期待的效果。

为何将软件研发定义为一个复杂的系统？

George Rzevski 教授层提供了一套复杂性的最佳标准：

1. 交互-复杂系统由大量参与丰富交互的不同组件（代理）组成

2. 自主-代理在很大程度上是自主的，但受制于某些法律、规则或规范；没有中央控制，但代理行为不是随机的

3. 涌现-复杂系统的整体行为从代理的交互中“涌现”，因此是不可预测的

4. 远离平衡-复杂系统“远离平衡”，因为频繁发生的破坏性事件不允许系统返回平衡

5. 非线性-非线性偶尔会导致微不足道的输入被放大为极端事件（蝴蝶效应)

6. 自组织-复杂系统能够自组织以应对破坏性事件

7. 共同进化-复杂系统与其环境不可逆转的共同进化

图片来自 cynefin.io

在Joseph多年前在一个大会上和300多名参会的软件开发人员做了一场Cynefin的“Butterfly stamping”工作坊，目的探索软件开发作为一个整体是否可以被认为是一个复杂的领域，他们得到了以下的共识：

• 软件开发是一个丰富的领域，在所有不同领域都有多个方面和活动。这些方面和活动之间的交互本身往往是复杂的。

• 软件开发是一个具有自相似特征的多层次领域，即活动通常由子活动组成，每个子活动可能位于与基本活动不同的域中。

• 活动往往更侧重于繁杂和复杂的领域，与软件开发的编码方面相关的活动落在繁杂（或有时简单）的领域，而与项目管理相关的活动则落在复杂的（有时是混乱的）领域。处理与计算机交互的任务倾向于在有序域中，处理与其他人交互的任务倾向于在无序（即，复杂和混乱）域中。

• 绝大多数的软件研发任务和活动都属于复杂领域。

复杂系统的演化，我们需要提到另一个概念：熵。

鲁道夫.克劳修斯发现热力学第二定律时定义了熵，熵是无序的混乱程度，熵增是世界上一切事物发展的自然倾向，即从井然有序走向混乱无序，最终灭亡。

如果把一个组织看成生命体：

• 熵增就是功能减弱，生命体的衰老，也就是组织的懈怠、价值创造乏力等

• 熵减指功能增强，生命体摄入食物、组织建立秩序等实现熵