作者 | 姚安峰

長久以來，如何有效衡量軟件研發效能是所有研發管理者心心念念的事，但也一直是個未解的難題。從早期的人均代碼行到人均功能點公式計算，再到基于故事點的迭代速率或人均吞吐量，業界一直在探索。

有失偏頗的指標

人均代碼行，若作為關鍵指標，與更優秀程序員應該用更優雅和少的代碼這一邏輯相悖，且將軟件編程這一腦力勞動等同于砌磚速度，顯然是不合理的。

功能點計算，通過基于需求分析和設計后確定要修改的頁面數、接口數等多種因素構成的復雜公式計算，看似客觀，然而忽視了軟件研發工作的多樣性。渠道側應用的界面更多，功能點數容易更大，但還有偏后端開發、基礎平臺開發、數據和報表開發、算法開發等多種類型的工作，前端開發也存在采用不同框架帶來的差異性，不可能用幾個公式客觀衡量團隊的產能；另外，越來越復雜的計算公式要依賴準確的設計，且很難讓每個人都理解，需要人投入專門的時間來計算，這種沒有價值創造的工作本來就是一種浪費。

隨著敏捷開發的發展，故事點作為一種基于團隊集體評估復雜度的工具可用于衡量細粒度需求的大小。一些管理者于是考慮用人均故事點來衡量產能。然而故事點沒有單位、不同團隊故事點基準可以不同，以及評估的主觀性特點，讓人均故事點、迭代速率很難作為令人滿意的效能衡量關鍵指標。

關鍵的研發效能指標集

經過多年的探索總結，DevOps社區提出了衡量IT績效的四個關鍵指標?，包括前置時間（或交付周期）、部署頻率、部署失敗率和線上失敗恢復時長，簡稱“4 Key Metrics”。這是一個很好的方向。不過在實踐中，我們發現實際要關心的關鍵指標其實不止這四個，例如生產缺陷率就是必不可少的關鍵結果，需求吞吐量也常常很受關注。下面是實踐中常見的研發過程度量指標，其中部分是反映最終結果的關鍵效能指標。

評價效能的關鍵原則

要觀察和評價研發效能，就首先要定義什么是效能？簡單一句話，效能就是團隊能持續快速交付價值的能力。目的是交付價值，其研發核心能力在于“響應力”與“穩健性”，同時，響應力這一概念又可以從“流動速率”和“資源速率”兩個維度來觀察。前者是指價值從明確到交付用戶的周期時間，而后者是單位人力資源在單位時間里交付價值的數量，對創新與敏捷的要求使得前者的重要性更勝于后者。

因此，要評價效能，這里就有幾個關鍵原則：

• 任何單一指標并不能合理地觀察和評價一個團隊的效能，否則會產生副作用。例如單一看吞吐量，會驅使團隊一味拆需求，或犧牲質量；若單一看交付周期時間，可能驅使團隊減少需求流入。
• 評價效能盡可能看全局結果，而非階段性表現，例如一次轉測通過率這樣的指標通常很重要，反映開發階段內建質量的效果，然而用于評價效能不合適，它反映的不是團隊整體表現。
• 效能評價原始數據應該是來自工具的客觀記錄，不需要人工計算，不需要為評價浪費時間，且對所有團隊是一視同仁的。
• 考慮到軟件研發工作種類的多樣性和以腦力勞動為主的工作性質，研發效能的觀察更多應關注團隊的改進趨勢，而非橫向對比的絕對數值。

那怎么才能更合理有效地達成觀察和評價效能的目的呢？最直接的辦法，也是最理想的，就是學會觀察分析一組核心指標，例如同時拿出4 Metrics的數據趨勢，或者上面圖中的關鍵效能指標數據趨勢進行分析和觀察。一些成熟的企業會將這些關鍵指標做成Dashboard（儀表盤），便于觀察者一目了然分析全局狀況。這就像做數字化運營的數據分析一樣，只有通過一組數據的對比分析才能得到相對有效的洞察。強烈建議每一位效能管理者、過程改進者以驅動改進為目標，學會和習慣以這種方式來評價一個團隊的效能情況。

觀察效能的綜合評價指標

但這一理想方式對觀察者要求較高，需要充分理解每一個指標的含義和內在邏輯，并且這樣一組核心指標對于反映宏觀的效能改進趨勢還是不夠直觀，認知負載有點高。尤其對于一些管理層和外部人員，看不出整體效能到底是變好還是變差了。想要解決這個問題，我想到了一些類似的解決方案。

國家需要一些指標來持續觀察一個經濟體的整體經濟狀況，典型的像居民消費價格指數（CPI）、購買力平價指數（PPP），都是采用一籃子指標基于某種內在邏輯構成的復合指標。好處是：

• 雖然不能說明問題根因在哪里，但能更直觀反映全局表現
• 其變化可綜合多種因素的影響，可體現不同因素對整體評價的影響程度
• 降低了為使得單一指標好看而采取片面行為的可能性

于是，在實踐案例中，我們設計了下面這樣的概念公式，綜合了六個要素來產生一個綜合評價指數（研發效能CEI），可以以周或月進行統計：

綜合效能 = （交付吞吐量 部署頻率 發布成功率） / （需求交付周期 線上穩定性 債務積壓）

