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