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

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

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

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

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

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

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

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

图片来自 cynefin.io

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

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

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

说明：本节关于“熵”的内容，参考了纪录片《宇宙的奇迹：时间之箭》，感兴趣的同学，可以自行搜索观看。

当组织的外部业务环境从工业时代转到IT时代，甚至以后会进入数字化智能时代，组织内的员工从70、80后的主力军变换到Z世代时，研发领域的管理方式的探索已经成为了在复杂系统如何更好地进行演化的命题。

我们的观点是，复杂领域下的管理方式就需要不断吸取外部的优秀负熵，以开放的心态和组织形式来促使组织逆向做功，从而让组织从无序混乱转向有序发展。一套工具所收集下来的指标只是助力，组织需要了解这些指标背后设定的含义，以及如何让组织内的成员理解这些度量指标。

理念二：负熵也要长期主义

管理大师德鲁克说过，所有企业管理，说到底都是目标管理。许多时候企业乱成一团，都是目标不一致的结果，小张有小张的心思，小李有小李的想法，每个人各有想法，公司就无法聚焦目标，也就无法共同发力。

德鲁克认为，并不是有了工作才有目标，而是有了目标才能确定每个人的工作。企业的使命和任务，必须转化为目标。如果一个领域没有目标，这个领域的工作必然被忽视。

关于目标的设定，史蒂芬.柯维在《高效能人士的七个习惯》中提出的“以终为始”思维方式就是一种很好的实现目标的方式。做事前认清方向，确立目标，逐步推进。比如我们在前几篇文章中谈到，组建产品部落的初衷，也是基于组织业务目标聚合跨职能人才在一起，为了共同的业务目标更实施产品的设计、交付和运营。

那么，组织将研发效能的目标，定义为短期之内提升北极星指标是合理的么？

首先，大多数组织都有提升效能的意愿，从组织面临的内外部因素影响可知，在外部业务已经趋向于饱和或者萎缩时，组织会抓紧时间练内功，也就是聚焦于研发效能的提升。

那什么是研发部门的效能度量目标？我们可以尝试用以下问题和管理层对齐组织效能提升的思路：

上述问题，有助于我们去理解组织领导层对于研发效能提升的焦虑度，同时我们也需要了解到，管理者也经常会被追问到的一个问题，就是一段时间内资源投入的合理程度。

ROI是深入人心的衡量方法，合理的资源投入产效管理对组织最终的经济效益的确起到关键作用，原则上来说，产效管理的核心在于科学化的资源规划与分配和数字化的产效衡量与管理，问题在于：

简单来说，在管理者的任期内，已经投入了多少研发资源达到了多少业务效果，未来打算投入多少研发资源达到多少的业务效果？

这两个问题中的任何一个，对于管理者来说都不是一个容易回答的问题。

抛开无限游戏的说法，最佳解可能就是在有限的时间以内，分阶段的设置目标。

有些组织出于对研发效能建设短期目标的追求，不是搞单元测试覆盖率，就是CI/CD3个月从零开始覆盖所有系统。如果把每一个工程实践的提升都看做是一个小的变革，首先得考虑组织的变革准备度，以及你打算实施的变革饱和度。

变革饱和度过高时，团队反而会因为要去解决一些不紧急的技术债而拖延业务交付的时间。

整个研发效能的建设就好像是一个基建工程，要想实现飞轮效应，我们就不可能在超短的时间内就达到。

现阶段我们做的大多数还是破除0到1的过程，从靠管理者个人主观的感受团队的忙闲程度，到依据积累的历史数据以及和同行同形态的团队相对比找差异。

受制于组织内部的文化、能力水平，外部的大环境业务形态变化影响，只有当历史数据积累了一定时间以后，组织的合理资源投入才能有一个相对客观的数据展示。

理念三：关注球队，而非球员

一场球赛结束，你猜上台获奖的会是一个团队还是一个球员？

虽然我们都很通常会很欣赏那些明星球员，但是一场球赛的胜负核心还是在于团队。

图 / 来自Pexels，基于CC0协议

依据真实事件改编的电影《点球成金》中，职业经理人Billy在球队缺钱、明星成员接二连三被挖走的逆境中通过挖掘出一批平凡的选手，这些人或者年龄很大，或身体有恙，或打球姿势诡异，或个人生活混乱，最终依靠这个团队取到了他心中的梦想——冠军杯。

一场球赛中，有的球员负责冲锋，有的负责防守，除了个人能力以外更多是团队的协作。同样的，一个研发团队中，有的擅长编码，有的擅长沟通，有的擅长架构设计，他们也许都称之为程序员，职责也相同，在团队中发挥的作用范围或对象却有可能天差地别。

当球队管理者不去关注团队进球数多少，而去一心关注单个球员进球数时，球员自身更容易打乱自己的节奏。

因此，在研发效能度量体系中，我们会推荐以团队的效能度量为主，个人的数据可以做极端异常值的分析。

比如一个团队中，若有成员的代码提交量一直保持非常低的水平，可能管理者会需要关注此成员被分配的工作和能力是否匹配，另一个配套的管理手段是把团队人数拆小以后，类似每日站会的实践也能提前发现此类问题。（关于这个问题，可以查看我上一篇小队划分的文章，在文末有链接）

从另一个方面来说，将成员的各项指标建立数据模型，给人物贴上标签，按照团队的需要进行指标选择，从大量以往不可定量中快速找出团队的最优解。这也是电影中Billy给我们的启示，即如何用最低的成本创造最大的价值，更多的是一种商业化的考量。

理念四：指标也有生命周期，需要演进

