[轉] 研發組織該如何設計績效體系？

德魯克在《21世紀的管理挑戰》一書中指出：「管理的第一個任務是規定組織的成效和績效，而任何有這方面經驗的人均可以證實，這實質上是一項最艱鉅、最有爭議的任務，但同時也是最重要的工做」。

知識工做的不肯定性更高、組織成員相互協同更復雜，所以，爲知識工者設計績效更加困難。

人力資源同事絞盡腦汁，但研發管理者和研發團隊又以爲指標定義不合理，不斷討論、妥協的結果是，許多企業最後在使用一份有幾十個指標的度量體系，管理成本高但激勵效果又不明顯。

筆者根據多年企業一線諮詢經驗，給讀者建議了一個研發績效度量框架做爲參考。第一節將介紹這個框架的設計原則，便於讀者將來根據企業自身特色對這個度量框架進行定製和調整，第二節將介紹框架中涉及的三種指標類型，第三節將詳細介紹這個研發績效度量框架的具體指標和算法。

 

1、研發績效度量體系設計五原則

 

1.外部性

一樣在《21世紀的管理挑戰》這本書中，德魯克指出，任何組織的績效都只在外部反映出來。

以一個咖啡廳爲例，客戶等待時間、咖啡口感、價格，這些都是客戶可感知的外部指標。研發組織也應優先選取其客戶可感知的外部指標做爲研發組織績效指標，這裏客戶包括但不限於業務人員、產品經理、最終用戶等。

2.無害性

管理學有一個原則「你考覈什麼你就會獲得什麼」，績效指標對團隊行爲具備很大的牽引做用。

設定一個指標後，須要首先考慮負向牽引做用，既團隊會採起哪些短時間行爲來試圖迅速達成績效指標？評估一下這些短時間行爲對組織的傷害有多大？

舉個例子，若是用開發代碼行數來評估開發工做量，就會對開發工程師產生一個明顯的負向牽引做用，讓開發工程師失去進行優雅設計或重構代碼從而讓代碼更精簡的動力。

所以，績效度量體系應儘可能選取一些難於僞造或者僞造行爲對組織傷害比較小的績效指標。

 

3.總體性

軟件研發組織是一個複雜系統，各崗位間界限很難徹底明確。管理者要剋制將績效指標分解到不一樣崗位，甚至分解到我的的衝動。這種無效的指標分解每每會致使局部優化，即各崗位僅僅爲本身的績效而優化工做方法，反而下降了組織的績效。

例如，將進度和質量兩個互相牽制的指標，割裂開分配給開發測試，這形成開發只關心進度，忽視移交質量，而光靠測試來保證質量。這種方式是不可能得到高質量軟件的，也不可能達到快速交付的目的。

 

4.制衡性

研發組織無法用單一指標來衡量，而須要用一組指標來互相制約以求得平衡。例如，單純追求交付速度是危險的，必須用質量指標來平衡。

 

5.演進性

績效指標應該隨着組織的發展不斷調整，須要按期增減修訂指標，保持指標體系精簡，下降管理成本。

 

2、三種績效指標類型

瞭解了定義研發績效體系的五個原則後，還須要介紹一下績效指標的三種類型：

1.適應性指標

反應組織是否適合生存，這些指標因組織的特色不一樣而不一樣。

例如，對於一個pizza外賣商家而言，pizza送達時長、送達準時率和價格就是它的適應性指標，但pizza口感就不那麼重要。

可是，對於一家pizza精品餐廳而言，pizza口感就變得很是重要，而上菜等候時間就變得相對不那麼重要了。好消息是，由於研發比較同質化，研發組織適應性指標相對統一。

2.健康度指標

反映組織的健康程度，就如同一我的的心率、血壓，血脂指標同樣。健康度指標每每是內部指標，非客戶可見，所以須要很是當心衡量指標的無害性和總體性。

健康度指標也須要不斷調整，一旦一個指標常常保持正常，就能夠將它從績效指標體系中剔除。

舉個例子，代碼冗餘度（有多少代碼是重複的）就是一個有用的代碼健康度指標。

 

3.槓桿指標

反映組織的重點改進方向。不少時候，須要進行某項改進，經過槓桿指標來撬動適應性指標改進。

例如，今年要推行接口測試自動化，就能夠將接口測試代碼覆蓋率做爲一個槓桿指標，這一指標的提高有利於保證生產質量。

槓桿指標通常是內部指標，因此一樣要保證無害性和總體性。一旦改進活動告一段落，槓桿指標可能會變成健康度指標，也可能直接被剔除。

 

3、參考績效指標體系   

有了上面的理論鋪墊，能夠進入正題，介紹給讀者參考的研發績效度量指標體系。這個體系的指標分紅四組，下面將一一詳細介紹：

