我特別反感那些不顧公司現狀一上來就想要做研發效能度量的人，尤其是想把研發效能度量當成錘子四處去敲打螺絲釘的人。

沒幾個人的小公司上來就做研發效能度量，就如同普通人一上來直接問媒婆怎么能娶到迪麗熱巴。解決辦法無非把大象裝冰箱里的那三步。套用一下，公司想要做好研發效能度量也有標準的三步：長時間對研發效能業務投入，建設好研發效能工具鏈，做好效能度量。現實是我們很多公司卡在了第一步上。我們可以邊做研發效能平臺邊做效能度量，但不能啥也沒有靠嘴造出來的效能度量，否則容易上下互相糊弄。

• 長時間對研發效能業務投入
• 完善研發效能工具鏈建設
• 做好研發效能度量

和一些老板交流，經常被問到公司現在想做研發效能度量，要做什么指標，怎么做，多長時間能完成。做啥研發效能度量啊，先保證公司三年不倒再說。產研運同學在脈脈上噴公司的基建都噴出火星子了，還做啥研發效能度量。我建議不把這些小伙伴火上眉毛的事情解決，就不要做研發效能度量。

很多人想要些數據的心情是可以理解的，畢竟整天拍腦袋做決定太假大空了，自己心里都發毛。如果能有一些產研運的數據，然后再拍腦袋也會容易些，所以一上來就想做研發效能度量。但是有時候，我們低估了做這件事的難度，高估了做這件事的效果。

舉個例子：

曾經有家公司的CTO想做研發效能度量，找PMO來驅動做這件事情。但是經過摸底發現現狀如下：

• 1）所有任務在 jira 中
• 2）代碼在 gitlab 中
• 3）編譯，構建，上線在發布系統中。只能按分支發布，不支持按 commit 發布，發布時可選擇 jira 任務(非必需)
• 4）PMO的小伙伴不知道從哪里收集的，羅列了各種度量指標，一個個問，這個指標是否可以出，怎么出，啥時候能得到。

此時很多數據不具有真實性，系統間無法打通，需要人為校對、處理，指標不能自動獲取。其實如果我們站得角度高一些，應該坦誠地跟 CTO 去聊，我們現在這種情況根本不適合做效能度量，即便給出一份報表也是不真實的，無法反應實際產研運情況，如果再根據這個報表去做決策實際誤差也許還不如拍腦袋。結果「拿著尚方寶劍」的PMO要求限時、保質保量地要這么一份報表，且以后定時出。結果可想而知，從多個數據庫中去比對時間「攢」出的一份報告，簡直不忍直視。還浪費了很多人力物力。

喬梁老師的《工程效率勝任力改善牽引指標體系》這篇文章(文末有鏈接)已經對研發效能度量的事情進行了很好的闡述，其中列出了19 個結果展示性指標，12 個維度的 50 個過程引導性指標，且在這篇文章的最后十分貼心地給出了「友情提示」：

• 度量有成本，而且不低
• 當指標變成目標后，它就不再是好的指標
• 指標最終都會被玩弄
• 改進不應「唯數字論」

- 明確研發效能度量的目標 -

要想做好研發效能首先要明確做的目的是什么，是給管理層看統計數據，還是讓中基層了解業務運行情況做決策。

• 很多數據一「平均」就掩蓋掉了「大多數」問題，且變得毫無意義
• 不同團隊，甚至同一團隊的不同時期的效能都有所差異，通過簡單幾個數字未必能有效度量
• 出一些度量報告很容易，難的是通過度量報告進行根因分析，看到背后的問題；
• 即便數字相同，背后的實際情況也是千差萬別
• 最好的「研發效能度量報告」是團隊負責人：他們知道團隊的效能，知道團隊的問題在哪里，團隊哪里效能低，怎么才能改進
• 之所以「忍受」一些低效能低表現，是因為有「更高優的」工作或者有一些「難以訴說」的苦衷，這要靠腳踏實地深入一線去發掘。
• 其次是每天工作在一線的同學，如果他們都不知道效能低的原因，卻想通過一些度量指標反饋出來，這是有悖常理的。

怎么去解釋好數字背后的情景也需要很大的投入。我們來舉個例子

生產環境上線成功率：每個計算周期服務進行上線成功的次數/上線的總次數。

 

這個指標可以體現出服務上線的質量。這個指標是否管用呢？是的，管用。但是如果一味的追求指標的數值就會造成大家都不敢上線了，以前每天晚飯時間上線一次改成了只周四上一次線。對于一個功能正處在快速迭代的產品，我們更期待所有的功能能盡快推到用戶的面前，收集用戶的反饋，以便及時修改和增強。那么過度追求這個指標對業務的發展就是有害的。

如果再加上一個上線次數的指標要求呢？也就說既要求上線次數多又要求上線成功率高。這個時候在沒有更好的方法保障質量和效率的情況下，就會對團隊造成很大壓力，團隊一般會要求增加人員投入，比如更多的開發和測試同學。

如果研發和測試同學「必須」不能加，上線次數「必須」保證，上線成功率也「必須」保證，怎么辦？典型的既要又要還要的情形。這個時候團隊動作就會變得畸形了。產研運團隊會要求排入迭代的需求個數降低，同時會出現一些沒必要的上線動作。一些可改可不改的需求排了進去，一些大的需求會拆分成一些改動特別小的需求單獨上線。。。這樣看似上線次數沒變，每天都有東西上線，上線成功率提高了，且人數也沒加，但是多了很多意義不大的上線操作且最后上線的有價值的功能還少了。有變更就會有風險，有風險就可能會對用戶造成問題。一旦造成問題，業務負責人就得負責。典型的金玉其外敗絮其中。

- 本文小結 -

在還沒有長時間投入研發效能團隊的時候，在研發效能工具鏈還沒成型的時候，不要貿然做研發效能度量。研發效能度量也是需要成本的，而且是很高的成本。與其前期投入一個產出不高的工作，不如加強研發工具的建設，去支持產研運工作的研發，把研發效能團隊的價值在業務的增長和支持保障中體現出來。

參考：

工程效率勝任力改善牽引指標體系

infra ｜ devops工具鏈基建建設評價標準

DevOps | 研發效能價值如何衡量

DevOps｜研發效能不是老板工程，是開發者服務