文章來自：ThoughtWorks，世界經(jīng)理人經(jīng)授權(quán)轉(zhuǎn)載。

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

有失偏頗的指標

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

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

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

關(guān)鍵的研發(fā)效能指標集

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

評價效能的關(guān)鍵原則

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

因此，要評價效能，這里就有幾個關(guān)鍵原則：

1.任何單一指標并不能合理地觀察和評價一個團隊的效能，否則會產(chǎn)生副作用。例如單一看吞吐量，會驅(qū)使團隊一味拆需求，或犧牲質(zhì)量；若單一看交付周期時間，可能驅(qū)使團隊減少需求流入。

2.評價效能盡可能看全局結(jié)果，而非階段性表現(xiàn)，例如一次轉(zhuǎn)測通過率這樣的指標通常很重要，反映開發(fā)階段內(nèi)建質(zhì)量的效果，然而用于評價效能不合適，它反映的不是團隊整體表現(xiàn)。

3.效能評價原始數(shù)據(jù)應(yīng)該是來自工具的客觀記錄，不需要人工計算，不需要為評價浪費時間，且對所有團隊是一視同仁的。

4.考慮到軟件研發(fā)工作種類的多樣性和以腦力勞動為主的工作性質(zhì)，研發(fā)效能的觀察更多應(yīng)關(guān)注團隊的改進趨勢，而非橫向?qū)Ρ鹊慕^對數(shù)值。

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

觀察效能的綜合評價指標

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

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

1.雖然不能說明問題根因在哪里，但能更直觀反映全局表現(xiàn)

2.其變化可綜合多種因素的影響，可體現(xiàn)不同因素對整體評價的影響程度

3.降低了為使得單一指標好看而采取片面行為的可能性

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

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

交付吞吐量

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

交付吞吐量 = 交付故事個數(shù) * （平均故事開發(fā)時長 / 平均的人均故事開發(fā)WIP）/ 團隊Size

部署頻率

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

發(fā)布成功率

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

發(fā)布成功率 = e ^ 版本發(fā)布成功率

需求交付周期

這是反映流動速率的關(guān)鍵指標，即從需求確認到需求上線的周期時長，衡量團隊對價值的響應(yīng)速度。這里對需求的統(tǒng)計尺度不采用故事，而是采用可獨立上線的特性或用戶需求。需求交付周期 = 平均特性交付周期

線上穩(wěn)定性

對線上穩(wěn)定性的衡量可以綜合幾個不同角度的基礎(chǔ)指標，人均生產(chǎn)缺陷、停機時長和線上失敗恢復(fù)時長。考慮到人均生產(chǎn)缺陷、停機時長和線上失敗恢復(fù)時長數(shù)值可能為0，且數(shù)字越小越難提升，以及這幾個指標數(shù)值的波動性很大，因此通過以下冪函數(shù)降級。線上穩(wěn)定性 = （（（生產(chǎn)缺陷個數(shù)+1）/ 團隊Size （停機時長+1）（線上失敗平均恢復(fù)時長+1））^ （1/e）

債務(wù)積壓

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

債務(wù)積壓 = （需求積壓 50% + 缺陷積壓 30% + 技術(shù)債務(wù)量 / 10 * 20%）/ 團隊Size

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

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

綜合指標應(yīng)用場景和意義

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

1.對于高層管理者或不熟悉效能數(shù)據(jù)分析的人，可以向其直觀展現(xiàn)團隊和組織的效能變化，作為溝通研發(fā)效能的基礎(chǔ)；

2.對于部門和團隊負責人、教練，能夠快速了解團隊的效能總體變化；當曲線發(fā)生顯著波動時，再深入展開分析是哪幾個因素導(dǎo)致了整體結(jié)果波動，從而采取改進措施；

3.當部門或團隊設(shè)定效能提升的目標時，如OKR，可以用綜合指數(shù)作為衡量目標達成的關(guān)鍵結(jié)果，避免團隊片面地關(guān)注單一指標提升，而是關(guān)注綜合結(jié)果，在重點提升個別指標的同時，也要確保其它關(guān)鍵指標不下滑。

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