• 響應力，反映研發組織響應市場要求的能力，包括需求耗費時長，時長分佈圖K值兩個指標；

• 質量，反映研發組織交付質量，包括生產缺陷需求比，測試缺陷需求比兩個指標；

• 可用度，反映研發組織管理的系統或服務的穩定性，包括系統可用度或服務可用度指標；

• 效能，反映研發組織的交付效率，包括需求吞吐率，流動效率兩個指標。

1. 需求耗費時長

需求耗費時長反映研發組織交付需求的速度。爲了計算需求耗費時長指標，須要計算一段時間內全部需求的耗費時長，計算單一需求耗費時長的公式很是簡單：

 

例如，需求A提出時間爲12月5日，需求A上線時間是12月30日，那麼，需求A耗費時長就是25天，這裏，需求提出時間是指業務人員和研發人員開始澄清需求細節的時間。

 

在計算出一段時間內，全部單一需求耗費時長以後，能夠用如下公式計算需求耗費時長：

例如，有10個需求，單一需求耗費時間分別是23，42，45，45，45，47，50，62，70，123天，那麼取85%百分位數，就至關於取這個數列的第9個數（10*85%後四捨五入得出），最終需求耗費時間是70天，這意味着，85%的需求是在70天內交付的。

需求耗費時長是一個典型的適應性指標，符合外部性和總體性，研發組織的客戶都很是關心，它表明研發組織的快速響應能力。在實際使用中，若是研發組織內存在多個不一樣需求類型，（常規需求、緊急需求和缺陷）那麼就須要將這個指標分紅幾個不一樣的指標，如常規需求耗費時長，緊急需求耗費時長以及缺陷修復時長等。

需求耗費時長是反映組織敏捷度的重要指標，由於須要全部角色齊心合力才能優化這一指標，因此全部相關角色都應該對這個指標負責，包括業務人員，產品經理，架構師，開發工程師，測試工程師，運維工程師。開發測試及架構師對這個指標的貢獻比較容易理解，但產品經理和運維工程師對這個指標也有獨特的貢獻：產品經理須要保證需求儘可能明確，對開發工程師提出的疑問快速響應，對開發完的需求儘快驗收；而運維工程師須要在保持系統穩定的前提下，儘可能加快移交速度。

需求耗費時長的一個相似指標是需求完成度，例如2個月需求完成度，就是計算有百分之多少需求能夠在2個月內完成。我不推薦使用需求完成度這個指標，由於這個百分比指標會引導團隊追求100%需求完成度，這不符合軟件開發中不肯定管理的思路，也忽略了下面一節討論的需求耗費時間分佈分析。

 

2. 需求耗費時長分佈K值

需求耗費時長分佈K值反應需求耗費時長的分佈特徵。爲了計算需求耗費時長分佈K值，須要先繪製需求耗費時長分佈圖。分佈圖是一個柱狀圖，橫軸上X位置柱狀高度是需求耗費時長爲X天的需求的個數，例如，假設四個需求的耗費時間，分別是8天，8天，9天，11天，那麼畫出分佈圖就以下圖所示：

下圖是一個實際團隊的需求耗費時長分佈圖，符合韋伯分佈（Weibull Distribution），其一個重要特色就是有一個衆數尖峯和一個長尾。衆數表明大多數需求能夠在一個時長區間內交付，是研發系統交付常態；而長尾表明交付系統的意外狀況。在下圖中能夠看到因爲長尾的存在，致使需求耗費時長的均值大於中值，85%百分位數大於均值20%，而98%百分位數三倍於均值。

韋伯分佈是瑞典工程師韋伯在1930年研究軸承壽命時發現的，他採用了「鏈式」模型來解釋壽命問題。

這個模型假設一個結構是由n個小元件串聯而成，因而能夠形象地將結構當作是由n個環構成的一條鏈條，其壽命取決於最薄弱環的壽命。

軟件研發能夠當作一個由需求，設計，開發和測試等環節構成的鏈條，任何一個環節出問題，軟件則沒法按時交付，這是爲何需求耗費時長也符合韋伯分佈的根本緣由。

韋伯分佈有兩個參數，一個是λ，一個是k。λ決定了衆數峯值的高度，k決定了曲線的形狀。下圖給出了四種k值的韋伯分佈曲線：

需求耗費時長分佈圖的K值是一個健康度指標，用來判斷需求耗費時長分佈是否合理，是否符合可預測性要求。若是K值小於1，那麼這個研發交付系統是很是脆弱的，不具有可預測性，需求可能很快交付，也可能會很是慢。若是K值大於2，那麼需求交付總體上都很慢，但可預測性比較強；軟件開發組織的K值會在1.0到2.0之間。

3. 生產缺陷需求比

生產缺陷需求比反應了研發組織的交付質量。在給定時間內，生產缺陷需求比能夠這樣計算：

