德魯克在《21世紀(jì)的管理挑戰(zhàn)》一書中指出：“管理的第一個(gè)任務(wù)是規(guī)定組織的成效和績效，而任何有這方面經(jīng)驗(yàn)的人都可以證明，這實(shí)質(zhì)上是一項(xiàng)最艱巨、最有爭議的任務(wù)，但同時(shí)也是最重要的工作”。知識(shí)工作的不確定性更高、組織成員相互協(xié)同更復(fù)雜，因此，為知識(shí)工者設(shè)計(jì)績效更加困難。人力資源同事絞盡腦汁，但研發(fā)管理者和研發(fā)團(tuán)隊(duì)又覺得指標(biāo)定義不合理，不斷討論、妥協(xié)的結(jié)果是，許多企業(yè)最后在使用一份有幾十個(gè)指標(biāo)的度量體系，管理成本高但激勵(lì)效果又不明顯。
筆者根據(jù)多年企業(yè)一線咨詢經(jīng)驗(yàn)，給讀者建議了一個(gè)研發(fā)績效度量框架作為參考。第一節(jié)將介紹這個(gè)框架的設(shè)計(jì)原則，便于讀者未來根據(jù)企業(yè)自身特點(diǎn)對這個(gè)度量框架進(jìn)行定制和調(diào)整，第二節(jié)將介紹框架中涉及的三種指標(biāo)類型，第三節(jié)將詳細(xì)介紹這個(gè)研發(fā)績效度量框架的具體指標(biāo)和算法。
一、研發(fā)績效度量體系設(shè)計(jì)五原則
1.外部性
同樣在《21世紀(jì)的管理挑戰(zhàn)》這本書中，德魯克指出，任何組織的績效都只在外部反映出來。以一個(gè)咖啡廳為例，客戶等待時(shí)間、咖啡口感、價(jià)格，這些都是客戶可感知的外部指標(biāo)。研發(fā)組織也應(yīng)優(yōu)先選取其客戶可感知的外部指標(biāo)作為研發(fā)組織績效指標(biāo)，這里客戶包括但不限于業(yè)務(wù)人員、產(chǎn)品經(jīng)理、最終用戶等。
2.無害性
管理學(xué)有一個(gè)原則“你考核什么你就會(huì)得到什么”，績效指標(biāo)對團(tuán)隊(duì)行為具有很大的牽引作用。設(shè)定一個(gè)指標(biāo)后，需要首先考慮負(fù)向牽引作用，既團(tuán)隊(duì)會(huì)采取哪些短期行為來試圖迅速達(dá)成績效指標(biāo)？評估一下這些短期行為對組織的傷害有多大？舉個(gè)例子，如果用開發(fā)代碼行數(shù)來評估開發(fā)工作量，就會(huì)對開發(fā)工程師產(chǎn)生一個(gè)明顯的負(fù)向牽引作用，讓開發(fā)工程師失去進(jìn)行優(yōu)雅設(shè)計(jì)或重構(gòu)代碼從而讓代碼更精簡的動(dòng)力。因此，績效度量體系應(yīng)盡量選取一些難于偽造或者偽造行為對組織傷害比較小的績效指標(biāo)。
3.整體性
軟件研發(fā)組織是一個(gè)復(fù)雜系統(tǒng)，各崗位間界限很難完全明確。管理者要克制將績效指標(biāo)分解到不同崗位，甚至分解到個(gè)人的沖動(dòng)。這種無效的指標(biāo)分解往往會(huì)導(dǎo)致局部優(yōu)化，即各崗位僅僅為自己的績效而優(yōu)化工作方法，反而降低了組織的績效。例如，將進(jìn)度和質(zhì)量兩個(gè)互相牽制的指標(biāo)，割裂開分配給開發(fā)測試，這造成開發(fā)只關(guān)心進(jìn)度，忽視移交質(zhì)量，而光靠測試來保證質(zhì)量。這種方式是不可能獲得高質(zhì)量軟件的，也不可能達(dá)到快速交付的目的。
4.制衡性
研發(fā)組織沒法用單一指標(biāo)來衡量，而需要用一組指標(biāo)來互相制約以求得平衡。例如，單純追求交付速度是危險(xiǎn)的，必須用質(zhì)量指標(biāo)來平衡。
5.演進(jìn)性
績效指標(biāo)應(yīng)該隨著組織的發(fā)展不斷調(diào)整，需要定期增減修訂指標(biāo)，保持指標(biāo)體系精簡，降低管理成本。
二、三種績效指標(biāo)類型
了解了定義研發(fā)績效體系的五個(gè)原則后，還需要介紹一下績效指標(biāo)的三種類型：
1.適應(yīng)性指標(biāo)
反應(yīng)組織是否適合生存，這些指標(biāo)因組織的特點(diǎn)不同而不同。例如，對于一個(gè)pizza外賣商家而言，pizza送達(dá)時(shí)長、送達(dá)準(zhǔn)時(shí)率和價(jià)格就是它的適應(yīng)性指標(biāo)，但pizza口感就不那么重要。但是，對于一家pizza精品餐廳而言，pizza口感就變得非常重要，而上菜等候時(shí)間就變得相對不那么重要了。好消息是，因?yàn)檠邪l(fā)比較同質(zhì)化，研發(fā)組織適應(yīng)性指標(biāo)相對統(tǒng)一。
2.健康度指標(biāo)
反映組織的健康程度，就如同一個(gè)人的心率、血壓，血脂指標(biāo)一樣。健康度指標(biāo)往往是內(nèi)部指標(biāo)，非客戶可見，因此需要非常小心衡量指標(biāo)的無害性和整體性。健康度指標(biāo)也需要不斷調(diào)整，一旦一個(gè)指標(biāo)經(jīng)常保持正常，就可以將它從績效指標(biāo)體系中剔除。舉個(gè)例子，代碼冗余度（有多少代碼是重復(fù)的）就是一個(gè)有用的代碼健康度指標(biāo)。
3.杠桿指標(biāo)
反映組織的重點(diǎn)改進(jìn)方向。很多時(shí)候，需要進(jìn)行某項(xiàng)改進(jìn)，通過杠桿指標(biāo)來撬動(dòng)適應(yīng)性指標(biāo)改進(jìn)。例如，今年要推行接口測試自動(dòng)化，就可以將接口測試代碼覆蓋率作為一個(gè)杠桿指標(biāo)，這一指標(biāo)的提升有利于保證生產(chǎn)質(zhì)量。杠桿指標(biāo)一般是內(nèi)部指標(biāo)，所以同樣要保證無害性和整體性。一旦改進(jìn)活動(dòng)告一段落，杠桿指標(biāo)可能會(huì)變成健康度指標(biāo)，也可能直接被剔除。
三、參考績效指標(biāo)體系
有了上面的理論鋪墊，可以進(jìn)入正題，介紹給讀者參考的研發(fā)績效度量指標(biāo)體系。這個(gè)體系的指標(biāo)分成四組，下面將一一詳細(xì)介紹：
響應(yīng)力，反映研發(fā)組織響應(yīng)市場要求的能力，包括需求耗費(fèi)時(shí)長，時(shí)長分布圖K值兩個(gè)指標(biāo)；
質(zhì)量，反映研發(fā)組織交付質(zhì)量，包括生產(chǎn)缺陷需求比，測試缺陷需求比兩個(gè)指標(biāo)；
可用度，反映研發(fā)組織管理的系統(tǒng)或服務(wù)的穩(wěn)定性，包括系統(tǒng)可用度或服務(wù)可用度指標(biāo)；
效能，反映研發(fā)組織的交付效率，包括需求吞吐率，流動(dòng)效率兩個(gè)指標(biāo)。
1. 需求耗費(fèi)時(shí)長
需求耗費(fèi)時(shí)長反映研發(fā)組織交付需求的速度。為了計(jì)算需求耗費(fèi)時(shí)長指標(biāo)，需要計(jì)算一段時(shí)間內(nèi)所有需求的耗費(fèi)時(shí)長，計(jì)算單一需求耗費(fèi)時(shí)長的公式非常簡單：
例如，需求A提出時(shí)間為12月5日，需求A上線時(shí)間是12月30日，那么，需求A耗費(fèi)時(shí)長就是25天，這里，需求提出時(shí)間是指業(yè)務(wù)人員和研發(fā)人員開始澄清需求細(xì)節(jié)的時(shí)間。
在計(jì)算出一段時(shí)間內(nèi)，所有單一需求耗費(fèi)時(shí)長之后，可以用以下公式計(jì)算需求耗費(fèi)時(shí)長：
例如，有10個(gè)需求，單一需求耗費(fèi)時(shí)間分別是23，42，45，45，45，47，50，62，70，123天，那么取85%百分位數(shù)，就相當(dāng)于取這個(gè)數(shù)列的第9個(gè)數(shù)（10*85%后四舍五入得出），最終需求耗費(fèi)時(shí)間是70天，這意味著，85%的需求是在70天內(nèi)交付的。
需求耗費(fèi)時(shí)長是一個(gè)典型的適應(yīng)性指標(biāo)，符合外部性和整體性，研發(fā)組織的客戶都非常關(guān)心，它代表研發(fā)組織的快速響應(yīng)能力。在實(shí)際使用中，如果研發(fā)組織內(nèi)存在多個(gè)不同需求類型，（常規(guī)需求、緊急需求和缺陷）那么就需要將這個(gè)指標(biāo)分成幾個(gè)不同的指標(biāo)，如常規(guī)需求耗費(fèi)時(shí)長，緊急需求耗費(fèi)時(shí)長以及缺陷修復(fù)時(shí)長等。
需求耗費(fèi)時(shí)長是反映組織敏捷度的重要指標(biāo)，因?yàn)?strong>需要所有角色齊心協(xié)力才能優(yōu)化這一指標(biāo)，所以所有相關(guān)角色都應(yīng)該對這個(gè)指標(biāo)負(fù)責(zé)，包括業(yè)務(wù)人員，產(chǎn)品經(jīng)理，架構(gòu)師，開發(fā)工程師，測試工程師，運(yùn)維工程師。開發(fā)測試及架構(gòu)師對這個(gè)指標(biāo)的貢獻(xiàn)比較容易理解，但產(chǎn)品經(jīng)理和運(yùn)維工程師對這個(gè)指標(biāo)也有獨(dú)特的貢獻(xiàn)：產(chǎn)品經(jīng)理需要保證需求盡量明確，對開發(fā)工程師提出的疑問快速響應(yīng)，對開發(fā)完的需求盡快驗(yàn)收；而運(yùn)維工程師需要在保持系統(tǒng)穩(wěn)定的前提下，盡量加快移交速度。
需求耗費(fèi)時(shí)長的一個(gè)類似指標(biāo)是需求完成度，例如2個(gè)月需求完成度，就是計(jì)算有百分之多少需求可以在2個(gè)月內(nèi)完成。我不推薦使用需求完成度這個(gè)指標(biāo)，因?yàn)檫@個(gè)百分比指標(biāo)會(huì)引導(dǎo)團(tuán)隊(duì)追求100%需求完成度，這不符合軟件開發(fā)中不確定管理的思路，也忽略了下面一節(jié)討論的需求耗費(fèi)時(shí)間分布分析。
2. 需求耗費(fèi)時(shí)長分布K值
需求耗費(fèi)時(shí)長分布K值反應(yīng)需求耗費(fèi)時(shí)長的分布特征。為了計(jì)算需求耗費(fèi)時(shí)長分布K值，需要先繪制需求耗費(fèi)時(shí)長分布圖。分布圖是一個(gè)柱狀圖，橫軸上X位置柱狀高度是需求耗費(fèi)時(shí)長為X天的需求的個(gè)數(shù)，例如，假設(shè)四個(gè)需求的耗費(fèi)時(shí)間，分別是8天，8天，9天，11天，那么畫出分布圖就如下圖所示：
下圖是一個(gè)實(shí)際團(tuán)隊(duì)的需求耗費(fèi)時(shí)長分布圖，符合韋伯分布（Weibull Distribution），其一個(gè)重要特點(diǎn)就是有一個(gè)眾數(shù)尖峰和一個(gè)長尾。眾數(shù)代表大多數(shù)需求可以在一個(gè)時(shí)長區(qū)間內(nèi)交付，是研發(fā)系統(tǒng)交付常態(tài)；而長尾代表交付系統(tǒng)的意外情況。在下圖中可以看到由于長尾的存在，導(dǎo)致需求耗費(fèi)時(shí)長的均值大于中值，85%百分位數(shù)大于均值20%，而98%百分位數(shù)三倍于均值。
韋伯分布是瑞典工程師韋伯在1930年研究軸承壽命時(shí)發(fā)現(xiàn)的，他采用了“鏈?zhǔn)健蹦Ｐ蛠斫忉寜勖鼏栴}。這個(gè)模型假設(shè)一個(gè)結(jié)構(gòu)是由n個(gè)小元件串聯(lián)而成，于是可以形象地將結(jié)構(gòu)看成是由n個(gè)環(huán)構(gòu)成的一條鏈條，其壽命取決于最薄弱環(huán)的壽命。軟件研發(fā)可以看成一個(gè)由需求，設(shè)計(jì)，開發(fā)和測試等環(huán)節(jié)構(gòu)成的鏈條，任何一個(gè)環(huán)節(jié)出問題，軟件則無法按時(shí)交付，這是為什么需求耗費(fèi)時(shí)長也符合韋伯分布的根本原因。
韋伯分布有兩個(gè)參數(shù)，一個(gè)是λ，一個(gè)是k。λ決定了眾數(shù)峰值的高度，k決定了曲線的形狀。下圖給出了四種k值的韋伯分布曲線：
需求耗費(fèi)時(shí)長分布圖的K值是一個(gè)健康度指標(biāo)，用來判斷需求耗費(fèi)時(shí)長分布是否合理，是否符合可預(yù)測性要求。如果K值小于1，那么這個(gè)研發(fā)交付系統(tǒng)是非常脆弱的，不具備可預(yù)測性，需求可能很快交付，也可能會(huì)非常慢。如果K值大于2，那么需求交付整體上都很慢，但可預(yù)測性比較強(qiáng)；軟件開發(fā)組織的K值會(huì)在1.0到2.0之間。
3. 生產(chǎn)缺陷需求比
生產(chǎn)缺陷需求比反應(yīng)了研發(fā)組織的交付質(zhì)量。在給定時(shí)間內(nèi)，生產(chǎn)缺陷需求比可以這樣計(jì)算：
例如，全年生產(chǎn)缺陷200個(gè)，上線需求2000個(gè)，那么生產(chǎn)缺陷需求比的數(shù)值為每需求0.1個(gè)缺陷。在實(shí)際使用的過程中，如果企業(yè)已經(jīng)有一套生產(chǎn)缺陷分級機(jī)制，那么可以使用生產(chǎn)缺陷嚴(yán)重級別對生產(chǎn)缺陷數(shù)量進(jìn)行加權(quán)計(jì)算。舉個(gè)例子，假設(shè)在200個(gè)缺陷里有致命缺陷20個(gè)、嚴(yán)重缺陷50個(gè)、普通缺陷130個(gè)，致命缺陷權(quán)值為3，嚴(yán)重缺陷權(quán)值為1，普通缺陷權(quán)值為0.5，那么加權(quán)后的生產(chǎn)缺陷個(gè)數(shù)是（20*3 50*1 130*0.5），共175個(gè)，加權(quán)生產(chǎn)缺陷需求比就是每需求0.0875個(gè)缺陷。
使用這個(gè)指標(biāo)的一個(gè)挑戰(zhàn)是如何確定需求規(guī)模。這個(gè)首先要看企業(yè)是不是已經(jīng)有一套可行的需求規(guī)模估算體系，如功能點(diǎn)，UCP等等。如果有，就可以延續(xù)現(xiàn)有的需求規(guī)模估算方式。如果沒有，那么我強(qiáng)烈建議，在需求上游對需求進(jìn)行適當(dāng)拆分，保證需求規(guī)模相對均勻，然后使用需求個(gè)數(shù)來反映需求規(guī)模。這其中的原因在后面計(jì)算需求吞吐率時(shí)，會(huì)詳細(xì)解讀。
有些企業(yè)為了規(guī)避需求規(guī)模這一難題，使用缺陷移除率這個(gè)指標(biāo)。我不推薦這個(gè)指標(biāo)，因?yàn)樗`反了無害性原則，它會(huì)鼓勵(lì)測試人員多報(bào)測試缺陷來提高缺陷移除率，這樣會(huì)損害開發(fā)測試團(tuán)隊(duì)配合。
生產(chǎn)缺陷需求比這個(gè)指標(biāo)是另一個(gè)重要的適應(yīng)性指標(biāo)，不同類型的企業(yè)會(huì)有不同的要求。它也與需求耗費(fèi)時(shí)長形成了一對制衡，要又快又好才行。生產(chǎn)缺陷需求比應(yīng)由所有和交付質(zhì)量有關(guān)的人負(fù)責(zé)，包括產(chǎn)品經(jīng)理，架構(gòu)師，開發(fā)工程師，測試工程師。
我咨詢過程中遇到一些團(tuán)隊(duì)，抱怨這個(gè)指標(biāo)已經(jīng)非常好了，因?yàn)樯a(chǎn)缺陷都已經(jīng)私下處理了，沒有在系統(tǒng)中記錄，因此，還想去尋求別的指標(biāo)。其實(shí)這時(shí)不需要糾結(jié)，而應(yīng)該保證生產(chǎn)質(zhì)量的前提下，將注意力轉(zhuǎn)向下面兩個(gè)方面:1、進(jìn)一步縮短需求耗費(fèi)時(shí)長，提高需求交付速度；2.改善開發(fā)移交質(zhì)量，降低測試缺陷需求比，降低測試成本。
4. 測試缺陷需求比
測試缺陷需求比反映開發(fā)團(tuán)隊(duì)初始移交質(zhì)量水平。測試缺陷需求比的計(jì)算方式和生產(chǎn)缺陷需求比的計(jì)算方式類似：
需要注意的是，這個(gè)指標(biāo)應(yīng)由產(chǎn)品經(jīng)理、開發(fā)工程師和測試工程師來共同負(fù)責(zé)。他們的目標(biāo)應(yīng)該是在盡量在保證生產(chǎn)缺陷需求比的前提下，盡可能降低測試缺陷需求比。例如，去年生產(chǎn)缺陷需求比為0.1個(gè)缺陷每需求，測試缺陷需求比為1.5個(gè)缺陷，那么今年希望保持生產(chǎn)缺陷需求比先不變，但要把測試缺陷需求比降低到0.5個(gè)缺陷每需求。測試缺陷需求比和生產(chǎn)缺陷需求比構(gòu)成了一對制衡。
測試缺陷需求比是一個(gè)杠桿指標(biāo)，它引導(dǎo)組織的提升其內(nèi)建質(zhì)量能力，即由開發(fā)工程師在開發(fā)過程中同步保證質(zhì)量，而不是先構(gòu)建再修復(fù)。這背后就是Google一直崇尚的質(zhì)量觀：質(zhì)量是開發(fā)工程師的神圣責(zé)任，而不僅僅是測試工程師的責(zé)任；只有將開發(fā)和測試完全地混合在一起，不分彼此，才能夠真正獲得好的質(zhì)量。
測試缺陷需求比的改善會(huì)引發(fā)一些關(guān)聯(lián)反應(yīng)，例如，由于測試前置到開發(fā)環(huán)節(jié)參與質(zhì)量提升活動(dòng)（如實(shí)例化需求，故事驗(yàn)收等工作），一個(gè)需求的開發(fā)測試時(shí)間比會(huì)發(fā)生變化。Agilean團(tuán)隊(duì)之前輔導(dǎo)的一個(gè)產(chǎn)品，測試缺陷需求比下降了90%，同時(shí)開發(fā)測試時(shí)間比從1:1下降到4:1。另一個(gè)長期可能出現(xiàn)變化的指標(biāo)是開發(fā)測試人力比。眾所周知，Google的開發(fā)測試工程師比是10:1，而Facebook幾乎沒有測試。隨著內(nèi)建質(zhì)量能力提升，開發(fā)測試人力比會(huì)逐步提升。
5. 技術(shù)債務(wù)
技術(shù)債務(wù)是一個(gè)健康度指標(biāo)，它代表代碼內(nèi)在質(zhì)量的健康程度，由圈復(fù)雜度、代碼重復(fù)率、每方法代碼行等許多指標(biāo)構(gòu)成。開源工具SonarCube已經(jīng)提供了非常好的能力來量化技術(shù)債務(wù)。
技術(shù)債務(wù)和需求耗費(fèi)時(shí)間是一對制衡。還技術(shù)債需要耗費(fèi)開發(fā)人力，減少當(dāng)前需求開發(fā)人力，短期增加需求耗費(fèi)時(shí)長，但可以優(yōu)化未來的需求耗費(fèi)時(shí)長。把握好這個(gè)權(quán)衡主要由架構(gòu)師和開發(fā)工程師來把握。
6. 可用度
可用度指標(biāo)反映系統(tǒng)或服務(wù)的穩(wěn)定性。可用度的計(jì)算公式如下：
例如，一個(gè)系統(tǒng)的服務(wù)水平協(xié)議是7天*11小時(shí)，那么全年總可用時(shí)間就是365*11小時(shí)，而假設(shè)不可用時(shí)間是50小時(shí)，那么系統(tǒng)可用度就是98.75%。建議由架構(gòu)師，開發(fā)工程師，測試工程師，運(yùn)維工程師共同負(fù)責(zé)改善這個(gè)指標(biāo)，運(yùn)維工程師主要保證軟硬件系統(tǒng)正常，開發(fā)工程師和測試工程師主要保證應(yīng)用系統(tǒng)正常，架構(gòu)師、開發(fā)工程師和運(yùn)維工程師共同實(shí)現(xiàn)DevOps，縮短部署耗時(shí)，甚至實(shí)現(xiàn)不停機(jī)部署。不建議按不可用原因（軟硬件系統(tǒng)故障原因，應(yīng)用故障原因，部署原因）來對這個(gè)指標(biāo)進(jìn)行細(xì)分，這樣會(huì)增加團(tuán)隊(duì)間的摩擦，不利于團(tuán)隊(duì)協(xié)作。
可用度是一個(gè)適應(yīng)性指標(biāo)，它適用于自己運(yùn)維軟件、將軟件作為服務(wù)載體的企業(yè)（例如，銀行或保險(xiǎn)公司）、不適用于將軟件作為產(chǎn)品交付出去的公司。這個(gè)指標(biāo)和需求耗費(fèi)時(shí)間是一對制衡，發(fā)的版本越多，需求等待越少，需求耗費(fèi)長越短，但可用度可能越低。
7. 需求吞吐率
需求吞吐率反應(yīng)研發(fā)組織的產(chǎn)能。需求吞吐率就是單位時(shí)間內(nèi)每個(gè)開發(fā)工程師完成的需求規(guī)模，例如每人每月完成兩個(gè)需求，或者每人每月完成五個(gè)功能點(diǎn)。
使用需求個(gè)數(shù)還是需求估算點(diǎn)數(shù)來反映需求規(guī)模，主要看企業(yè)是否已經(jīng)有一套成熟且有效運(yùn)行的估算機(jī)制。如果沒有，我會(huì)強(qiáng)烈建議使用需求個(gè)數(shù)而不是需求估算點(diǎn)數(shù)來反應(yīng)需求規(guī)模。使用估算點(diǎn)數(shù)，容易產(chǎn)生兩種危害：1、讓研發(fā)人員產(chǎn)生規(guī)模沖動(dòng)，想辦法（如把需求文檔復(fù)雜化）來增加估算點(diǎn)數(shù)；2、催生產(chǎn)品經(jīng)理和研發(fā)人員之間的不信任，進(jìn)而產(chǎn)生討價(jià)還價(jià)、合同談判等浪費(fèi)，這違反了無害性原則。
由于上述原因，我建議由產(chǎn)品經(jīng)理和研發(fā)人員一起，將需求分解成顆粒度相對均勻的需求條目，然后用需求個(gè)數(shù)來表示需求規(guī)模。這個(gè)指標(biāo)可能會(huì)促使研發(fā)人員用動(dòng)力去更細(xì)地拆分需求，但這個(gè)副作用對整個(gè)組織有利，更小的需求可以更快地交付業(yè)務(wù)價(jià)值。在國際上，用需求個(gè)數(shù)來替代需求估算的思潮被叫做“拋棄估算”運(yùn)動(dòng)，如果讀者感興趣可以點(diǎn)擊文章末尾的延伸閱讀去更多了解。
需求吞吐率是一個(gè)適應(yīng)性指標(biāo)，它和需求耗費(fèi)時(shí)長形成一對制衡，避免團(tuán)隊(duì)單純改善交付速度，而降低交付數(shù)量。但是，研發(fā)團(tuán)隊(duì)不應(yīng)該僅僅關(guān)注交付需求的數(shù)量還應(yīng)該關(guān)心交付后的成效，我建議團(tuán)隊(duì)每個(gè)人也同時(shí)需要對業(yè)務(wù)指標(biāo)負(fù)責(zé)。
8. 流動(dòng)效率
流動(dòng)效率反映需求交付過程的效率， 流動(dòng)效率計(jì)算公式如下：
需求耗費(fèi)時(shí)長一節(jié)中已經(jīng)介紹了如何計(jì)算需求耗費(fèi)時(shí)長，下面介紹如何計(jì)算需求增值時(shí)長。計(jì)算需求增值時(shí)長有三種方式：回憶法、記錄法和推算法，下面先用回憶法來說明。訪談參與需求交付的所有角色，請他們回憶交付過程中，他們實(shí)際花費(fèi)了多少個(gè)小時(shí)，最后將這些時(shí)間匯總。假設(shè)，需求A澄清環(huán)節(jié)花了3個(gè)人2個(gè)小時(shí)討論，研發(fā)花了4 6小時(shí)，測試花了4小時(shí)，改缺陷花了2個(gè)小時(shí)，UAT花了3個(gè)小時(shí)，部署花了1個(gè)小時(shí)，總共花了22個(gè)小時(shí)，而需求A的交付耗費(fèi)時(shí)長為25天，那么需求A的流動(dòng)效率就是：
在上述統(tǒng)計(jì)過程中，有兩點(diǎn)注意事項(xiàng)：
建議用小時(shí)而不是人天為單位，因?yàn)檠邪l(fā)人員時(shí)間都非常碎片化，使用小時(shí)可以促進(jìn)他們更準(zhǔn)確地估算；
統(tǒng)計(jì)時(shí)間，而不是工時(shí)，比如3個(gè)人花了2個(gè)小時(shí)澄清需求，只是將2個(gè)小時(shí)而不是6個(gè)小時(shí)計(jì)入需求增值時(shí)長；
了解了如何計(jì)算一個(gè)需求的效率之后，我們來看如何計(jì)算研發(fā)交付系統(tǒng)的整體流動(dòng)效率。例如，需求A增值時(shí)長22小時(shí)，交付耗費(fèi)時(shí)長為25天，需求B增值時(shí)長30小時(shí)，交付耗費(fèi)時(shí)長28天，創(chuàng)意C交付耗費(fèi)時(shí)長40小時(shí)，交付耗費(fèi)時(shí)長30天，那么整體流動(dòng)效率是：
流動(dòng)效率是一個(gè)非常重要的杠桿指標(biāo)，實(shí)現(xiàn)自主流動(dòng)是精益思想的核心，而每次成功的精益變革都得益于通過大幅提升流動(dòng)效率來大幅提升交付時(shí)效，例如，福特用流水線方式生產(chǎn)T型車，將一輛車從12.5個(gè)小時(shí)縮短到了1小時(shí)33分鐘；Zara通過集中式生產(chǎn)，集中式上下游整合將服裝生命周期從6-9月縮短到最快兩周。
上面兩個(gè)例子都是制造業(yè)的例子，但是，軟件研發(fā)過程中流動(dòng)效率同樣非常低下（有研究表明，研發(fā)全流程流動(dòng)效率只有1%-5%），這意味著如果能夠?qū)浖邪l(fā)過程進(jìn)行精益化改造，同樣能夠大幅縮短交付時(shí)效。軟件研發(fā)流程的精益化改造雖然復(fù)雜程度更高，但同時(shí)收益巨大，因此已經(jīng)成為許多大型企業(yè)的研究重點(diǎn)方向。
五、總結(jié)
下表對于那些角色應(yīng)該關(guān)心哪些績效指標(biāo)做了一個(gè)總結(jié)。這個(gè)績效度量體系中的指標(biāo)可以用于KPI，也可以用于OKR，后面我會(huì)再寫一篇文章來專門闡述KPI和OKR的區(qū)別。
雖然花了許多時(shí)間來編寫這個(gè)指標(biāo)體系，但是需要聲明，最理想的績效度量體系還是沒有指度量指標(biāo)，團(tuán)隊(duì)一起齊心協(xié)力以業(yè)務(wù)成功為導(dǎo)向，這是上策。提出這個(gè)指標(biāo)體系只能算一個(gè)中策，至少讓團(tuán)隊(duì)能夠擺脫不合理指標(biāo)體系的荼毒。
聯(lián)系客服