软件业界中曾流行过的CMMI和敏捷流畅度模型等，都是依据演化的思路。组织的不同形态对应着不同的阶段，在软件研发的演化过程中因为加入了许多的变量，指标本身也是有着生命周期，需要演进的。

在2020年3月出版的《谷歌软件工程》中，谷歌将整个软件生命周期的度量管理分为了两部分：

在研发阶段工作的度量就由项目的PH(Project Health)值来进行度量。它取代了之前谷歌使用了八年的Test Certified(2008～2016)，一个很重要原因是，TC标准是静态的，当团队达到某个级别以后，就没有再进一步的动力提升级别，甚至项目实际情况已经降级了。这和业界中许多组织过了CMMI3评级后就一直停滞不前，甚至倒退的情况有些类似。

在之前，Agilean也提出过一个研发效能提升过程中指标演进路线图（文末推荐阅读有链接），供大家参考：

理念五：不能因噎废食

南京城里的后湖由于其得天独厚的优势，“周遭四十里，中突数洲，断岸千尺”被明朝设为黄册的存放地，也就是国家绝密档案库，当时的天下郡、县编制赋役都存于此，甚至有了“黄册、里甲制、鱼鳞图册在手，天下透明”的说法。

图 / 南京后湖，来自Pixabay

朱元璋为了让黄册可以得到很好的防护，可以说是殚精竭虑，整个玄武湖被整整封锁了近300年。结果呢，为了修改里面的数据，下面的人想了无数的方法，最狠的一招，是本来使用黄檗汁来做染黄使书籍防虫，被人替换为石黄，招致蠹鱼把黄册直接给吃掉了，神不知鬼不觉的把数据给消失掉。

所以，一旦涉及到利益时，人类的想象力和智慧是无穷的。上头有多少条政策，下面就有多少条对策。汉代搞案户比民，民间就敢舍匿虚田；隋唐有大索貌阅，民间士子就敢冒籍取解；宋代搞衙前差役，老百姓就会析居避役、鬻田减户。

同样的，研发团队要是按照代码行数来统计员工的奖金，那代码的隐形技术债估计也不会少。

从数据运营角度说，我们看到的是趋势，分析的是异常，开放性系统中我们一般会经历以下三个阶段：

阶段一：部门内部的数据共享

单个研发部门内部的数据收集及趋势呈现，有助于CTO改善部门内的管理方式及提升部门研发能力。

阶段二：组织内部的数据共享

组织内部各个部门研发效能数据的共享，可以在一定程度上透明化组织的整个研发部门数字化运营能力，有利于组织从全局层面做资源规划和分配的决策。

阶段三：跨组织的数据共享

研发效能的兴起加上标准的制定，不同组织都开始有意识的收集自身组织的数据，随着有效数据的清洗和治理，之后同行业之间就可以达到数据共享及行业的趋势预测。

德鲁克说，管理的本质，其实就是激发和释放每一个人的善意。

用数据来说话或者数据驱动是为了消除主观偏见，更多的人能在更短的时间内达成共识。

不排除在实际操作中我们因为某些原因在某一个阶段设定了一些不合理的指标，小步试错，指标的设定也是有假设-验证-修改这样不停迭代的过程。

理念六：情景化度量而非控制型度量

下图是一个团队的时效图，从图上你可以看出什么呢？

不同颜色的线条表示不同的前置时间，从图中可以看出，深蓝色最上面的那根时长是在增加的，而由上往下的第三根浅蓝色的线条时长在减少。对应的表示整个团队的研发时效在增加，而需求排期的时间在减少。

如果你不是团队的成员或者你完全不知道团队的情况，你可以知道这样变化的原因么？

大家说，我可以推测呀。

是的，假设-验证-反馈是一个科学化的正向反馈循环。

Keniberg提出过一个数据的验证模型DIBB，即DATA-INSIGHT-BELIEF-BET。从客观数据出发，激发洞见，设定假设，运营验证。从度量的方式来说，我们就是通过数据治理的方式来做组织的研发数据运营，帮助组织实现数据驱动的持续改善。

在日益复杂难测的组织环境中，管理者们可以看到，完全是流程性的从上而下的命令-控制性管理方式已经开始褪去光环，来自于军事领域的Mission Command管理方式更适合现今不确定性较高的组织管理领域。

我们可以从不同的团队数据中，得到不同的团队数据特征，并不要求所有的团队展现出来的都是一样的数据行为模式。当然，要选择控制型度量还是情景度量的判断因素可能有：

我们观察到组织的研发效能度量可能会经历4个不同阶段的流畅度，流畅度是指某个组织在面临压力时研发效能度量数据可视化呈现的方式。如果有足够的时间待在课堂里，每个人都能做到遵循一系列良好实践，但真正的流畅度是一种有技巧的日常实践，即使当你为其它事分心的时候，这种流畅度也不会离你而去。

对于研发效能度量来说，我们更关注于团队的研发效能度量流畅度，而非个人流畅度。

而团队的流畅度则更多地取决于团队中每个成员的能力，也取决于管理结构、关系、组织的文化等方面。请别误会，这并不是说团队的流畅度低下要归咎于个人，也不是说一个高水平成员的存在就能够保证整个团队的流畅度。

本文作者：

程萃，Agilean资深顾问，精益敏捷转型、研发效能度量专家。四川大学软件工程硕士，16余年软件和咨询行业经验，银行、软件开发企业、教育等行业从事过咨询和培训服务，曾深度服务于平安银行，建信金科等大型金融组织，帮助组织进行组织级的流程改进，部门级的技术、业务、组织协同的敏捷转型。