作者 | 張樂
編輯 | 蔡芳芳
研發效能度量的出發點雖然很好，但是如何正確、有效地度量卻是一個頗有難度的技術活兒。近期圍繞如何進行效能度量的討論不絕於耳，但如何構建度量的體系化框架、如何進行度量指標的選取、如何進行度量分析、如何進行落地運營，卻鮮有文章具體闡述。在這一背景下，張樂老師撰寫了《研發效能度量核心方法與實踐》系列文章，對以往經驗進行了總結和提煉，包括以下內容：
1。效能度量的難點和反模式
2。效能度量的行業案例和關鍵原則
3。 效能度量的實踐框架和指標體系設計
4。 效能度量的常用分析方法
5。 效能度量的落地實施建議
以上內容將以五篇連載文章的形式釋出，共計超過 3 萬字，本文是第三篇。
在前兩篇文章中，我們分別介紹了研發效能度量的難點和反模式、BAT 等網際網路大廠的研發效能度量體系案例和關鍵原則。本篇文章，我會介紹名為“研發效能度量的五項精進”的度量實踐框架，詳細展開根據這幾年經驗總結出來的研發效能度量指標集設計、關鍵指標定義，並會對指標設計過程中的常見疑問進行解答。
研發效能度量的實踐框架
研發效能度量的成功落地需要一個相對完善的體系，其中包含資料採集、度量指標設計、度量模型構建、度量產品建設、資料運營等多個方面，我把它們整理出來形成一個實踐框架，稱為
“研發效能度量的五項精進”
。
1。 構建自動採集效能資料的能力
透過度量系統分層處理好資料接入、儲存計算和資料分析。比如，小型團隊透過 MQ、API 等方式把資料採集起來之後，使用 MySql（存放明細資料和彙總資料）、Redis（存放快取資料）、ES（資料聚合和檢索分析）三件套基本就夠用了；而大規模企業由於資料量龐大、匯聚和分析邏輯複雜，建議使用整套大資料分析解決方案，比如流行的流批一體的大資料分析架構。
2。 設計效能度量指標體系
選取全域性結果指標用於評估能力，區域性過程指標用於指導分析改進。比如：需求交付週期、需求吞吐量就是全域性結果指標，可用於對交付效率進行整體評估；交付各階段耗時、需求變更率、需求評審透過率、缺陷解決時長就是區域性過程指標，可用於指導分析改進。
透過先導性指標進行事前干預，透過滯後性指標進行事後覆盤。比如：
流動負載（在製品數量）是一個先導性指標
，根據利特爾法則，在製品過高一定會導致後續的交付效率下降、交付週期變長，所以識別到這類問題就要進行及時干預；而線上缺陷密度就是一個滯後性指標，線上缺陷已經發生了，我們能做的就只有覆盤、對缺陷根因進行分析，爭取在下個統計週期內能讓質量提升、指標好轉。
3。 建立效能度量分析模型
這裡的模型是指對研發效能問題、規律進行抽象後的一種形式化的表達方式。比如流時間（需求交付週期）、流速率（需求吞吐量）、流負載、流效率、流分佈這五個指標結合在一起，就是一個典型的分析產品 / 團隊交付效率的模型，透過這個模型可以講述一個交付交付價值流完整的故事，回答一個關於交付效率的本質問題。
模型還有很多種，比如組織效能模型（如戰略資源投入分佈和合理性）、產品 / 團隊效能模型、工程師效能模型等，我們還要合理採用趨勢分析、相關性分析、診斷分析等方法，分析效能問題、指導效能改進。
4。 設計和實現效能度量產品
將資料轉化為資訊，然後將資訊轉化為知識，讓使用者可以自助消費資料，主動進行分析和洞察。
簡單的度量產品以展示度量指標為主，比如按照部門、產品線等維度進行指標卡片和指標圖表的展現；做的好一點的度量產品可以加入各種分析能力，可以進行下鑽上卷，可以進行趨勢分析、對比分析等；而做的比較完善的度量產品應該自帶各種分析模型和邏輯，面向使用者遮蔽理論和資料關係的複雜性，直接輸出效能報告，並提供問題根因分析和改進建議，讓對效能分析不是很熟悉的人也能自助地使用。
5。 實現有效的效能資料運營體系
也許放在最後的其實才是最重要的，我們有了度量指標、有了度量模型、有了度量產品，但一定要注意的是：要避免不正當使用度量而產生的負面效果，避免將度量指標 KPI 化而導致“造資料“的短視行為。根據古德哈特定律，度量不是武器，而是學習和持續改進的工具。
正所謂“上有政策，下有對策”，“度量什麼就會得到什麼“，為了避免度量帶來的各種副作用，我們首要的度量物件應該是工作本身，而不是工作者。另外，效能改進的運作模式也很重要，只是把資料報表放在那裡效能不會自己變好，需要有團隊或專人負責推動改進事宜。
研發效能度量的指標體系設計
根據研發效能度量的七大原則，我們確定了從全域性性出發，以結果產出為牽引的一系列研發效能度量指標 。這些指標也反映出了研發效能改進的關鍵點，即以端到端的流動效率（而非資源效率）為核心。這裡的流動效率是指需求（或使用者價值）在整個系統中跨越不同職能和團隊流動的速度，速度越快則需求交付的效率越高、交付時長越短。當然我們並不是只關注流動效率、不關注資源效率（如工時、資源利用率等），而是
在確保前者效率足夠高的情況下再逐步提升後者，最終追求的是二者的協同最佳化
。
在建設初期，我們把研發效能度量指標分為三個維度，分別是交付效率、交付質量和交付能力。這些指標的提升需要組織進行管理、工程、技術等多方面的系統性改進
1。 交付效率
目標是促進端到端、及早的交付，用最短的時間順暢地交付使用者價值。具體可細分為以下指標：
需求前置時間
：也稱為需求交付週期，是指從需求提出，到完成開發、測試，直到完成上線的時間週期。反映了整個團隊（包含業務、產品、開發、測試、運維等職能）對客戶問題或業務機會的交付速度，依賴整個組織各職能和部門的協調一致和緊密協作。從資料統計的角度來看，需求前置時間指標通常符合韋伯分佈，我們要儘量避免度量的平均值陷阱，建議使用 85 百分位數進行統計分析，相關細節將在後續文章中展開說明。
產研交付週期
：從需求被產研團隊確認，到完成開發、測試，直到完成上線的時間週期。反映了產研團隊的交付速度，依賴需求的拆分和管理，研發團隊的分工協作。
需求吞吐量
：統計週期內交付的需求個數 / 統計週期，即單位時間交付的需求個數。需要注意的是，需求顆粒度要保持一定規則（如約定業務需求、產品需求的顆粒度上限），避免需求大小不統一導致的資料偏差。
2。 交付質量
目標是促進端到端高質量交付，避免不必要的錯誤和返工。具體可細分為以下指標：
線上缺陷密度
：統計週期內線上或單個版本嚴重級別 Bug 數量 / 需求個數。
故障恢復時間
：線上系統和應用如果發生故障，多長時間可以進行恢復。
變更成功率
：上線部署成功，且沒有導致服務受損、降級或需要事後補救的比例。
3。 交付能力
目標是建設卓越的工程能力，實現持續交付。具體可細分為以下指標：
部署頻率
：單位時間內的有效部署次數。團隊對外響應的速度不會大於其部署頻率，部署頻率約束了團隊對外響應和價值的流動速度。
變更前置時間
：程式碼提交到功能上線的時長。反映了團隊的工程技術能力，依賴交付過程中高度自動化以及架構、研發基礎設施的支撐能力。
我們落地的任何研發效率提升實踐，推動的任何敏捷或 DevOps 轉型，其目標都應該要促進交付效率、交付質量、交付能力中一個或多個要素的提升，而其中交付能力的提升通常需要一定的週期沉澱和積累，所以是延遲反饋的，但最終還是會體現在效率或質量的提升上。
交付效率、交付質量、交付能力的提升會推動軟體研發效能的提升，而研發效能的提升最終會助力組織效能的提升和業務結果的最佳化。所以，我們在設計度量指標體系時，還應該增加業務結果維度的考量，包括業務價值、交付成本和滿意度（包括客戶滿意度 NPS 及員工滿意度 eNPS）。這樣的指標體系才更完整，才更能體現出研發效能提升對於組織效能提升的貢獻。
所以，完整的指標維度設計應該是“3+1”的形式，即三個研發交付的維度，再加上一個業務結果的維度。
研發效能度量指標體系的設計還要結合組織中實際的研發價值流，並且在三個研發交付指標維度的基礎之上，更多地考慮到價值的流動性，並增加相關的度量指標。下圖展示了某網際網路大廠典型的研發價值流，並且由此擴展出來一些新的度量指標項。
在圖中，我們可以看到存在兩層價值流。第一層是需求價值流，流動的單元是業務需求，這是業務人員的核心關注點，目標是業務需求交付的效率和效果。主要節點包括：需求建立、需求受理、需求拆分和處理、需求開發測試併發布上線、需求發起驗收，業務驗收透過。第二層是產品交付價值流，流動的單元是業務需求拆解到葉子節點後形成的產品需求，目標是提高產品需求的持續交付能力，包括效率、質量和可預測性。產品需求由具體的敏捷交付團隊承接，經過準備、評審、就緒、設計、開發、測試、釋出等狀態，直到完成。兩層價值流之間存在承接和對齊的關聯關係，產品需求的研發狀態會回溯到業務需求層面進行資訊同步。
根據圖中不同階段的起始點，我們定義了多個週期類指標，包括端到端的交付週期和某個分段的交付週期。我們之前用文字描述的需求前置時間、產研交付週期在圖中就可以展示的非常清晰。另外，我還特別繪製了一個虛線的管狀圖形，覆蓋從需求受理到釋出上線的過程，這就是我們重點要關注的交付管道。除了交付週期類指標（也稱流時間）外，這裡還有幾個指標值得單獨說明下：
流速率
：單位時間內流經交付管道的工作項數量就是流速率，也就是我能常說的吞吐量。流分佈：單位時間內流經交付管道的需求中，不同工作項型別的佔比（包括需求、缺陷、風險、技術債等）就是流分佈，這個指標可以衡量團隊工作量是花在開發新需求、被動救火還是主動解決技術債上，對於工作計劃的合理分配有一定指導意義。
流負載
：在交付管道中已經開始、尚未完成的工作項的數量就是流負載，其實就是我們經常說的在製品數量。流負載是一個關鍵的先導性指標，流負載過高一定會導致後續的交付效率下降、交付週期變長，所以識別到這類問題就要進行及時干預。
流效率
：在交付管道中工作項處於活躍工作狀態的時間（無阻塞地工作）與總交付時間（活躍工作時間 + 等待時間）的比率就是流效率。調查表明，很多企業的流效率只有不到 10%，也就意味著需求在交付管道中有大量時間都處於停滯、阻塞、等待的狀態，以至於看似熱火朝天的研發工作，很可能只是虛假繁忙。大家只是因為交付流被迫中斷，所以切換到其他工作，從而並行開展了很多不同的工作而已，從業務和客戶的視角來看，需求交付效率其實很低。
流時間、流速率、流分佈、流負載、流效率這五個指標結合在一起，就是一個典型的分析產品 / 團隊交付效率的模型，透過這個模型可以講述一個關於研發價值流完整的故事，回答一個關於交付效率的本質問題。
截止到目前，我已經介紹了研發效能度量的一些比較關鍵的指標，這些指標通常已經能夠用來評估產研團隊的整體交付效率、交付質量和交付能力了。但是，我們不滿足於可以評估效能，還要從宏觀到微觀一層層地下鑽下去，找到那些影響效能的阻礙因素，這樣才能針對性採取改進措施，讓組織獲得效能提升。因此，我整理了一張研發效能度量指標的“全景圖”，希望對你有所幫助。
在圖中，我以一種矩陣的形式來組織研發效能度量指標。縱軸是軟體研發生命週期的各個階段，橫軸是研發效能度量的三大維度，矩陣中羅列了相關指標及其適用範圍。圖中實心的方框是偏結果性的指標，其他是偏過程性的指標。在落地過程中，我們的指標全集持續累積，實際上要多於圖中展示的這些內容，這裡只是給出一個示例，你可以結合所在組織的上下文進行進一步的增減和調整。
除了以上指標，還有很多實踐中常用的指標，這裡選取一部分介紹下：
需求規模。
用於描述需求的顆粒度，計算公式為：統計週期內交付的需求總研發工作量 / 需求個數。這個指標反映了產研團隊需求拆分情況。對於單一團隊來講，需求規模保持相對穩定，需求吞吐量指標才具備參考意義。
需求變更率。
統計週期內，發生變更的需求數與需求總數的佔比。這個指標透過度量開發、測試過程中變更的需求數來達到衡量需求質量的目的。注意，這裡的需求變更統計的是需求達到了就緒狀態之後才發生的變更，主要用於反饋開發活動中實際發生的摩擦，這與敏捷擁抱變化的原則並不衝突。
需求按時交付率。
統計週期內交付的需求中，滿足業務方期望上線日期的需求個數佔比。這個指標反映了在使用者的視角下，產研團隊是否在全力為滿足業務方的上線需求而努力。
技術債率。
技術債率是倉庫維度的統計資料。計算公式為：預計技術債務修復時長佔開發所有程式碼所需時間的比例。這個指標是有效衡量程式碼質量的一種方法，反映了因快速開發暫時不顧程式碼質量所產生的技術債比率，而技術債會不斷降低開發效率。技術債本身無法在不同倉庫之間比較，因為各個倉庫大小各不相同，但技術債率就可以進行橫向比較，因為比率是相對的。根據技術債率可以進行倉庫的評級，對於直觀體現倉庫狀況非常有幫助。關於這個指標更詳細的資訊可以參考：SQALE （Software Quality Assessment Based on Lifecycle Expectations） 相關方法。
單元測試覆蓋率。
透過統計單元測試中對功能程式碼的行、分支、類等場景覆蓋的比率，來量化說明測試的充分情況。
平均缺陷解決時長。
用於描述研發修復線下缺陷的平均時長，計算公式為：統計週期內缺陷的總解決時間 / 缺陷數量。這個指標體現了研發解決線下缺陷的效率。
程式碼評審覆蓋率。
在主分支上，程式碼評審覆蓋的提交數 / 總提交數。這個指標體現了研發質量內建活動中程式碼評審的總體執行情況，即有多少比例的提交被程式碼評審所覆蓋。
專案收益達成率。
收益指標全部完成的專案數 / 收益指標驗證時間在所選週期內的專案數。這個指標衡量了專案的各項預期收益指標的達成情況。
專案滿意度評價。
以專案為維度，對該專案的整體過程進行評價，評價分為兩層：第一層為總體滿意度評價，用於對團隊的整體交付情況進行評價；第二層為具體分類評價，用雷達圖進行呈現，分類評價可用於收集改進意見，發現短板從而進行改進；分類評價包括但不限於以下幾方面：需求管理、進度管理、成本管理、溝通管理、風險與問題管理、驗收測試、上線質量、上線後支援、開放性問題等。
實踐者的常見困惑
在指導團隊進行指標設計的過程中，經常會遇到一些實踐者的疑問，這也代表了一些對指標選取的常見困惑，主要有以下幾點：
需求吞吐量是按需求個數算還是按故事點計算？
針對這個問題，我建議還是應該按照需求個數來計算。敏捷中我們經常使用故事點來評估工作量的大小，大家已經使用的很成熟了。但故事點實際上是一種敏捷規劃的工具，不建議作為需求吞吐量中關於需求規模的度量指標來使用。因為不同團隊對於同樣顆粒度大小的需求，所估算的故事點是不同的，所以不具備普適性和橫向的可比性。
另外，如果使用故事點來作為需求規模的度量指標，
還會導致讓研發人員產生規模衝動
，想辦法來增加估算的點數。這種行為又會導致業務人員 / 產品經理與研發之間產生不信任，對故事點數進行討價還價和合同談判的行為，從而導致了更多的問題。所以，一種比較建議的方式是，由產品經理和研發人員一起將需求拆分成顆粒度相對均勻的需求條目，然後用需求個數來表示需求規模，計算需求吞吐量。
需求吞吐量計算時，需求大小不一怎麼辦？
這個問題其實緊接著上一個問題，如果使用需求個數來標識需求規模，計算需求吞吐量，那需求大小不一怎麼辦？這裡的答案依然是需求的合理拆分，比如有的企業使用“業務需求 - 產品需求 - 技術任務”的三級需求層次模型來進行需求的分解，每一層的工作項條目都可以定義顆粒度範圍，形成大小相對均勻的條目。比如業務需求最好能在一次釋出中完成，產品需求最好在一個迭代內完成（如最多不超過 10 人天工作量），技術任務最好讓研發能快速完成（如不超過 3 人天工作量）。
把需求拆分為不同層次、相對均勻的工作項條目，一方面解決了度量準確性的問題（每個不同的層次可以分別統計），另外還有一個附加的好處是，這個指標會促使研發人員更有動力去更細地拆分需求，但
這個副作用是對整個組織有利的，因為更小的需求可以更快地交付業務價值
，這也是敏捷和精益思想中所提倡的。
當然，最終拆分出來的需求大小也不可能完全一樣，但是根據大數定理，只要樣本足夠多就能遮蔽個體的差異性而體現出整體的規律性。再者說，我們也不會只使用需求吞吐量這個單一指標去度量研發效能，而是結合交付週期類等一系列指標進行綜合評估，所以也不必對這個指標的計算過於糾結。
為什麼度量變更前置時間，有什麼意義？
前文中我們也提到，變更前置時間度量的是程式碼提交到功能上線的時長。這個指標的意義在於它反映了團隊的工程技術能力。軟體研發不同於生產製造行業，後者在設計和生產計劃制定後，基本上都是大規模、重複性、機械性的生產過程。而軟體研發過程實際上可以分為兩類活動：（1）創造性活動，比如基於業務需求進行創造性的設計和編碼；（2）重複性活動，比如程式碼提交後進行重複性的構建、測試和部署。而第二個部分就是工程實踐擅長的領域。
軟體研發同時受益於敏捷和精益方法。軟體的二進位制檔案是敏捷方法建立的，而通往生產環境的路徑是精益的，因為構建、測試、部署流程應該每天多次重複執行，並且具有高度的自動化。軟體就是一種在精益流水線上，敏捷建立的盒子。
我們可以問自己一個問題，如果你只修改了一行程式碼，那麼從程式碼提交到上線需要多少時間？是幾分鐘，一個小時還是數天的時間？如果我們還在採用大量手工部署、手工測試、手工配置、複雜的審批流程，即使一行程式碼的變更也需要很久才能上線。所以回到問題本身，我們為什麼要度量變更前置時間？因為我們希望通往生產環境的路徑是精益的，這條路是被工程實踐最佳化過的。所以，這個指標可以很好反應出團隊的工程技術能力，讓我們持續追求工程卓越（Engineering Excellence）。
為什麼度量平均故障恢復時間，而不是平均無故障時間？
在度量系統可靠性方面，有三個常見指標，分別是：MTTR、MTTF 和 MTBF。MTTF （Mean Time To Failure，平均無故障時間），指系統無故障執行的平均時間，度量的是從系統開始正常執行到發生故障之間的時間段的平均值。MTTR （Mean Time To Repair，平均故障修復時間），指系統從發生故障到修復完成之間的時間段的平均值，度量的是系統出現問題後恢復的速度。MTBF （Mean Time Between Failure，平均失效間隔），指系統兩次故障發生時間之間的時間段的平均值。MTBF= MTTF+ MTTR。
在這三個指標中，為什麼我們選用的是平均故障恢復時間（即 MTTR）呢？因為我們知道，在快速變更的複雜系統中，出錯和故障是在所難免的。軟體研發和運維的複雜性已經不僅限於系統架構的複雜性，還有像大型成熟企業普遍存在的歷史包袱，新舊系統之間大量的資訊通訊，複雜業務連線的多個不同系統，海量資料的計算與管理，跨團隊協同等都可能是未知故障的觸發點。所以核心的問題不是系統多長時間才出現故障，而是出現問題後如何快速恢復服務。
所以，在接受了系統的複雜性與不確定性的前提下，業界一般優先選用平均故障恢復時間作為系統可靠性的核心度量指標。包括近年來流行的混沌工程，也是在追求如何實現複雜系統的韌性，這與我們度量指標的選擇也是非常契合的。
小 結
以上我們介紹了度量指標體系的設計思路，也展開對一些指標進行了詳細說明。但是，這些度量指標並不是孤立存在的，它們之前存在很多相關性關係。如何綜合選取適當的指標，並運用一系列統計分析方法進行效能的分析，才是用好這些指標的關鍵。我們將在下一節中詳細講解效能度量分析方法相關的內容。敬請期待！
作者介紹：
張樂，DevOps 與研發效能資深實踐者，長期工作於擁有數萬研發的網際網路大廠（百度、京東等），主攻敏捷與 DevOps 實踐、DevOps 平臺建設、研發效能度量體系設計等方向，歷任資深敏捷教練、DevOps 平臺產品總監、研發效能度量標準化聯盟負責人等崗位。長期活躍於技術社群，目前是 DevOps 起源國際組織 DevOpsDays 中國區核心組織者，同時也是國內多個技術峰會的聯席主席、DevOps/ 研發效能專題出品人、特邀演講嘉賓。EXIN DevOps 全系列國際認證授權講師、鳳凰專案 DevOps 沙盤國際授權教練。歷任埃森哲、惠普等全球五百強企業資深諮詢顧問、技術專家，多年敏捷與 DevOps 轉型、工程效率提升和大型專案實踐經驗。暢銷書《獨角獸專案：數字化時代的開發傳奇》譯者。
