隨著敏捷漸入人心，踐行者們積極開展諸多嘗試，卻疏於建立與之相匹配的績效體系，甚至認為既然敏捷了，還搞績效何用。在過往十餘年為大企業進行敏捷落地諮詢的過程中，我們強烈感受到敏捷組織不僅要有績效體系，還應投入更多思考，精心設計合理的考核指標並不斷疊代優化。這裡，就以 Agilean 自創的研發績效體系( DEF , Development Efficacy Framework)為例，來談談我們的觀點與實踐。
這套績效體系以「多快好喜」4組指標為核心：
- 多：需求吞吐量和吞吐率，衡量現實產能；
- 快：想法澄清、需求研發、故障修復的耗費時長，衡量研發部門對市場要求的響應能力；
- 好：生產缺陷需求比，衡量交付質量；
- 喜：需求方對交付的評價，衡量業務滿意度。
知微系統已將這套指標體系納入統計功能，從而進行可視化展現和快速統計。下面將結合知微研發同學的真實數據，對重要指標進行詳細解釋。
1
需求耗費時長
需求耗費時長（即需求前置時間，Leadtime）衡量研發團隊需求交付速度，它反映了研發的快速響應能力，受到很多研發團隊關注。
計算單一「需求耗費時長」的公式如下：
如果一個需求11月5日提出，11月20日上線，則該需求耗費時長為15天。
基於過往經驗，我們建議研發部門以85%分位數來衡量整體需求耗費時長指標。隨機取10個需求為例，耗費時長分別是15、25、40、45、45、45、48、52、65、80天，85%分位數為第9個數字（10*85%並四捨五入），由此可知85%的需求在65天內交付。
知微的統計視圖即以85%分位數對需求耗費時長進行可視化展示。下圖為2017年7月至今年11月13日的真實數據，即知微研發近3年的需求耗費時長統計。圖里方框內的數字，表示如果以2017年11月28日之前的90天為採樣周期，知微85%的需求在27天內完成。
為什麼選用85%分位數而不是使用更廣的平均數？統計的意義在於以真實有效的數據進行預測，從而支持更優決策，避免由於主觀或經驗判斷布下的雷區，而均值和50%分位數無法具備支持預測的作用。通常情況下，均值和85%分位數的統計結果會出現兩倍的差距，85%分位數和99%分位數也往往是約兩倍關係（考慮此文主題，背後原理不再展開）。因此，85%分位數是一個很好的預測平衡點。
上面這張柱形分布圖，真實展現了知微三年來的需求耗費時長。可以看到，數據較好地符合了韋伯分布（Weibull Distribution），即存在一個眾數尖峰以及一條長尾。排除掉異常時間影響後，我們就可以自信地進行整體交付時效和響應指標的預測。
需求耗費時長是一項非常重要的協作指標。研發部門任何環節掉隊，都會導致該指標發生敏感變化，因此，所有相關角色都應對該指標負責。基於以上考慮，知微支持對需求耗費時長進行分段計算。不僅能實時展示需求端到端耗費時長，也可以分成需求分析、設計、研發、測試、驗收等各段分別展示，並以不同顏色的線條表現其變化趨勢。
舉一個典型例子。開發同學經常為整體交付慢背鍋，很多人認為需求交付慢的根源在於開發耗時太久。但通過知微研發團隊累積的真實數據可以看到，開發環節耗費時長（9天）遠遠少於需求分析（14天）和驗收（14天）。事實上，我們用了兩倍於開發階段的時間，來想清楚需求。通過自身經歷，我們深深感受到對創新產品來說，想清楚需求要花很多時間，過程中需要不同角色參與，需要頭腦風暴和反覆討論。在這個過程中，研發並不是瓶頸，「想好」是「做好」的前提。
通過上述的分段計算方式，需求完成鏈條中不同階段的具體耗時一目了然。團隊可以快速發現影響整體交付速度的環節，找到真正的痛點，並採取有針對性的改善措施，而不是僅憑主觀做出判斷。
現實中，不同企業不同研發部門對「需求耗費時長」的理解並不一致，主要差異在於該從哪個步驟開始計算：用需求提出時間？需求澄清時間？還是需求確認選擇時間？我們認為最好採用適合組織流程現狀的統計方式，這並不會影響該指標蘊含的價值。因此，知微上所有的統計指標和計算公式，都能根據企業需要進行靈活定義和實時調整，人們可以自行編輯諸如需求耗費時長一類的計算公式，只要該統計結果能在現實中引領改善，對企業就是有意義的。
2
需求吞吐量和吞吐率
需求吞吐量（單位時間或版本內完成的需求個數），是最直觀粗暴的研發產能度量指標，表述通常為「上個版本完成了XX個需求」。
需求吞吐率在吞吐量基礎上增加了平均計算，以衡量單位時間或版本完成的平均需求規模，表述通常為「今年以來，每個版本平均完成XX個需求」。
這兩個指標容易理解且應用廣泛。以知微為例，下圖是研發團隊近兩年需求吞吐量的按月統計結果（也可按需選擇日、周、雙周等不同統計周期），從圖中數據可以計算出研發團隊的吞吐率。比如，今年6-10月這段時間，需求吞吐率為52個需求/月。
除了按時間統計產能，知微也支持按版本進行吞吐量和吞吐率統計。下圖可以看出知微的疊代速度（差不多每兩周一個版本），以及每個版本完成了多少個需求，以及產能的變化。
採用吞吐量和吞吐率作為產能指標，往往被問到一個問題：如何衡量需求規模？目前，需求規模衡量通常有兩種選擇：需求個數、需求估算點數。如果尚未建起一套成熟有效的估算機制，我們強烈建議使用需求個數而非需求估算點數來衡量需求規模。產品經理與研發共同協作，將需求拆分成粒度相對均勻的條目，再用需求個數來代表需求規模。
除度量產能這個作用以外，需求吞吐量/率還能夠與需求耗費時長形成制衡，二者共同使用，可以避免只改善交付速度但降低交付數量，或者只考慮數量增加而忽視了速度。在二者基礎之上，研發還應關注交付質量和交付成效，助力業務指標的達成。
那麼，好的質量指標該是什麼樣？請繼續往下看。
3
生產缺陷需求比
生產缺陷需求比是一項質量指標，用於衡量研發交付質量，計算公式如下：
直接以知微研發團隊的實際數據進行介紹：
知微上一個版本V1.1.1，上線需求59個，生產缺陷7個，生產缺陷需求比為0.11個缺陷每需求。這是對該指標的基礎統計，我們建議研發團隊建立一套生產缺陷分級機制，按照致命缺陷、嚴重缺陷、普通缺陷等嚴重級別對生產缺陷數量進行加權計算。
依然採用知微V1.1.1版本的數據。過濾後發現7個缺陷均為普通缺陷，如果致命、嚴重、普通缺陷權重分別為3、1、0.5，加權後的生產缺陷個數為0*3+0*1+7*0.5=3.5，即加權後的生產缺陷需求比為0.06個缺陷每需求。
不同業務類型、不同規模的研發組織對質量的要求不盡相同。生產缺陷需求比與需求耗費時長可以形成制衡，既要交付快，也要兼顧質量水平。很多角色可能對質量造成影響，比如產品經理、開發工程師、測試工程師、架構師等。
4
滿意度指標
與需求耗費時長、吞吐量等指標相比，滿意度是一個外部指標，它反映需求方（外部客戶、業務部門等）對研發交付質量、時效、可用度、體驗等的綜合評價。滿意度有時會帶上主觀因素，但我們仍應儘可能客觀地度量它。
一個需求上線後，其耗費時長、吞吐量、生產缺陷需求比等指標已經可以得出。到此階段時，對需求的評價已暫時脫離研發體系，轉而由業務部門處理，通過適合的評價體系，在客戶處獲得對該需求的滿意度評價。
目前流行的滿意度指標體系中，常見的是CSAT「非常滿意」-「非常不滿意」5重評價，NPS（凈推薦值）的0分（完全不可能）- 1分（完全可能）推薦傾向。對於服務型產品，有CES（用戶費力度）的評價體系。這些指標無好壞之分，企業按需採用即可。
針對滿意度指標統計，知微能夠配置出不同的滿意度評價指標，將該指標作為一項屬性，由具體的需求卡片承載（見上圖）。也具備指定打分人、需求完成後打分提醒等功能。
5
總結部分
我們總結出以下表格，來直觀展現哪些角色應該關注哪些指標：
除了文中談到的幾個指標，還有很多相關概念和內容值得展開闡述，包括上表里的流動效率、分布K值等等。
作者：Fitzz 來源：Agilean