我特地恶感那些不顾公司现状一上来就想要做研发效力度量的人，尤其是想把研发效力度量当成锤子到处去敲打螺丝钉的人。

没几个人的小公司上来就做研发效力度量，就如同普通人一上来间接问媒婆怎么能娶到迪丽热巴。解决办法无非把大象装冰箱里的那三步。套用一下，公司想要做好研发效力度量也有规范的三步：长时间对研发效力业务投入，建设好研发效力工具链，做好效力度量。事实是咱们很多公司卡在了第一步上。咱们能够边做研发效力平台边做效力度量，但不能啥也没有靠嘴造出来的效力度量，否则容易高低相互糊弄。

  • 长时间对研发效力业务投入
  • 欠缺研发效力工具链建设
  • 做好研发效力度量

和一些老板交换，常常被问到公司当初想做研发效力度量，要做什么指标，怎么做，多长时间能实现。做啥研发效力度量啊，先保障公司三年不倒再说。产研运同学在脉脉上喷公司的基建都喷出火星子了，还做啥研发效力度量。我倡议不把这些小伙伴火上眉毛的事件解决，就不要做研发效力度量。

很多人想要些数据的情绪是能够了解的，毕竟终日拍脑袋做决定太假大空了，本人心里都发毛。如果能有一些产研运的数据，而后再拍脑袋也会容易些，所以一上来就想做研发效力度量。然而有时候，咱们低估了做这件事的难度，高估了做这件事的成果。

举个例子：

已经有家公司的CTO想做研发效力度量，找PMO来驱动做这件事件。然而通过摸底发现现状如下：

  • 1）所有工作在 jira 中
  • 2）代码在 gitlab 中
  • 3）编译，构建，上线在公布零碎中。只能按分支公布，不反对按 commit 公布，公布时可抉择 jira 工作(非必须)
  • 4）PMO的小伙伴不晓得从哪里收集的，列举了各种度量指标，一个个问，这个指标是否能够出，怎么出，啥时候能失去。

此时很多数据不具备真实性，零碎间无奈买通，须要人为校对、解决，指标不能主动获取。其实如果咱们站得角度高一些，应该坦诚地跟 CTO 去聊，咱们当初这种状况基本不适宜做效力度量，即使给出一份报表也是不实在的，无奈反馈理论产研运状况，如果再依据这个报表去做决策理论误差兴许还不如拍脑袋。后果「拿着尚方宝剑」的PMO要求限时、保质保量地要这么一份报表，且当前定时出。后果可想而知，从多个数据库中去比对工夫「攒」出的一份报告，几乎不忍直视。还节约了很多人力物力。

乔梁老师的《工程效率胜任力改善牵引指标体系》这篇文章(文末有链接)曾经对研发效力度量的事件进行了很好的论述，其中列出了19 个后果展现性指标，12 个维度的 50 个过程引导性指标，且在这篇文章的最初非常贴心地给出了「情谊提醒」：

  • 度量有老本，而且不低
  • 当指标变成指标后，它就不再是好的指标
  • 指标最终都会被捉弄
  • 改良不应「唯数字论」

明确研发效力度量的指标

要想做好研发效力首先要明确做的目标是什么，是给管理层看统计数据，还是让中基层理解业务运行状况做决策。

  • 很多数据一「均匀」就覆盖掉了「大多数」问题，且变得毫无意义
  • 不同团队，甚至同一团队的不同期间的效力都有所差别，通过简略几个数字未必能无效度量
  • 出一些度量报告很容易，难的是通过度量报告进行根因剖析，看到背地的问题；
  • 即使数字雷同，背地的理论状况也是千差万别
  • 最好的「研发效力度量报告」是团队负责人：他们晓得团队的效力，晓得团队的问题在哪里，团队哪里效力低，怎么能力改良
  • 之所以「忍耐」一些低效能低体现，是因为有「更高优的」工作或者有一些「难以诉说」的苦衷，这要靠好高鹜远深刻一线去挖掘。
  • 其次是每天工作在一线的同学，如果他们都不晓得效力低的起因，却想通过一些度量指标反馈进去，这是有悖常理的。

怎么去解释好数字背地的情景也须要很大的投入。咱们来举个例子

生产环境上线成功率：每个计算周期服务进行上线胜利的次数/上线的总次数。
  • 这个指标能够体现出服务上线的品质。这个指标是否管用呢？是的，管用。然而如果一味的谋求指标的数值就会造成大家都不敢上线了，以前每天晚饭时间上线一次改成了只周四上一次线。对于一个性能正处在疾速迭代的产品，咱们更期待所有的性能能尽快推到用户的背后，收集用户的反馈，以便及时批改和加强。那么适度谋求这个指标对业务的倒退就是无害的。
  • 如果再加上一个上线次数的指标要求呢？也就说既要求上线次数多又要求上线成功率高。这个时候在没有更好的办法保障品质和效率的状况下，就会对团队造成很大压力，团队个别会要求减少人员投入，比方更多的开发和测试同学。
  • 如果研发和测试同学「必须」不能加，上线次数「必须」保障，上线成功率也「必须」保障，怎么办？典型的既要又要还要的情景。这个时候团队动作就会变得畸形了。产研运团队会要求排入迭代的需要个数升高，同时会呈现一些没必要的上线动作。一些可改可不改的需要排了进去，一些大的需要会拆分成一些改变特地小的需要独自上线。。。这样看似上线次数没变，每天都有货色上线，上线成功率进步了，且人数也没加，然而多了很多意义不大的上线操作且最初上线的有价值的性能还少了。有变更就会有危险，有危险就可能会对用户造成问题。一旦造成问题，业务负责人就得负责。典型的金玉其外败絮其中。

- 本文小结 -

在还没有长时间投入研发效力团队的时候，在研发效力工具链还没成型的时候，不要贸然做研发效力度量。研发效力度量也是须要老本的，而且是很高的老本。与其后期投入一个产出不高的工作，不如增强研发工具的建设，去反对产研运工作的研发，把研发效力团队的价值在业务的增长和反对保障中体现进去。

参考：

工程效率胜任力改善牵引指标体系
infra ｜ devops工具链基建建设评估规范
DevOps | 研发效力价值如何掂量
DevOps｜研发效力不是老板工程，是开发者服务