企業如何度量研發效能？

 研發效能度量是當下軟件研發領域最火熱話題之一，互聯網企業和傳統軟件企業都在關注研發效能度量領域。
尤其在數字產業化和產業數字化的大背景下，研發效能更被視為一家科技公司的核心競爭力，也被部分管理者奉為圭臬。

然而研發效能度量雖好，但要在團隊中真正實施落地起來，卻不是那么容易。

總結起來有以下幾個原因：

• 偏離了效能度量的正確方向
• 缺乏系統性的思考與設計
• 缺乏優秀高效的效能度量產品

那么到底什么是研發效能度量？如何避免落入效能度量的誤區？如何進行系統化的設計效能度量指標體系？以及如何在團隊中有效的實施落地研發效能度量？優秀的效能度量產品應該具備哪些要素？
這些問題都是本文將要探討的話題。

 

01 什么是效能度量

研發效能並沒有一個官方的標准定義，從字面意思來理解，所謂的研發效能就是軟件研發的效率和能力。

提到研發效能，很多人第一時間想到的是快速的完成開發工作，原本需要一周完成的需求，提高了研發效能之后，能在一天內完成。而這個場景只能算是研發效能的一個指標，並不全面。

個人看來研發效能可以概括為：高效率、高質量的持續交付有效業務價值的能力。

這句話里有幾個關鍵點需要特別強調一下：

• 高效率：交付的效率要高，交付周期要盡可能的短
• 高質量：交付的質量要高，如果交付的質量太差，系統隨時面臨崩潰，不是我們所追求的效能。
• 持續交付：交付的過程必須是可持續的，而不是只高效高質量交付一次。
• 有效業務價值：交付的內容必須關注業務價值，關注業務是否成功。

這幾個關鍵點缺一不可，缺少哪個都夠不成完整的研發效能的定義，了解清楚什么是研發效能之后，我們來看看研發效能是否可以進行度量。

關於研發效能度量，業界有兩種截然相反的觀點：

一種觀點以現代管理學之父 Peter Drucker 的理論為依據，主張研發效能是可以度量的；

另一種觀點以世界級軟件開發大師 Martin Fowler 為代表，主張研發效能是不可度量的。

我的看法是研發效能可以度量，但落地實施起來並不那么容易，要避免落入研發效能度量的誤區。

 

02 效能度量的誤區

然而研發效能度量雖然可度量，在團隊中真正實施落地起來，卻不是那么容易。

大部分團隊在推行研發效能度量的過程中，落入了效能度量的誤區。總結起來在研發效能度量的過程中，常見的誤區有以下幾個：

誤區1：

效能度量的目的是為了績效考核。把研發效能度量與績效考核關聯起來，是國內團隊常見的做法，也是效能度量最大的誤區。

效能度量是一種達成目標的手段，而非績效考核的手段，它在於幫助團隊找出團隊活動中的瓶頸，分析瓶頸產生的原因，從而改進並不斷反饋，以保證更快更高質量的交付業務價值。

如果把效能度量等於績效考核，注定會變成數字游戲，效能度量也一定會失敗。

誤區2：

效能度量等同於數據報表。效能度量並不等同於數據報表，數據報表更多的是通過數據加工清洗，以可視化的方式呈現出來，從數據中得出有用的信息，所以數據報表只是研發效能度量活動中的一個工具，一個手段。

效能度量除了需要可視化的數據報表之外，更重要的是識別出瓶頸，進行改進優化，並不斷的反饋改進。

誤區3：

關注局部效率，而忽視了全局。在研發效能度量中過度關注局部效率，並不會帶來全局效率的提升。

整個研發活動是一個非常長的鏈條，我們要把着眼點放在那些真正出現瓶頸的地方。如下圖中藍色線條代表實際的研發時長，紅色線條代表是阻塞時長。

所謂關注局部效率，就是縮短藍色部分的時長，而對整個周期來看紅色部分的影響遠大於藍色部分的影響，所以提升研發效能最有效的是縮短紅色部分的時長。

 

誤區4：

 

關注效能度量本身，而忽視了業務價值。研發效能的提升，最終是要為業務價值服務的，關注研發效能的改進過程成功與否，是要看最終為業務成功帶來了多大的提升，而不是只關注研發效能自身的數據。

如在研發管理活動中引入一套新的研發管理工具，從效能度量角度看，引入該系統后從開發到測試交付的周期是不是縮短，發布的質量和頻率是不是提升；從業務價值角度看，引入該系統后是否為業務價值帶來了真正的成功。

