?作者 | 云昭

不管在哪個領(lǐng)域，團隊想要高效運轉(zhuǎn)，取得成功，最重要的是，讓團隊有一個與上下文語境相適應(yīng)的“方向”，而在軟件開發(fā)領(lǐng)域，KPI則充當著“北極星”，使團隊朝著正確的方向前進。

軟件開發(fā)KPI經(jīng)常與指標相混淆。指標是代表一個事實的數(shù)字，而KPI是對一個組織很重要的事情。注意：選擇KPI而不評估其給團隊帶來的影響，往往弊大于利。例如，“代碼行（LOC）”可以是一個度量，但絕不應(yīng)該是軟件開發(fā)團隊的“KPI”。

軟件開發(fā)的KPI只有設(shè)置正確的度量，才能有助于確保打造一支高績效、高效的工程團隊，從某種程度上看，這才是一支團隊真正的競爭優(yōu)勢?！案呖冃А焙汀案咝А钡亩x往往因業(yè)務(wù)性質(zhì)和許多其他因素而異。找出這些關(guān)鍵績效指標有助于區(qū)分重要因素和噪音。

在本文中，我們將介紹如何為團隊選擇KPI，并列出其他工程團隊行之有效的9個軟件開發(fā)KPI。

一、那些危險的KPI

“賽馬”、“LOC”、“編碼天數(shù)”……你應(yīng)該不惜一切代價避免以下這些指標。它們往往對開發(fā)團隊弊大于利。

1.有效編碼天數(shù)

這個指標絕不代表個人所做工作的質(zhì)量。每個人的工作模式都可能不同——有些人可能需要三天時間來理解需求，并邏輯地規(guī)劃出具體需要做什么，然后在一天內(nèi)完成實際任務(wù)。假設(shè)每個團隊成員都應(yīng)該每天編寫代碼，這是一個毫無根據(jù)的假設(shè)。團隊還有很多其他的工作，比如評審、設(shè)計、測試、發(fā)布、規(guī)劃、整理和幫助初級團隊成員等等。將編碼天數(shù)作為KPI進行跟蹤會使所有其他功能變得無用。而不是你想在一個高績效團隊中灌輸?shù)恼_文化。

2.代碼行

毫無疑問，這個古老的指標是跟蹤工程團隊生產(chǎn)力/產(chǎn)出的最差方法。跟蹤像LOC這樣的KPI表明，對于一項任務(wù)，如果一個團隊使用100行智能代碼，則比1000行錯誤代碼更糟糕。任何軟件開發(fā)團隊都不應(yīng)將LOC作為KPI。

3.沖刺速度（Velocity）

另一個非常常用的度量是速度（Velocity）。速度可以很好地指示完成了多少計劃任務(wù)，也有助于未來的沖刺計劃。但從來不是團隊生產(chǎn)力或效率的指標。當使用“Velocity”用于推動開發(fā)人員和比較團隊時，它會成為一個危險的KPI。即使在同一個組織中，兩個團隊也可能有非常不同的評估標準，作為團隊生產(chǎn)力的KPI，這種機制往往埋下危險的種子。團隊成員往往會為了完成KPI而使得工作變形，最后的結(jié)果適得其反。

4.與其他程序員相比較

許多管理者經(jīng)常會犯一個錯誤：將軟件開發(fā)KPI與以“開發(fā)人員生產(chǎn)力”為名跟蹤個人的指標混為一談。前者應(yīng)該代表團隊或項目的整體狀態(tài)，而不是個人。最重要的是，將一個開發(fā)人員與另一個進行比較，對于團隊的生產(chǎn)力而言，有百害而無一利。記?。哼@些KPI是為了促使團隊成員提高工程效率做出貢獻，而不要感到受到威脅。

二、五條原則

1.始終考慮團隊效率，而不是開發(fā)人員效率

軟件開發(fā)本質(zhì)上是一個團隊概念，從長遠來看，在個人層面制定KPI去跟蹤是行不通的。

2.KPI不應(yīng)是定量的

它應(yīng)該更多地關(guān)注你工作的質(zhì)量層面。例如，跟蹤“提交次數(shù)”不能成為KPI，但“客戶滿意度”就能很好地反應(yīng)出團隊產(chǎn)出的質(zhì)量，是一個不錯的候選指標。

3.首先確定重要流程，然后選擇KPI

