我特別反感那些不顧公司現狀一上來就想要做研發效能度量的人，尤其是想把研發效能度量當成錘子四處去敲打螺絲釘的人。
沒幾個人的小公司上來就做研發效能度量，就如同普通人一上來直接問媒婆怎麼能娶到迪麗熱巴。解決辦法無非把大象裝冰箱裡的那三步。套用一下，公司想要做好研發效能度量也有標準的三步：長時間對研發效能業務投入，建設好研發效能工具鏈，做好效能度量。現實是我們很多公司卡在了第一步上。我們可以邊做研發效能平臺邊做效能度量，但不能啥也沒有靠嘴造出來的效能度量，否則容易上下互相糊弄。
和一些老闆交流，經常被問到公司現在想做研發效能度量，要做什麼指標，怎麼做，多長時間能完成。做啥研發效能度量啊，先保證公司三年不倒再說。產研運同學在脈脈上噴公司的基建都噴出火星子了，還做啥研發效能度量。我建議不把這些小夥伴火上眉毛的事情解決，就不要做研發效能度量。
很多人想要些資料的心情是可以理解的，畢竟整天拍腦袋做決定太假大空了，自己心裡都發毛。如果能有一些產研運的資料，然後再拍腦袋也會容易些，所以一上來就想做研發效能度量。但是有時候，我們低估了做這件事的難度，高估了做這件事的效果。
舉個例子：
曾經有家公司的CTO想做研發效能度量，找PMO來驅動做這件事情。但是經過摸底發現現狀如下：
此時很多資料不具有真實性，系統間無法打通，需要人為校對、處理，指標不能自動獲取。其實如果我們站得角度高一些，應該坦誠地跟 CTO 去聊，我們現在這種情況根本不適合做效能度量，即便給出一份報表也是不真實的，無法反應實際產研運情況，如果再根據這個報表去做決策實際誤差也許還不如拍腦袋。結果「拿著尚方寶劍」的PMO要求限時、保質保量地要這麼一份報表，且以後定時出。結果可想而知，從多個資料庫中去比對時間「攢」出的一份報告，簡直不忍直視。還浪費了很多人力物力。
喬樑老師的《工程效率勝任力改善牽引指標體系》這篇文章(文末有連結)已經對研發效能度量的事情進行了很好的闡述，其中列出了19 個結果展示性指標，12 個維度的 50 個過程引導性指標，且在這篇文章的最後十分貼心地給出了「友情提示」：
- 明確研發效能度量的目標 -
要想做好研發效能首先要明確做的目的是什麼，是給管理層看統計資料，還是讓中基層瞭解業務執行情況做決策。
怎麼去解釋好數位背後的情景也需要很大的投入。我們來舉個例子
生產環境上線成功率：每個計算週期服務進行上線成功的次數/上線的總次數。
這個指標可以體現出服務上線的質量。這個指標是否管用呢？是的，管用。但是如果一味的追求指標的數值就會造成大家都不敢上線了，以前每天晚飯時間上線一次改成了只週四上一次線。對於一個功能正處在快速迭代的產品，我們更期待所有的功能能儘快推到使用者的面前，收集使用者的反饋，以便及時修改和增強。那麼過度追求這個指標對業務的發展就是有害的。
如果再加上一個上線次數的指標要求呢？也就說既要求上線次數多又要求上線成功率高。這個時候在沒有更好的方法保障質量和效率的情況下，就會對團隊造成很大壓力，團隊一般會要求增加人員投入，比如更多的開發和測試同學。
如果研發和測試同學「必須」不能加，上線次數「必須」保證，上線成功率也「必須」保證，怎麼辦？典型的既要又要還要的情形。這個時候團隊動作就會變得畸形了。產研運團隊會要求排入迭代的需求個數降低，同時會出現一些沒必要的上線動作。一些可改可不改的需求排了進去，一些大的需求會拆分成一些改動特別小的需求單獨上線。。。這樣看似上線次數沒變，每天都有東西上線，上線成功率提高了，且人數也沒加，但是多了很多意義不大的上線操作且最後上線的有價值的功能還少了。有變更就會有風險，有風險就可能會對使用者造成問題。一旦造成問題，業務負責人就得負責。典型的金玉其外敗絮其中。
- 本文小結 -
在還沒有長時間投入研發效能團隊的時候，在研發效能工具鏈還沒成型的時候，不要貿然做研發效能度量。研發效能度量也是需要成本的，而且是很高的成本。與其前期投入一個產出不高的工作，不如加強研發工具的建設，去支援產研運工作的研發，把研發效能團隊的價值在業務的增長和支援保障中體現出來。
參考：