每日分享最新，最流行的軟件開發(fā)知識與最新行業(yè)趨勢，希望大家能夠一鍵三連，多多支持，跪求關注，點贊，留言。

軟件開發(fā) KPI 就像工程團隊的指導信標。知道找出它們的最佳方法，以及九個這樣的 KPI 創(chuàng)造了奇跡。

為什么軟件開發(fā) KPI 很重要？

對于任何領域的成功和高效的團隊來說，最重要的是“方向”。并且其中沒有絕對的“對”或“錯”。這都是一個相對的和上下文的概念。軟件開發(fā) KPI（關鍵績效指標）充當“北極星”，使團隊朝著正確的方向前進。

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

衡量正確的工程 KPI 有助于確保您擁有一支高績效和高效的工程團隊，這是真正的競爭優(yōu)勢。“高性能”和“高效”的定義因業(yè)務性質和許多其他因素而異。弄清楚這些 KPI 可以幫助您將重要與噪音區(qū)分開來。在本文中，我們將討論您應該如何為您的團隊選擇 KPI，并列出曾為其他工程團隊工作的前 9 個軟件開發(fā) KPI。

如何以及如何不選擇 KPI

1. 始終考慮團隊效率，而不是開發(fā)人員的生產(chǎn)力

軟件開發(fā)本質上是一個團隊概念，從長遠來看，選擇在個人層面跟蹤的 KPI 永遠不會奏效。

2. KPI 不應該是量化的

它應該更多地關注您工作的質量方面。跟蹤“提交計數(shù)”不能成為 KPI，但“客戶滿意度”是團隊輸出質量的指標，是一個很好的候選。

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

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

4. 永遠不要“復制粘貼” KPI，即使是本文中的 KPI

請記住，組織的性質、文化和發(fā)展方向對于選擇正確的 KPI 非常重要。最好的方法是從別人做什么和不做什么學習，但永遠不要僅僅因為它對他們有用而復制它們。

5. 不要跟蹤你的團隊不相信的 KPI

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

6.從小處著手

您不能一開始就說這 25 個工程 KPI 對我們很重要。從本質上講，它認為一切都很重要，這不可能是真的?；〞r間弄清楚什么是重要的是可以的，但不這樣做會削弱這些 KPI 的價值。

9 個有效的軟件開發(fā) KPI

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

1. 團隊入職時間

新團隊成員開始為團隊的交付做出有意義的貢獻所需的時間。這有助于了解該團隊的學習曲線有多大，也表明該團隊在向新成員介紹團隊的架構、技術堆棧和開發(fā)實踐方面的效率如何。較低的數(shù)字表示較小的學習曲線，新成員可以開始快速做出貢獻，從而影響團隊的整體生產(chǎn)力以及新團隊成員的滿意度。

2. 測試有效性

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

3. 有效發(fā)展

修改了多少代碼并不重要——重要的是代碼的有效性。有效性是需要最少的返工并且團隊在添加新更改時不會繼續(xù)添加代碼債務。返工有時也表明要求不明確或經(jīng)常進行臨時增強。跟蹤代碼有效性的另一個好方法是開發(fā)的代碼中有多少百分比對您的客戶產(chǎn)生了影響。將此作為 KPI 進行跟蹤有助于樹立有效工作比更多工作更有價值的觀念。

4. 客戶滿意度

工程團隊完成的所有工作最終都會為最終用戶提供新功能或更好的體驗。衡量最終用戶的滿意度成為一個很好的衡量標準，可以表明您的工程團隊是否以正確的心態(tài)工作。跟蹤這一點的一些方法可以是測量功能的使用頻率，也可以來自新功能發(fā)布后的反饋調查。根據(jù)您的產(chǎn)品類型和您的組織提供的客戶支持，客戶報告錯誤的頻率和交付客戶請求的速度等指標在衡量滿意度方面也起著重要作用。您可以通過查看其周期時間（從梳理到生產(chǎn)部署）來跟蹤功能請求的速度。另一個非常有效的指標是 NPS（凈推薦值），它是最終用戶向其他人推薦您的產(chǎn)品的可能性的分數(shù)。這是使用客戶調查和反饋表進行跟蹤的。

5. 周期時間

廣泛使用且正確的軟件開發(fā) KPI，因為它是交付速度的明確指標。周期時間主要幫助您了解團隊的敏捷性以及您花費大部分時間的領域。例如，如果在暫存環(huán)境中進行測試所花費的時間超過了開發(fā)項目，則它暗示您要自動化/優(yōu)化您的測試框架。

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

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

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

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

1. CFR — 變更失敗率— 導致生產(chǎn)缺陷的部署百分比，可幫助您了解您的團隊發(fā)生修復缺陷開銷的頻率。
2. MTTD – 平均檢測時間– 在生產(chǎn)中識別缺陷所需的平均時間 – 這代表了您的監(jiān)控和可觀察性機制的有效性。
3. MTTR — 平均恢復時間 — 檢測到生產(chǎn)缺陷后修復生產(chǎn)缺陷所需的平均時間 — 傳達您的團隊找出和解決問題以盡量減少對最終用戶的影響的速度。