KPI是對工程團隊至關(guān)重要的績效指標，所以首先要確定重要的流程，然后找出有助于實現(xiàn)這一目標的KPI。需要考慮的一些工程過程包括：規(guī)劃、執(zhí)行、代碼質(zhì)量、部署周期、測試、團隊健康和用戶滿意度。

4.永遠不要“復(fù)制粘貼”KPI

記住，組織的性質(zhì)、文化和發(fā)展方向，對于選擇正確的KPI非常重要。最好的方法是從別人做什么和不做什么中學(xué)習(xí)，但千萬不要因為這對他們有用就復(fù)制他們。

5.要團隊相信KPI的重要性

你在決定什么樣的軟件開發(fā)KPI對的團隊很重要時，還需要確定優(yōu)先級，并告訴團隊這對我們很重要。擁有錯誤的KPI比沒有KPI更糟糕。

三、行之有效的9個KPI

這些是我們看到的一些KPI，對于軟件開發(fā)團隊來說非常有效。（順序不表示重要性或有效性。）

1.團隊上手時間

新團隊成員開始為團隊交付做出有意義貢獻所需的時間。這有助于理解團隊的學(xué)習(xí)曲線有多大，也表明團隊在教育新成員有關(guān)團隊架構(gòu)、技術(shù)堆棧和開發(fā)實踐方面的效率有多高。數(shù)字越小，表示學(xué)習(xí)曲線越小，新成員可以開始快速做出貢獻，從而影響團隊的整體生產(chǎn)力以及新成員的滿意度。

2.測試有效性

這可以通過幾個指標的組合來衡量，比如在非生產(chǎn)環(huán)境與生產(chǎn)環(huán)境中發(fā)現(xiàn)的bug的比率、在非產(chǎn)品環(huán)境中測試的用戶場景的百分比以及測試分支覆蓋率。此KPI的主要目的應(yīng)該是確保團隊在投入使用之前測試更改的措施是有效的，并且生產(chǎn)缺陷的開銷不會降低團隊的速度。

3.有效開發(fā)

進行了多少代碼更改，并不重要，重要的是代碼的有效性。這里的有效性是是指，當團隊在添加新更改的同時不繼續(xù)添加代碼債務(wù)時，需要最少的返工。返工有時也反映出要求的不明確，或經(jīng)常需要進行特別改進。跟蹤代碼有效性的另一個很好的衡量標準是，開發(fā)的代碼對客戶產(chǎn)生影響的百分比是多少。將此作為KPI進行跟蹤有助于樹立有效工作比更多工作更重要的觀念。

4.客戶滿意度

開發(fā)團隊的所有工作最終都會為用戶提供新的功能或更好的體驗。衡量最終用戶滿意度是一個很好的衡量標準，可以表明團隊是否以正確的心態(tài)工作。

跟蹤這一點的幾種方法可以是測量功能的使用頻率，也可以來自新功能發(fā)布后的反饋調(diào)查。根據(jù)產(chǎn)品類型和組織提供的客戶支持、客戶報告錯誤的頻率、客戶請求的交付速度等指標，在衡量滿意度方面也起著重要作用。

管理者可以通過查看特性請求的周期時間（從整理到生產(chǎn)部署）來跟蹤特性請求的速度。

另一個非常有效的指標是NPS（Net Promoter Score，凈促銷得分），它是一個最終用戶向其他人推薦產(chǎn)品的可能性的得分。通常可以使用客戶調(diào)查和反饋表跟蹤這一點。

5.周期時長（Cycle Time）

這是一種廣泛使用的KPI，是交付速度的明確指標。周期時長主要幫助了解團隊的敏捷性，以及管理者應(yīng)該在哪些領(lǐng)域花費精力。例如，如果在登臺環(huán)境中進行測試所需的時間超過了開發(fā)項目，則意味著需要考慮如何優(yōu)化或者自動化測試框架。

跟蹤周期時長的最佳方法是從開始（計劃）到實現(xiàn)（生產(chǎn)部署）。繪制開發(fā)過程全貌的周期時間示例如下：

從計劃部署到生產(chǎn)部署的真實工程周期

將周期時間作為KPI進行跟蹤有助于了解不同流程的效率。有時，不同階段的周期可能不能精確到分鐘，但比較視圖和不同流程之間的整體分割，可以幫助你優(yōu)化正確的區(qū)域。

6.生產(chǎn)穩(wěn)定性和可觀測性