誤區5：

忽略效能度量的長周期性。效能度量是具有周期性的，而且周期也帶有一定的不可預測性，不是每引入一項研發效能度量改進計划，都會產生正向的收益。
很多時候需要不斷的嘗試，識別問題，並制定詳細的改進計划，經過一段周期后才會看到效能真正的提升。

所以在研發效能度量過程中，不可操之過急，不可以忽略它的的長周期性，只要設定的度量目標正確，通過不斷的改進與反饋，最終會達到想要的目標。

誤區6：

效能度量的指標設計過於單一。效能度量的指標體系需要具有科學且系統性的思維以及全局思考，切不可以偏概全，如果設計的度量指標體系過於單一、片面，會把研發效能度量引到錯誤的方向上去。

以需求交付周期為例，如果在研發活動中以需求交付周期作為一個指標，就需要同時設計關於需求交付質量的指標，因為需求的交付不僅僅只是快，有效高質量的需求交付才有價值。

誤區7：
效能度量必須是精確的。這可能是大家經常會陷入的一個誤區，認為效能度量的數據必須精確才有意義，其實在效能度量中我們經常采用的是統計度量，而非精確度量。
所謂統計度量是以統計樣本為基礎，在觀察樣本的基礎上得出近似精准但科學的推斷，統計度量常用趨勢、分布、均值等手段。

 

03

效能度量指標體系

整個研發管理鏈條，本質上是兩條工作流。

一條管理側以需求特性的全生命周期為核心的需求價值流，涵蓋需求收集、規划、開發、測試、發布到上線環節；

一條工程側以代碼提交為線索的研發工作流，涵蓋啟動開發、開發中、開發完成、持續集成、持續部署到線上發布環節：

 

這就要求我們在效能度量的指標體系設計中，充分考慮這兩條流之間信息的流轉與狀態的同步，從而設計出一套覆蓋端到端交付的效能度量體系。

根據效能度量的目標，我們要實現高效率、高質量的持續交付有效業務價值的能力，可以把效能度量指標分為如下三個體系：交付效率、交付質量和交付能力。

 

 交付效率

目標是促進端到端及早的交付，用最短的時間順暢的交付用戶價值，包括：

• 平均需求交付周期：需求從提出到最終發布上線的時間周期；

• 需求吞吐量：統計單位時間內交付需求的個數；

• 平均開發交付周期：需求從開發到提交測試的時間周期；

• 平均測試交付周期：需求從開始測試到測試完成的時間周期。

交付質量

目標是促進端到端高質量交付，避免不必要的錯誤故障和返工，包括：

• 構建成功率：構建成功的次數在全部構建次數中的比例；

• 嚴重缺陷占比：線上嚴重缺陷在所有缺陷中的比例；

• 測試覆蓋率：判斷測試用例的執行情況以及測試執行是否充分；

• 測試通過率：判斷測試用例的執行結果，衡量軟件的質量。

交付能力

目標是建設卓越的工程能力，實現持續交付，包括：

• 代碼提交頻率：單位周期內提交代碼的頻率；

• 每日構建次數：每日能夠完成的構建次數；

• 持續集成時長：單位周期內持續集成所花的時間周期；

• 部署時長：單位周期內部署版本所花的時間周期。

完整的效能度量指標體系，可以用下圖來表示，通過這些指標體系，可以從不同層面找到影響效能的因素，進而制定詳細的效能改進計划，達到提升研發效能的目的。

 

 

04 

效能度量分析方法

在探討效能度量的誤區時，我們提到了效能度量中經常采用的是統計度量，而非精確度量。統計度量是以統計樣本為基礎，在觀察樣本的基礎上得出近似精准但科學的推斷。

那么采用哪些度量分析手段，才能使得效能度量更有意義和價值呢？

我們經常采用的效能度量分析方法有如下幾種：

趨勢分析

相比較於絕對值趨勢分析更有價值，在研發效能度量過程中，因為業務不同，團隊成員的配比不同、成員的能力有個體差異等因素的影響，關注絕對值意義不大，更應該關注某個對象隨着時間的推移而形成的趨勢變化。

 

均值分析

使用均值分析可以確定每個組的均值是否與總體均值存在差異，分析的數據可以服從正態分布、二項分布或泊松分布。如分析每個小組嚴重缺陷占比或者缺陷重開率，與團隊整體嚴重缺陷占比或缺陷重開率的均值之間的對比。

