我特别反感那些不顾公司现状一上来就想要做研发效能度量的人，尤其是想把研发效能度量当成锤子四处去敲打螺丝钉的人。
没几个人的小公司上来就做研发效能度量，就如同普通人一上来直接问媒婆怎么能娶到迪丽热巴。解决办法无非把大象装冰箱里的那三步。套用一下，公司想要做好研发效能度量也有标准的三步：长时间对研发效能业务投入，建设好研发效能工具链，做好效能度量。现实是我们很多公司卡在了第一步上。我们可以边做研发效能平台边做效能度量，但不能啥也没有靠嘴造出来的效能度量，否则容易上下互相糊弄。
- 长时间对研发效能业务投入
- 完善研发效能工具链建设
- 做好研发效能度量
和一些老板交流，经常被问到公司现在想做研发效能度量，要做什么指标，怎么做，多长时间能完成。做啥研发效能度量啊，先保证公司三年不倒再说。产研运同学在脉脉上喷公司的基建都喷出火星子了，还做啥研发效能度量。我建议不把这些小伙伴火上眉毛的事情解决，就不要做研发效能度量。
很多人想要些数据的心情是可以理解的，毕竟整天拍脑袋做决定太假大空了，自己心里都发毛。如果能有一些产研运的数据，然后再拍脑袋也会容易些，所以一上来就想做研发效能度量。但是有时候，我们低估了做这件事的难度，高估了做这件事的效果。
举个例子：
曾经有家公司的CTO想做研发效能度量，找PMO来驱动做这件事情。但是经过摸底发现现状如下：
- 1）所有任务在 jira 中
- 2）代码在 gitlab 中
- 3）编译，构建，上线在发布系统中。只能按分支发布，不支持按 commit 发布，发布时可选择 jira 任务(非必需)
- 4）PMO的小伙伴不知道从哪里收集的，罗列了各种度量指标，一个个问，这个指标是否可以出，怎么出，啥时候能得到。
此时很多数据不具有真实性，系统间无法打通，需要人为校对、处理，指标不能自动获取。其实如果我们站得角度高一些，应该坦诚地跟 CTO 去聊，我们现在这种情况根本不适合做效能度量，即便给出一份报表也是不真实的，无法反应实际产研运情况，如果再根据这个报表去做决策实际误差也许还不如拍脑袋。结果「拿着尚方宝剑」的PMO要求限时、保质保量地要这么一份报表，且以后定时出。结果可想而知，从多个数据库中去比对时间「攒」出的一份报告，简直不忍直视。还浪费了很多人力物力。
乔梁老师的《工程效率胜任力改善牵引指标体系》这篇文章(文末有链接)已经对研发效能度量的事情进行了很好的阐述，其中列出了19 个结果展示性指标，12 个维度的 50 个过程引导性指标，且在这篇文章的最后十分贴心地给出了「友情提示」：
- 度量有成本，而且不低
- 当指标变成目标后，它就不再是好的指标
- 指标最终都会被玩弄
- 改进不应「唯数字论」
- 明确研发效能度量的目标 -
要想做好研发效能首先要明确做的目的是什么，是给管理层看统计数据，还是让中基层了解业务运行情况做决策。
- 很多数据一「平均」就掩盖掉了「大多数」问题，且变得毫无意义
- 不同团队，甚至同一团队的不同时期的效能都有所差异，通过简单几个数字未必能有效度量
- 出一些度量报告很容易，难的是通过度量报告进行根因分析，看到背后的问题；
- 即便数字相同，背后的实际情况也是千差万别
- 最好的「研发效能度量报告」是团队负责人：他们知道团队的效能，知道团队的问题在哪里，团队哪里效能低，怎么才能改进
- 之所以「忍受」一些低效能低表现，是因为有「更高优的」工作或者有一些「难以诉说」的苦衷，这要靠脚踏实地深入一线去发掘。
- 其次是每天工作在一线的同学，如果他们都不知道效能低的原因，却想通过一些度量指标反馈出来，这是有悖常理的。
怎么去解释好数字背后的情景也需要很大的投入。我们来举个例子
生产环境上线成功率：每个计算周期服务进行上线成功的次数/上线的总次数。
这个指标可以体现出服务上线的质量。这个指标是否管用呢？是的，管用。但是如果一味的追求指标的数值就会造成大家都不敢上线了，以前每天晚饭时间上线一次改成了只周四上一次线。对于一个功能正处在快速迭代的产品，我们更期待所有的功能能尽快推到用户的面前，收集用户的反馈，以便及时修改和增强。那么过度追求这个指标对业务的发展就是有害的。
如果再加上一个上线次数的指标要求呢？也就说既要求上线次数多又要求上线成功率高。这个时候在没有更好的方法保障质量和效率的情况下，就会对团队造成很大压力，团队一般会要求增加人员投入，比如更多的开发和测试同学。
如果研发和测试同学「必须」不能加，上线次数「必须」保证，上线成功率也「必须」保证，怎么办？典型的既要又要还要的情形。这个时候团队动作就会变得畸形了。产研运团队会要求排入迭代的需求个数降低，同时会出现一些没必要的上线动作。一些可改可不改的需求排了进去，一些大的需求会拆分成一些改动特别小的需求单独上线。。。这样看似上线次数没变，每天都有东西上线，上线成功率提高了，且人数也没加，但是多了很多意义不大的上线操作且最后上线的有价值的功能还少了。有变更就会有风险，有风险就可能会对用户造成问题。一旦造成问题，业务负责人就得负责。典型的金玉其外败絮其中。
- 本文小结 -
在还没有长时间投入研发效能团队的时候，在研发效能工具链还没成型的时候，不要贸然做研发效能度量。研发效能度量也是需要成本的，而且是很高的成本。与其前期投入一个产出不高的工作，不如加强研发工具的建设，去支持产研运工作的研发，把研发效能团队的价值在业务的增长和支持保障中体现出来。
参考：
工程效率胜任力改善牵引指标体系
infra ｜ devops工具链基建建设评价标准
DevOps | 研发效能价值如何衡量 DevOps｜研发效能不是老板工程，是开发者服务