例如，整年生產缺陷200個，上線需求2000個，那麼生產缺陷需求比的數值爲每需求0.1個缺陷。在實際使用的過程當中，若是企業已經有一套生產缺陷分級機制，那麼可使用生產缺陷嚴重級別對生產缺陷數量進行加權計算。舉個例子，假設在200個缺陷裏有致命缺陷20個、嚴重缺陷50個、普通缺陷130個，致命缺陷權值爲3，嚴重缺陷權值爲1，普通缺陷權值爲0.5，那麼加權後的生產缺陷個數是（20*3+50*1+130*0.5），共175個，加權生產缺陷需求比就是每需求0.0875個缺陷。

使用這個指標的一個挑戰是如何肯定需求規模。這個首先要看企業是否是已經有一套可行的需求規模估算體系，如功能點，UCP等等。若是有，就能夠延續現有的需求規模估算方式。若是沒有，那麼我強烈建議，在需求上游對需求進行適當拆分，保證需求規模相對均勻，而後使用需求個數來反映需求規模。這其中的緣由在後面計算需求吞吐率時，會詳細解讀。

有些企業爲了規避需求規模這一難題，使用缺陷移除率這個指標。我不推薦這個指標，由於它違反了無害性原則，它會鼓勵測試人員多報測試缺陷來提升缺陷移除率，這樣會損害開發測試團隊配合。

生產缺陷需求比這個指標是另外一個重要的適應性指標，不一樣類型的企業會有不一樣的要求。它也與需求耗費時長造成了一對制衡，要又快又好才行。生產缺陷需求比應由全部和交付質量有關的人負責，包括產品經理，架構師，開發工程師，測試工程師。

我諮詢過程當中遇到一些團隊，抱怨這個指標已經很是好了，由於生產缺陷都已經私下處理了，沒有在系統中記錄，所以，還想去尋求別的指標。其實這時不須要糾結，而應該保證生產質量的前提下，將注意力轉向下面兩個方面:一、進一步縮短需求耗費時長，提升需求交付速度；2.改善開發移交質量，下降測試缺陷需求比，下降測試成本。

4. 測試缺陷需求比

測試缺陷需求比反映開發團隊初始移交質量水平。測試缺陷需求比的計算方式和生產缺陷需求比的計算方式相似：

須要注意的是，這個指標應由產品經理、開發工程師和測試工程師來共同負責。他們的目標應該是在儘可能在保證生產缺陷需求比的前提下，儘量下降測試缺陷需求比。例如，去年生產缺陷需求比爲0.1個缺陷每需求，測試缺陷需求比爲1.5個缺陷，那麼今年但願保持生產缺陷需求比先不變，但要把測試缺陷需求比下降到0.5個缺陷每需求。測試缺陷需求比和生產缺陷需求比構成了一對制衡。

測試缺陷需求比是一個槓桿指標，它引導組織的提高其內建質量能力，即由開發工程師在開發過程當中同步保證質量，而不是先構建再修復。這背後就是Google一直崇尚的質量觀：質量是開發工程師的神聖責任，而不只僅是測試工程師的責任；只有將開發和測試徹底地混合在一塊兒，不分彼此，纔可以真正得到好的質量。

測試缺陷需求比的改善會引起一些關聯反應，例如，因爲測試前置到開發環節參與質量提高活動（如實例化需求，故事驗收等工做），一個需求的開發測試時間比會發生變化。Agilean團隊以前輔導的一個產品，測試缺陷需求比降低了90%，同時開發測試時間比從1:1降低到4:1。另外一個長期可能出現變化的指標是開發測試人力比。衆所周知，Google的開發測試工程師比是10:1，而Facebook幾乎沒有測試。隨着內建質量能力提高，開發測試人力比會逐步提高。

5. 技術債務

技術債務是一個健康度指標，它表明代碼內在質量的健康程度，由圈複雜度、代碼重複率、每方法代碼行等許多指標構成。開源工具SonarCube已經提供了很是好的能力來量化技術債務。

技術債務和需求耗費時間是一對制衡。還技術債須要耗費開發人力，減小當前需求開發人力，短時間增長需求耗費時長，但能夠優化將來的需求耗費時長。把握好這個權衡主要由架構師和開發工程師來把握。

6. 可用度

可用度指標反映系統或服務的穩定性。可用度的計算公式以下：

例如，一個系統的服務水平協議是7天*11小時，那麼整年總可用時間就是365*11小時，而假設不可用時間是50小時，那麼系統可用度就是98.75%。建議由架構師，開發工程師，測試工程師，運維工程師共同負責改善這個指標，運維工程師主要保證軟硬件系統正常，開發工程師和測試工程師主要保證應用系統正常，架構師、開發工程師和運維工程師共同實現DevOps，縮短部署耗時，甚至實現不停機部署。不建議按不可用緣由（軟硬件系統故障緣由，應用故障緣由，部署緣由）來對這個指標進行細分，這樣會增長團隊間的摩擦，不利於團隊協做。