沒有一個系統(tǒng)是完美的，軟件開發(fā)中的錯誤是不可避免的。我們需要接受這樣一個事實：即完善開發(fā)過程無濟于事。擁有適當?shù)目捎^測性機制，將影響降至最低，是解決這一問題的最佳方法。關(guān)注過程的速度和穩(wěn)定性是關(guān)鍵（也是DORA度量思想的核心）。幫助了解穩(wěn)定性的一些軟件開發(fā)KPI包括：

（1）CFR（更改失敗率）：導(dǎo)致生產(chǎn)缺陷的部署百分比，有助于了解團隊修復(fù)缺陷的開銷發(fā)生的頻率。

（2）MTTD（平均檢測時間）：在生產(chǎn)中識別缺陷所需的平均時間-這代表了監(jiān)控和可觀察性機制的有效性。

（3）MTTR（平均恢復(fù)時間）：檢測到生產(chǎn)缺陷后修復(fù)生產(chǎn)缺陷所需的平均時間，表征著團隊找出并修復(fù)問題的速度，以最大限度地減少對最終用戶的影響。

7.團隊健康和滿意度

維珍創(chuàng)始人Richard Branson曾說：“照顧好你的員工，他們也會照顧好你?！焙笠咔闀r代，團隊成員都有待從倦怠中恢復(fù)，這比以往任何時候都更重要。確保團隊不會筋疲力盡，并對他們自身所做的工作感到滿意，這是擁有一個高效團隊的根本支柱。有助于跟蹤這一情況的一些指標包括：

（1）每個人都希望開發(fā)新功能和最新技術(shù)：如果你的團隊不斷致力于解決現(xiàn)有系統(tǒng)的bug和維護，勢必會引起團隊成員的不滿。

（2）開發(fā)經(jīng)驗-測試系統(tǒng)的：行更改是否太難了？為開發(fā)人員配備快速測試更改或運行小型POC的工具和靈活性對于擁有一個更快樂的團隊至關(guān)重要。

（3）花在會議上的時間與實際工作的時間：軟件開發(fā)團隊經(jīng)常面臨“會議疲勞”，他們在會議上花費的時間比工作效率高，這會導(dǎo)致倦怠和上下文切換，而這通常是可以避免的。了解團隊參加會議的次數(shù)或他們在會議上花費的時間百分比可以幫助了解團隊對會議的態(tài)度。

8.文件和知識共享

想要讓軟件開發(fā)團隊有效地工作，在整個團隊中廣泛地共享知識是必不可少的。它可以是代碼文檔、組件規(guī)范或設(shè)計文檔的形式。在很多情形中人們往往擔心團隊成員的外流。但問題在于，某個團隊成員要“活水”或跳槽到另一個團隊或組織，這都是時間長短的問題。零減員根本就是是不可能的。

所以，解決這一問題的最佳方法是減少團隊中的知識孤島，這樣即使團隊成員決定離開“演出”也可以繼續(xù)。涵蓋這一方面的工程KPI包括：

（1）記錄的代碼庫百分比。組件圖或API規(guī)范的更新頻率，是表示代碼/設(shè)計文檔實踐的幾個指標。

（2）新加入者理解系統(tǒng)所需的會議次數(shù)。大量的會議意味著沒有足夠的文檔作為新團隊成員的自助服務(wù)。

（3）只有一個團隊成員知道的代碼庫的百分比。（百分比越高=團隊中的知識庫越多）

9.任務(wù)規(guī)劃和可預(yù)測性

哪些任務(wù)需要完成，何時完成，以及誰來完成，這些都是計劃項目時需要回答的關(guān)鍵問題。并非所有團隊成員都必須參與決策，但是，團隊需要以可預(yù)見的方式為組織的發(fā)展而努力。以下是一些有效的KPI：

工作分解結(jié)構(gòu)：項目管理完全基于你如何將任務(wù)分解為更易于管理的任務(wù)，這有助于明確需要做什么，并更好地估計可能需要的時間。

可預(yù)測性：這表示在一個時間范圍內(nèi)完成的承諾工作的百分比。有很多事情可能會影響可預(yù)測性，比如臨時請求或生產(chǎn)錯誤。

WIP計數(shù)：可以同時處理幾件事情固然好，但同時處理太多事情是不可取的。通過查看開發(fā)團隊的這一點，可以了解規(guī)劃過程的健全性。

通過過程來選擇對您的團隊至關(guān)重要的正確軟件開發(fā)KPI可能會稍微耗時，但如果有正確的心態(tài)，從長遠來看，這是非常有用的。正確的績效指標，將在動蕩時期為你的工程團隊指引方向，并幫助確保朝著正確的方向前進。?