7. 團隊健康和滿意度

理查德布蘭森說：“照顧好你的員工，他們就會照顧好你的客戶?！?由于每個人仍在從大流行后的倦怠中恢復過來，這比以往任何時候都更加重要。確保團隊不會精疲力盡并對他們正在做的工作類型感到滿意，這是擁有高效和富有成效的團隊的基本支柱。一些有助于跟蹤這一點的指標是：

1. 每個人都想致力于開發(fā)新功能和最新技術。如果你的團隊不斷致力于解決現(xiàn)有系統(tǒng)的 bug 和維護，勢必會引起團隊成員的不滿。
2. 開發(fā)經(jīng)驗——測試對系統(tǒng)的一行更改是否太難了？為開發(fā)人員配備工具和靈活性以快速測試更改或運行小型 POC 對于擁有更快樂的團隊至關重要。
3. 花在會議上的時間與實際工作——軟件開發(fā)團隊經(jīng)常面臨“會議疲勞”，他們在會議上花費的時間多于高效工作，這導致了通?？梢员苊獾木氲『蜕舷挛那袚Q。了解團隊參加了多少次會議或他們在會議上花費的時間百分比可以幫助您了解團隊對會議的看法。

8. 文檔和知識共享

為了使任何軟件開發(fā)團隊有效地工作，必須在整個團隊中廣泛共享知識。它可以是代碼文檔或組件規(guī)范或設計文檔的形式。在當前情況下，問題不是“是否”團隊成員要切換到不同的團隊或組織，而是“何時”的問題——0% 的人員流失是不可能的時期。解決這個問題的最佳方法是減少團隊內(nèi)部的知識孤島，這樣即使團隊成員決定離開，“演出也可以繼續(xù)”。涵蓋這方面的工程 KPI 包括：

1. 已記錄的代碼庫的百分比。組件圖或 API 規(guī)范的更新頻率可能是表示代碼/設計文檔實踐的幾個指標。
2. 新加入者了解系統(tǒng)所需的會議次數(shù)。大量會議意味著沒有足夠的文檔作為新團隊成員的自助服務。
3. 只有一名團隊成員知道的代碼庫百分比。（更高的百分比 = 團隊內(nèi)更多的知識孤島）。

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

需要完成哪些任務、何時完成以及由誰來完成——這些都是在規(guī)劃項目時需要回答的關鍵問題。不一定所有團隊成員都參與做出此決定，但是，團隊需要以可預測的方式工作以促進組織的發(fā)展。以下是一些有效的 KPI：

1. 工作分解結構——項目管理完全基于你將任務分解為更易于管理的任務的程度——這有助于明確需要完成的工作并更好地估計可能花費的時間。
2. 可預測性——這表明在一個時間范圍內(nèi)完成了承諾工作的百分比。諸如臨時請求或生產(chǎn)錯誤等多種因素可能會影響可預測性。
3. WIP 計數(shù)——一起處理多件事情是最佳的，但一起處理太多事情是不可取的。通過查看開發(fā)團隊，您可以了解規(guī)劃過程的合理性。

要避免的 4 個危險的軟件工程 KPI

您應該不惜一切代價盡量避免這四個指標。它們往往對您的開發(fā)團隊弊大于利。

1. 積極編碼日

該指標絕不代表個人所做工作的質量。每個人的工作模式可能不同——有些人可能需要三天時間來理解一個需求并從邏輯上規(guī)劃出究竟需要做什么，然后在一天內(nèi)完成實際任務。假設每個團隊成員都應該每天編碼是一個毫無根據(jù)的假設。團隊還有許多其他事情，例如審查、設計、測試、發(fā)布、規(guī)劃、修飾和幫助初級團隊成員等。作為 KPI 跟蹤編碼天數(shù)會使所有這些其他功能變得無用。而不是你想要在一個高績效團隊中吸收的正確文化。

2. 代碼行

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

3.沖刺速度

另一個非常常被濫用的指標是速度。速度可以很好地指示完成了多少計劃任務，也有助于未來的沖刺計劃。但絕不是團隊生產(chǎn)力或有效性的指標。當 Velocity 被用來推動開發(fā)人員和比較團隊時，它就變成了一個危險的 KPI。即使在同一個組織中的兩個團隊也可以有非常不同的估計標準，并且作為團隊生產(chǎn)力的 KPI 進行跟蹤為系統(tǒng)博弈打開了大門。將速度作為 KPI 進行跟蹤通常會導致團隊為更好的 KPI 而工作而不是更好的工作。

4. 將開發(fā)人員相互堆疊

將軟件開發(fā) KPI 與以“開發(fā)人員生產(chǎn)力”名義跟蹤個人的指標混淆是很常見的。工程 KPI 應該代表團隊或項目的整體狀態(tài)，而不是個人。最重要的是，將一個開發(fā)人員與另一個開發(fā)人員進行比較是提高團隊生產(chǎn)力所能做的最糟糕的事情。您的團隊必須使用這些 KPI 為提高工程生產(chǎn)力做出貢獻，并且不要感到受到它們的威脅。

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