可用度是一個適應性指標，它適用於本身運維軟件、將軟件做爲服務載體的企業（例如，銀行或保險公司）、不適用於將軟件做爲產品交付出去的公司。這個指標和需求耗費時間是一對制衡，發的版本越多，需求等待越少，需求耗費長越短，但可用度可能越低。

7. 需求吞吐率

需求吞吐率反應研發組織的產能。需求吞吐率就是單位時間內每一個開發工程師完成的需求規模，例如每人每個月完成兩個需求，或者每人每個月完成五個功能點。

使用需求個數仍是需求估算點數來反映需求規模，主要看企業是否已經有一套成熟且有效運行的估算機制。若是沒有，我會強烈建議使用需求個數而不是需求估算點數來反應需求規模。使用估算點數，容易產生兩種危害：一、讓研發人員產生規模衝動，想辦法（如把需求文檔複雜化）來增長估算點數；二、催生產品經理和研發人員之間的不信任，進而產生討價還價、合同談判等浪費，這違反了無害性原則。

因爲上述緣由，我建議由產品經理和研發人員一塊兒，將需求分解成顆粒度相對均勻的需求條目，而後用需求個數來表示需求規模。這個指標可能會促使研發人員用動力去更細地拆分需求，但這個反作用對整個組織有利，更小的需求能夠更快地交付業務價值。在國際上，用需求個數來替代需求估算的思潮被叫作「拋棄估算」運動，若是讀者感興趣能夠點擊文章末尾的延伸閱讀去更多瞭解。

需求吞吐率是一個適應性指標，它和需求耗費時長造成一對制衡，避免團隊單純改善交付速度，而下降交付數量。可是，研發團隊不該該僅僅關注交付需求的數量還應該關心交付後的成效，我建議團隊每一個人也同時須要對業務指標負責。

8. 流動效率

流動效率反映需求交付過程的效率， 流動效率計算公式以下：

需求耗費時長一節中已經介紹瞭如何計算需求耗費時長，下面介紹如何計算需求增值時長。計算需求增值時長有三種方式：回憶法、記錄法和推算法，下面先用回憶法來講明。訪談參與需求交付的全部角色，請他們回憶交付過程當中，他們實際花費了多少個小時，最後將這些時間彙總。假設，需求A澄清環節花了3我的2個小時討論，研發花了4+6小時，測試花了4小時，改缺陷花了2個小時，UAT花了3個小時，部署花了1個小時，總共花了22個小時，而需求A的交付耗費時長爲25天，那麼需求A的流動效率就是：

在上述統計過程當中，有兩點注意事項：

• 建議用小時而不是人天爲單位，由於研發人員時間都很是碎片化，使用小時能夠促進他們更準確地估算；

• 統計時間，而不是工時，好比3我的花了2個小時澄清需求，只是將2個小時而不是6個小時計入需求增值時長；

瞭解瞭如何計算一個需求的效率以後，咱們來看如何計算研發交付系統的總體流動效率。例如，需求A增值時長22小時，交付耗費時長爲25天，需求B增值時長30小時，交付耗費時長28天，創意C交付耗費時長40小時，交付耗費時長30天，那麼總體流動效率是：

流動效率是一個很是重要的槓桿指標，實現自主流動是精益思想的核心，而每次成功的精益變革都得益於經過大幅提高流動效率來大幅提高交付時效，例如，福特用流水線方式生產T型車，將一輛車從12.5個小時縮短到了1小時33分鐘；Zara經過集中式生產，集中式上下游整合將服裝生命週期從6-9月縮短到最快兩週。

上面兩個例子都是製造業的例子，可是，軟件研發過程當中流動效率一樣很是低下（有研究代表，研發全流程流動效率只有1%-5%），這意味着若是可以對軟件研發過程進行精益化改造，一樣可以大幅縮短交付時效。軟件研發流程的精益化改造雖然複雜程度更高，但同時收益巨大，所以已經成爲許多大型企業的研究重點方向。

5、總結

 

下表對於那些角色應該關心哪些績效指標作了一個總結。這個績效度量體系中的指標能夠用於KPI，也能夠用於OKR，後面我會再寫一篇文章來專門闡述KPI和OKR的區別。

雖然花了許多時間來編寫這個指標體系，可是須要聲明，最理想的績效度量體系仍是沒有指度量指標，團隊一塊兒齊心合力以業務成功爲導向，這是上策。提出這個指標體系只能算一箇中策，至少讓團隊可以擺脫不合理指標體系的荼毒。