交付吞吐量

反映資源速率，通常是指單位時間交付需求的個數，但這是六個要素中最難以有效計算的，因為與需求顆粒度有關。功能點、故事點都需要人為評估，且存在以上一些問題。于是采用一個自然產生的近似值：故事開發時長，即從開始開發到開發完成的時間，依靠看板中的故事拖動產生。盡管這一時長可能受個體開發效率影響，但在統計學意義上可以近似代表需求大小。開發時長還受到同時并行工作的故事數的影響，同樣大小，并行越多，時長越長。因此交付吞吐量的人均值計算如下：

交付吞吐量 = 交付故事個數 x （平均故事開發時長 / 平均的人均故事開發WIP）/ 團隊Size

部署頻率

這個指標就是人均的發布單元部署次數，理論上團隊規模越大能夠交付越多的需求，應該更頻繁地交付特性。為了提高頻率，這個指標會驅使團隊拆分部署單元。考慮到部署頻率相對吞吐量和周期時間對整體效能評價的重要性相對較低，因此其影響通過冪函數降級。

部署頻率 = （部署單元部署次數 / 團隊Size）^（1/e）

發布成功率

這一指標較簡單，即每次上線發布的成功率，只要發生回滾或新版本產生重要故障即視為不成功。由于這一指標是百分率，比率越高提升困難越大，因此采用以下指數函數參與計算：

發布成功率 = e ^ 版本發布成功率

需求交付周期

這是反映流動速率的關鍵指標，即從需求確認到需求上線的周期時長，衡量團隊對價值的響應速度。這里對需求的統計尺度不采用故事，而是采用可獨立上線的特性或用戶需求。

需求交付周期 = 平均特性交付周期

線上穩定性

對線上穩定性的衡量可以綜合幾個不同角度的基礎指標，人均生產缺陷、停機時長和線上失敗恢復時長。考慮到人均生產缺陷、停機時長和線上失敗恢復時長數值可能為0，且數字越小越難提升，以及這幾個指標數值的波動性很大，因此通過以下冪函數降級。

線上穩定性 = （（（生產缺陷個數+1）/ 團隊Size （停機時長+1）（線上失敗平均恢復時長+1））^ （1/e）

債務積壓

最后一個因素我認為需要加進來。這里所謂的“債務”是指各類團隊應當及時解決然而未解決的問題，包括需求積壓、缺陷積壓、技術債務。團隊在快速交付過程中可能欠下很多債務。如果忽略了技術債務、缺陷積壓，一段時間里的高速率其實只是掩蓋了問題。而對于需求積壓，即便團隊自己認為效能很高，然而站在業務方角度，其效能仍無法滿足需要，其感知到的效率不高。缺陷積壓即未解決的缺陷；需求積壓是業務提出但超過一定時限仍未進入交付的需求；技術債務目前容易量化的是代碼債務，例如Sonar掃描的結果，如果可能也可以包括架構債務的數量。當然，考慮到這幾類積壓的重要性差異，賦予一定權重。人均的積壓計算如下：

債務積壓 = （需求積壓 x 50% + 缺陷積壓 x 30% + 技術債務量 / 10 x 20%）/ 團隊Size

最后，綜合考慮到分子和分母計算中均有兩次團隊Size參與計算，可考慮簡化將其相互抵消，形成如下最終計算公式：

下面是實踐中基于實際度量數據形成的綜合評價指數曲線和源數據示例。我們能夠直觀的看到綜合多種因素后團隊整體效能的變化。在圖中額外自動生成了一條紅色趨勢線（虛線），能夠體現一段時間周期內，效能的總體變化趨勢是變好還是變差以及變化幅度大小。由于團隊工作的多樣性，可能不同類型的團隊計算出的指數結果數值差異較大，因此該曲線主要用于團隊與自己過往相比，或者在工作性質類似的研發團隊之間做橫向比較。

綜合指標應用場景和意義

通過統計和觀察該綜合指標，可以有效解決前面單一指標、人工統計的問題，且能反映出不同維度指標因素對綜合效能的影響程度。那么該指標趨勢對誰有用呢？實踐中有以下幾種應用場景：

• 對于高層管理者或不熟悉效能數據分析的人，可以向其直觀展現團隊和組織的效能變化，作為溝通研發效能的基礎；
• 對于部門和團隊負責人、教練，能夠快速了解團隊的效能總體變化；當曲線發生顯著波動時，再深入展開分析是哪幾個因素導致了整體結果波動，從而采取改進措施；
• 當部門或團隊設定效能提升的目標時，如OKR，可以用綜合指數作為衡量目標達成的關鍵結果，避免團隊片面地關注單一指標提升，而是關注綜合結果，在重點提升個別指標的同時，也要確保其它關鍵指標不下滑。

該指標公式也還有很多改進空間，例如不同的企業、部門對效能的解讀不同，或者對不同關鍵指標的重視程度不同，可以適當調整公式中的影響程度因子或權重。或者，在對發布成功率、生產缺陷等因素如何作用于最終結果的算法上，可能有更科學準確的公式，也可以改進它，歡迎提出建議。

原文鏈接：??觀察和評價研發效能的趨勢 (qq.com)??