下鑽分析

下鑽分析指沿着特定屬性維度的層次下降，獲取更詳細的數據。通常用於對某數據的不斷細分，以分析在各種細分情況下的數據關系，找出影響該數據的根本原因。在實際度量過程中，我們可以采用按階段下鑽、按部門下鑽、按聚合維度下鑽等。

累計流圖

累計流圖（CFD: Cumulative Flow Diagram)經常被用在看板方法度量中，可以很好地反映工作項在每個流程環節的流動問題。累計流圖的使用場景遠不止看板方法，在研發效能度量中累計流圖可用於分析在制品、分析平均前置時間、需求吞吐量、需求范圍變化、預測需求交付時間等。

累計流圖本質上就是團隊交付過程的回放，引導團隊回顧發生了什么，從而改進價值流動過程。

這里只是列出了幾種常見的度量分析方法，其他的還有相關分析、交叉分析、聚類分析、矩陣分析、負載分析等各種度量分析方法，感興趣的可以自行檢索。

 

05

效能度量產品設計

研發效能度量的過程實際上是把研發活動中產生的過程數據，進行加工與清洗，並且轉化為可視化的信息，幫助團隊進行效能分析與洞察。

其中，把數據轉化為信息是這個過程中最有價值的環節，信息對用戶是有意義的，而不是單純的數據，這就是為什么我們叫IT（Information Technology），而不是DT（Data Technology）。

 

在實際業務中，知道了效能度量的誤區，也了解了如何設計好度量指標體系，以及運用合適的效能度量分析方法，僅有這些還不夠。

要在團隊中更好的落地研發效能度量，還需要一款優秀有效的研發效能度量產品，工欲善其事，必先利其器。

選擇一款優秀的研發效能度量產品可以讓你的團隊在落地效能度量時起到事半功倍的效果。

在我看來一款優秀的研發效能度量產品應該具備如下幾個要素：

• 自動化的收集數據，而不是依賴於團隊成員的手工輸入；

• 能夠根據團隊度量的需要，進行自定義和個性化的配置；

• 能夠根據團隊成員角色的不同，對效能報表的訪問設定不同的可見性；

• 效能報表支持篩選，從而篩選出對效能度量有價值的數據；

• 度量產品的成本要低，如果需要花巨大成本去建設一套效能度量平台，產生的收益並不會達到預期。

這里就以我們 PingCode 推出的研發效能度量產品 Insight為例。

如果你的團隊在研發管理過程中使用 PingCode 產品矩陣中的其他子產品進行管理。

如使用 Project 進行項目管理，使用 Testhub 進行測試管理，這些子產品中產生的過程數據將會通過自動化的收集至 Insight 中，並進行加工清洗，最終以可視化的效能儀表盤形式展現出來。

同時 PingCode 還將提供 Marketplace 和 REST API，幫助研發團隊把其他工具的數據收集到 PingCode。這些數據和 PingCode 自身產品中產生的數據加以匯總融合，從而提供更多維度的效能度量。

PingCode Insight 產品設計原理如下圖所示：

 

06

PingCode Insight

PingCode Insight 中的效能度量報表都以效能儀表盤的形式展示，每個團隊可以定義多個不同的儀表盤，在每個效能儀表盤上支持添加不同的指標分析。

也可以針對每個效能儀表盤設定不同的可見性權限，以滿足團隊不同角色所關注的效能度量指標。

 

 

 

PingCode Insight 中根據以上效能度量指標體系，默認設計了大量的效能報表，減少用戶定義報表的復雜配置。這些報表都可以直接添加到效能儀表盤中進行使用，后續還會根據實際業務場景需要，不斷增加更多更有價值的效能報表：

 

在每一個具體的度量報表中，團隊可以根據自己實際的業務場景，進行個性化的配置。

如定義效能報表展示的樣式，對關注的指標進行進行設置，定義不同的對比維度，同時還可以在視圖界面對要展示的數據定義篩選條件，以便過濾出對效能度量有價值的數據：

 

 

07

總結

研發效能度量本身是一個非常復雜的過程。

在這個過程中，一方面要避免陷入效能度量的誤區；另一方面要有系統性思維和全局思考能力，設計完善的效能度量指標體系，運用科學的效能度量的分析方法，同時選擇高效的研發效能度量產品，以達到事半功倍的效果。

在效能度量的過程中，只要最終達到的收益大於效能度量所付出的成本，這個付出就是值得的。

 

Pingcode官網

Worktile官網