轉載理由：

本文的第一部分和第二部分的理論非常值得借鑑，但第三部分的很多指標已經不適用于敏捷過程，並且即使是傳統瀑布過程，這些指標也適用於巨集觀管理，只有少量指標適用於微觀團隊，不過仍然有一定借鑑意義。

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

知識工作的不確定性更高、組織成員相互協同更復雜，因此，為知識工者設計績效更加困難。

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

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

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

1.外部性

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

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

2.無害性

管理學有一個原則“你考核什麼你就會得到什麼”，績效指標對團隊行為具有很大的牽引作用。

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

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

因此，績效度量體系應儘量選取一些難於偽造或者偽造行為對組織傷害比較小的績效指標。

3.整體性

軟體研發組織是一個複雜系統，各崗位間界限很難完全明確。管理者要剋制將績效指標分解到不同崗位，甚至分解到個人的衝動。這種無效的指標分解往往會導致區域性優化

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

4.制衡性

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

5.演進性

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

二、三種績效指標型別

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

1.適應性指標

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

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

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

2.健康度指標

反映組織的健康程度，就如同一個人的心率、血壓，血脂指標一樣。健康度指標往往是內部指標，非客戶可見，因此需要非常小心衡量指標的無害性和整體性。

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

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

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等等。如果有，就可以延續現有的需求規模估算方式。如果沒有，那麼我強烈建議，在需求上游對需求進行適當拆分，保證需求規模相對均勻，然後使用需求個數來反映需求規模。這其中的原因在後面計算需求吞吐率時，會詳細解讀。

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

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

我諮詢過程中遇到一些團隊，抱怨這個指標已經非常好了，因為生產缺陷都已經私下處理了，沒有在系統中記錄，因此，還想去尋求別的指標。其實這時不需要糾結，而應該保證生產質量的前提下，將注意力轉向下面兩個方面:1、進一步縮短需求耗費時長，提高需求交付速度；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. 需求吞吐率

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

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

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

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

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%），這意味著如果能夠對軟體研發過程進行精益化改造，同樣能夠大幅縮短交付時效。軟體研發流程的精益化改造雖然複雜程度更高，但同時收益巨大，因此已經成為許多大型企業的研究重點方向。

五、總結

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

雖然花了許多時間來編寫這個指標體系，但是需要宣告，最理想的績效度量體系還是沒有指度量指標，團隊一起齊心協力以業務成功為導向，這是上策。提出這個指標體系只能算一箇中策，至少讓團隊能夠擺脫不合理指標體系的荼毒。