?作者 | 云昭
不管在哪個領域，團隊想要高效運轉，取得成功，最重要的是，讓團隊有一個與上下文語境相適應的“方向”，而在軟件開發領域，KPI則充當著“北極星”，使團隊朝著正確的方向前進。
軟件開發KPI經常與指標相混淆。指標是代表一個事實的數字，而KPI是對一個組織很重要的事情。注意：選擇KPI而不評估其給團隊帶來的影響，往往弊大于利。例如，“代碼行（LOC）”可以是一個度量，但絕不應該是軟件開發團隊的“KPI”。
軟件開發的KPI只有設置正確的度量，才能有助于確保打造一支高績效、高效的工程團隊，從某種程度上看，這才是一支團隊真正的競爭優勢。“高績效”和“高效”的定義往往因業務性質和許多其他因素而異。找出這些關鍵績效指標有助于區分重要因素和噪音。
在本文中，我們將介紹如何為團隊選擇KPI，并列出其他工程團隊行之有效的9個軟件開發KPI。
一、那些危險的KPI
“賽馬”、“LOC”、“編碼天數”……你應該不惜一切代價避免以下這些指標。它們往往對開發團隊弊大于利。
1.有效編碼天數
這個指標絕不代表個人所做工作的質量。每個人的工作模式都可能不同——有些人可能需要三天時間來理解需求，并邏輯地規劃出具體需要做什么，然后在一天內完成實際任務。假設每個團隊成員都應該每天編寫代碼，這是一個毫無根據的假設。團隊還有很多其他的工作，比如評審、設計、測試、發布、規劃、整理和幫助初級團隊成員等等。將編碼天數作為KPI進行跟蹤會使所有其他功能變得無用。而不是你想在一個高績效團隊中灌輸的正確文化。
2.代碼行
毫無疑問，這個古老的指標是跟蹤工程團隊生產力/產出的最差方法。跟蹤像LOC這樣的KPI表明，對于一項任務，如果一個團隊使用100行智能代碼，則比1000行錯誤代碼更糟糕。任何軟件開發團隊都不應將LOC作為KPI。
3.沖刺速度（Velocity）
另一個非常常用的度量是速度（Velocity）。速度可以很好地指示完成了多少計劃任務，也有助于未來的沖刺計劃。但從來不是團隊生產力或效率的指標。當使用“Velocity”用于推動開發人員和比較團隊時，它會成為一個危險的KPI。即使在同一個組織中，兩個團隊也可能有非常不同的評估標準，作為團隊生產力的KPI，這種機制往往埋下危險的種子。團隊成員往往會為了完成KPI而使得工作變形，最后的結果適得其反。
4.與其他程序員相比較
許多管理者經常會犯一個錯誤：將軟件開發KPI與以“開發人員生產力”為名跟蹤個人的指標混為一談。前者應該代表團隊或項目的整體狀態，而不是個人。最重要的是，將一個開發人員與另一個進行比較，對于團隊的生產力而言，有百害而無一利。記住：這些KPI是為了促使團隊成員提高工程效率做出貢獻，而不要感到受到威脅。
二、五條原則
1.始終考慮團隊效率，而不是開發人員效率
軟件開發本質上是一個團隊概念，從長遠來看，在個人層面制定KPI去跟蹤是行不通的。
2.KPI不應是定量的
它應該更多地關注你工作的質量層面。例如，跟蹤“提交次數”不能成為KPI，但“客戶滿意度”就能很好地反應出團隊產出的質量，是一個不錯的候選指標。
3.首先確定重要流程，然后選擇KPI
KPI是對工程團隊至關重要的績效指標，所以首先要確定重要的流程，然后找出有助于實現這一目標的KPI。需要考慮的一些工程過程包括：規劃、執行、代碼質量、部署周期、測試、團隊健康和用戶滿意度。
4.永遠不要“復制粘貼”KPI
記住，組織的性質、文化和發展方向，對于選擇正確的KPI非常重要。最好的方法是從別人做什么和不做什么中學習，但千萬不要因為這對他們有用就復制他們。
5.要團隊相信KPI的重要性
你在決定什么樣的軟件開發KPI對的團隊很重要時，還需要確定優先級，并告訴團隊這對我們很重要。擁有錯誤的KPI比沒有KPI更糟糕。
三、行之有效的9個KPI
這些是我們看到的一些KPI，對于軟件開發團隊來說非常有效。（順序不表示重要性或有效性。）
1.團隊上手時間
新團隊成員開始為團隊交付做出有意義貢獻所需的時間。這有助于理解團隊的學習曲線有多大，也表明團隊在教育新成員有關團隊架構、技術堆棧和開發實踐方面的效率有多高。數字越小，表示學習曲線越小，新成員可以開始快速做出貢獻，從而影響團隊的整體生產力以及新成員的滿意度。
2.測試有效性
這可以通過幾個指標的組合來衡量，比如在非生產環境與生產環境中發現的bug的比率、在非產品環境中測試的用戶場景的百分比以及測試分支覆蓋率。此KPI的主要目的應該是確保團隊在投入使用之前測試更改的措施是有效的，并且生產缺陷的開銷不會降低團隊的速度。
3.有效開發
進行了多少代碼更改，并不重要，重要的是代碼的有效性。這里的有效性是是指，當團隊在添加新更改的同時不繼續添加代碼債務時，需要最少的返工。返工有時也反映出要求的不明確，或經常需要進行特別改進。跟蹤代碼有效性的另一個很好的衡量標準是，開發的代碼對客戶產生影響的百分比是多少。將此作為KPI進行跟蹤有助于樹立有效工作比更多工作更重要的觀念。
4.客戶滿意度
開發團隊的所有工作最終都會為用戶提供新的功能或更好的體驗。衡量最終用戶滿意度是一個很好的衡量標準，可以表明團隊是否以正確的心態工作。
跟蹤這一點的幾種方法可以是測量功能的使用頻率，也可以來自新功能發布后的反饋調查。根據產品類型和組織提供的客戶支持、客戶報告錯誤的頻率、客戶請求的交付速度等指標，在衡量滿意度方面也起著重要作用。
管理者可以通過查看特性請求的周期時間（從整理到生產部署）來跟蹤特性請求的速度。
另一個非常有效的指標是NPS（Net Promoter Score，凈促銷得分），它是一個最終用戶向其他人推薦產品的可能性的得分。通常可以使用客戶調查和反饋表跟蹤這一點。
5.周期時長（Cycle Time）
這是一種廣泛使用的KPI，是交付速度的明確指標。周期時長主要幫助了解團隊的敏捷性，以及管理者應該在哪些領域花費精力。例如，如果在登臺環境中進行測試所需的時間超過了開發項目，則意味著需要考慮如何優化或者自動化測試框架。
跟蹤周期時長的最佳方法是從開始（計劃）到實現（生產部署）。繪制開發過程全貌的周期時間示例如下：
從計劃部署到生產部署的真實工程周期
將周期時間作為KPI進行跟蹤有助于了解不同流程的效率。有時，不同階段的周期可能不能精確到分鐘，但比較視圖和不同流程之間的整體分割，可以幫助你優化正確的區域。
6.生產穩定性和可觀測性
沒有一個系統是完美的，軟件開發中的錯誤是不可避免的。我們需要接受這樣一個事實：即完善開發過程無濟于事。擁有適當的可觀測性機制，將影響降至最低，是解決這一問題的最佳方法。關注過程的速度和穩定性是關鍵（也是DORA度量思想的核心）。幫助了解穩定性的一些軟件開發KPI包括：
（1）CFR（更改失敗率）：導致生產缺陷的部署百分比，有助于了解團隊修復缺陷的開銷發生的頻率。
（2）MTTD（平均檢測時間）：在生產中識別缺陷所需的平均時間-這代表了監控和可觀察性機制的有效性。
（3）MTTR（平均恢復時間）：檢測到生產缺陷后修復生產缺陷所需的平均時間，表征著團隊找出并修復問題的速度，以最大限度地減少對最終用戶的影響。
7.團隊健康和滿意度
維珍創始人Richard Branson曾說：“照顧好你的員工，他們也會照顧好你。”后疫情時代，團隊成員都有待從倦怠中恢復，這比以往任何時候都更重要。確保團隊不會筋疲力盡，并對他們自身所做的工作感到滿意，這是擁有一個高效團隊的根本支柱。有助于跟蹤這一情況的一些指標包括：
（1）每個人都希望開發新功能和最新技術：如果你的團隊不斷致力于解決現有系統的bug和維護，勢必會引起團隊成員的不滿。
（2）開發經驗-測試系統的：行更改是否太難了？為開發人員配備快速測試更改或運行小型POC的工具和靈活性對于擁有一個更快樂的團隊至關重要。
（3）花在會議上的時間與實際工作的時間：軟件開發團隊經常面臨“會議疲勞”，他們在會議上花費的時間比工作效率高，這會導致倦怠和上下文切換，而這通常是可以避免的。了解團隊參加會議的次數或他們在會議上花費的時間百分比可以幫助了解團隊對會議的態度。
8.文件和知識共享
想要讓軟件開發團隊有效地工作，在整個團隊中廣泛地共享知識是必不可少的。它可以是代碼文檔、組件規范或設計文檔的形式。在很多情形中人們往往擔心團隊成員的外流。但問題在于，某個團隊成員要“活水”或跳槽到另一個團隊或組織，這都是時間長短的問題。零減員根本就是是不可能的。
所以，解決這一問題的最佳方法是減少團隊中的知識孤島，這樣即使團隊成員決定離開“演出”也可以繼續。涵蓋這一方面的工程KPI包括：
（1）記錄的代碼庫百分比。組件圖或API規范的更新頻率，是表示代碼/設計文檔實踐的幾個指標。
（2）新加入者理解系統所需的會議次數。大量的會議意味著沒有足夠的文檔作為新團隊成員的自助服務。
（3）只有一個團隊成員知道的代碼庫的百分比。（百分比越高=團隊中的知識庫越多）
9.任務規劃和可預測性
哪些任務需要完成，何時完成，以及誰來完成，這些都是計劃項目時需要回答的關鍵問題。并非所有團隊成員都必須參與決策，但是，團隊需要以可預見的方式為組織的發展而努力。以下是一些有效的KPI：
工作分解結構：項目管理完全基于你如何將任務分解為更易于管理的任務，這有助于明確需要做什么，并更好地估計可能需要的時間。
可預測性：這表示在一個時間范圍內完成的承諾工作的百分比。有很多事情可能會影響可預測性，比如臨時請求或生產錯誤。
WIP計數：可以同時處理幾件事情固然好，但同時處理太多事情是不可取的。通過查看開發團隊的這一點，可以了解規劃過程的健全性。
通過過程來選擇對您的團隊至關重要的正確軟件開發KPI可能會稍微耗時，但如果有正確的心態，從長遠來看，這是非常有用的。正確的績效指標，將在動蕩時期為你的工程團隊指引方向，并幫助確保朝著正確的方向前進。?
