開發人員生產力－如何衡量

人類本質上是認知守財奴，我們傾向於以簡單且最省力的方式解決複雜的問題。這就是我們一直在透過採用最簡單的可用方法來衡量「開發人員生產力」的方法。

當您聽到「開發人員生產力」時第一個想到的是什麼？

我敢打賭這是負面的，毫無疑問這在開發團隊中幾乎是一個禁忌，因為領導者常常擔心談論這個問題會讓團隊認為他們受到微觀管理或缺乏信任。兩個原因：

1. 開發人員生產力的方式被工程領導者濫用，並且正如我們所說的。

2. 「開發人員生產力」不是一個公式，我們不會在不確定性中茁壯成長，因此我們選擇要麼走最簡單的道路，要麼遠離這條道路。

試想：每年在開發團隊上花費數十億美元，如果有萬能的方法來衡量開發人員的生產力，那它還會是個謎嗎？或者你會讀這篇部落格嗎？

PS：如果您閱讀此部落格的目的是衡量您最有生產力的開發人員或獲得一個有助於您晉升和解僱開發人員的數字，請轉身離開，因為您會感到失望。

那麼我們是否應該嘗試衡量開發人員的生產力？

是的，一點沒錯！ ！因為開發人員的生產力不僅在於提高工程成果，還在於確保團隊的滿意度和福祉。通常，生產力指標也有助於發現開發流程中的瓶頸以及團隊工作環境和文化的挑戰。

最成功的籃球教練之一菲爾傑克森(Phil Jackson) 精彩地闡述了這一點：

「團隊的力量在於每個成員。每個成員的力量就是團隊的力量。」 — 菲爾·傑克遜

在開發團隊的背景下，每個團隊的成功都取決於每個開發人員都發揮出最佳水平並不斷為團隊的成功做出貢獻。

好的，現在我該如何衡量開發人員的生產力？

兩個基本支柱可最大限度地提高衡量開發人員生產力的成功機會。

1. 永遠不要將生產力降低到單一指標

衡量開發人員的生產力很困難，因為我們試圖衡量參與邏輯和創造性任務的人。而我們身為認知守財奴，試圖將生產力降到一個指標──讓我明確指出，這種模式將會失敗。

相反，嘗試跨多個維度捕捉生產力並利用諸如SPACE 框架之類的東西（S-滿意度和幸福感，P-績效，A-活動，C-溝通和協作，E-效率和流程）可以幫助開發人員團隊以正確的方式衡量開發人員的生產力。

2. 與團隊溝通

有一個非常普遍的迷思：開發人員的生產力只適合管理者。這與事實相差甚遠。研究表明，開發人員和管理人員對開發人員生產力的看法存在顯著差異。大多數開發人員將更高的生產力與更高的活動聯繫起來，而大多數經理人將生產力與績效和效率聯繫起來。

只有當開發團隊就生產力對他們意味著什麼以及他們追蹤生產力的真正意圖是什麼時，這種看法之間的明顯差異才能消除。這有助於澄清為什麼這很重要以及我們應該如何衡量它，並且還消除了大多數開發團隊的保留。這是決定我們評價的數字嗎？或者我們這樣做是因為領導階層不相信我們能完成工作？

要做的事

1. 使用 SPACE 框架跨多個維度追蹤開發人員的生產力。
2. 與整個團隊溝通意圖。
3. 使用生產力衡量標準來確定需要改進的領域並消除瓶頸。

不該做的

1. 將生產力降低到單一指標。
2. 制定秘密措施來追蹤生產力。
3. 使用指標作為決定評估的唯一指標。

開發人員生產力指標

現在讓我們來看看一些跨空間維度追蹤的開發人員生產力指標。

開發人員生產力指標：

滿意度與幸福感

一個高度滿意的團隊就是一個高生產力的團隊。這是健康團隊和工作文化的最大指標之一。然而，滿意度是一個抽象的概念，如果有人問你“你有多滿意？”，就忘記衡量標準吧。我相信在回答這個問題之前您會思考幾分鐘，滿意對您意味著什麼以及如何量化這一點。我們知道用數字來捕捉這一方面是極為困難的。因此，您在這裡看到的是代理指標，它們試圖最好地捕捉開發人員滿意度和幸福感的不同方面。

• 工作完成： 每當我們完成一項任務時，我們的大腦就會釋放多巴胺，這使我們在任務完成後立即感到滿足和動力。因此，與承諾的工作相比，工作完成率較高將使開發人員感到非常滿意，因為他/她能夠及時完成承諾的工作並為團隊的成功做出貢獻。
• 加班： 加班≠更高的生產力；事實上，情況恰恰相反，加班是導致開發人員倦怠並損害他們福祉的最大因素之一。追蹤額外的工作時間，例如週末或深夜的工作時間，可以幫助您了解開發人員在當前的工作環境中是否快樂並表現良好。
  • 忙碌不是成就的手段，而是成就的障礙
    ——Alex Soojung-Kim Pang
    
• 脫離： 不滿和倦怠的最常見指標是脫離團隊和團隊活動。衡量開發人員敬業程度的方法之一是測量開發人員對團隊活動（如程式碼審查）的一般回應時間的變化，或團隊會議中互動或出席的減少。
• 開發人員調查： 通常，在確定最佳生產力指標時，我們會忘記最明顯的方法，即透過執行和分析開發人員滿意度調查來詢問您的團隊並了解團隊的情緒。問諸如「您滿意嗎？」之類的問題。 （評分1-5）」是理解這一點的最糟糕的方式。但是，可能還有其他問題可以幫助您以不同的方式和維度捕獲類似的信息。
• 任期： 跟踪整個團隊滿意度的好方法，您可以查看開發團隊中成員的平均任期。考慮到開發人員趨勢的性質，合適的任期範圍可以是12 至18 個月之間。任何更低的值肯定會引起人們的擔憂。

表現

衡量開發人員和開發團隊績效的最佳方法是衡量結果而不是輸出。這些指標幫助我們捕捉開發人員所做工作的品質方面。對於任何開發人員來說，理想的結果都是「開發返工最少的功能，確保及時交付和最大程度的客戶滿意度」。

• 返工： 當開發人員需要糾正其拉取請求或經常將任務從QA 返回給開發人員進行錯誤修復時，這清楚地表明所完成的工作品質未達到預期標準。如此反复，最終導致功能開發週期延長。這個想法並不是零修正，而且返工通常也是由於需求的變化而導致的；然而，如果一個開發人員在相同的團隊限制下面臨著比其他人異常高的問題，那麼這絕對是性能差距的跡象。
• 及時交付： 每個工程和業務領導者關心的一個結果是交付的可預測性，因為客戶溝通的許多其他業務決策通常依賴這些交付日期。為了在整個工程流程中具有可預測性，每個開發人員也吸收這種品質是絕對重要的。衡量這一點的一種方法是查看開發人員在開發衝刺/迭代中提交的任務完成了多少。
• 客戶滿意度： 一致認為，這是為任何組織帶來價值的最重要的結果，因此對於開發團隊來說也必須如此。客戶滿意度可能意味著應用程式商店獲得更好的評論，或者API 服務具有更高的正常運行時間和更快的回應時間，或者對於平台團隊來說，它可能意味著其他團隊使用的內部庫的易用性和報告的錯誤最少。儘管客戶滿意度不僅由工程團隊驅動，但將其作為績效指標可以使開發團隊與他們正在建立的產品的真實用戶保持聯繫，並幫助他們專注於正確的事情。

活動

#活動維度本身就廣泛等同於開發人員的生產力，因為它是最容易跟踪的維度。然而，僅憑活動永遠無法真正衡量開發人員的生產力。結合SDLC 流程不同領域的其他維度來追蹤活動指標將幫助您確定開發人員的真正瓶頸和需要改進的領域。

• 已解決的任務： 此階段的活動有助於確定開發人員對開發任務做出貢獻的頻率和程度。鑑於開發任務始終被規劃為專案管理工具上的任務、使用者故事或子任務，查看已解決的總任務有助於了解開發人員在開發週期的這一部分中的參與情況。
• 審查拉取請求： 通常只有技術主管或開發團隊的經理才有責任審查變更/拉取請求，這是一個明顯的反模式。鼓勵每個開發人員審查越來越多的同行程式碼有助於消除審查瓶頸。這個指標將是一個很好的方法來確定開發人員是否為團隊的審查負載做出了貢獻。
• 部署頻率： 團隊將變更部署到生產系統的次數可以幫助您了解開發流程的速度面向。這也是 DORA 指標之一，研究顯示 DORA 指標也與客戶滿意度甚至組織的獲利能力具有高度相關性，這使其成為追蹤開發團隊生產力活動維度的絕佳衡量標準。

溝通與協作

在任何開發團隊中，最終成果（無論是功能、服務、應用程式或增強功能）始終是團隊努力的結果。良好的溝通和協作是建立高效開發團隊的基礎。在衡量開發人員生產力時納入此維度可以促進透明度和資訊共享的文化。一些有助於捕捉這一點的生產力指標是：

• PR 等待時間和週期時間： 如果開發團隊具有良好的協作，則可以清楚地反映在他們的審核過程中，因為這可能是最瓶頸的開發過程，因為它取決於貢獻者與審核者的有效溝通，反之亦然。有助於追蹤開發人員協作程度的指標是測量該開發人員在分配拉取請求後開始審查拉取請求所需的時間。接下來，測量拉取請求的平均週期時間有助於了解貢獻者的溝通技巧。
• 共同工作的成員數量： 開發團隊通常存在知識孤島和開發人員小組，這些開發人員只相互交互，而不與團隊的其他成員交互；這是另一種經典的反模式。衡量開發人員與其他團隊成員的溝通程度和溝通程度是衡量此維度的好方法。
• 新成員的入職時間： 每當新開發人員加入團隊時，他們都會經歷初始學習曲線，了解業務環境，熟悉技術堆疊，通常還會獲得程式碼演練的協助。開發人員自加入以來做出第一個有影響力的變更所需的時間是衡量開發團隊溝通的重要生產力指標。作為一個擁有良好文件實踐的團隊，願意花精力幫助新加入者的開發人員將使新開發人員能夠盡快做出有影響力的更改。一個值得努力的良好基準是新開發人員的第一個生產成果是在前 30 天內。

效率和流程

這就是開發者經常談論的「進入流程」的維度。這裡的指標有助於了解開發週期中有多少中斷以及任務從開始到結束的流程有多順利。頻繁的中斷不僅會影響開發人員的工作效率，還會導致壓力和疲勞程度增加。

• 不間斷的開發時間： 對於開發人員來說，每天有足夠的不間斷的時間進入流程並投入時間進行開發活動絕對重要。其中最大的障礙就是團隊會議。通常，為了鼓勵更長的開發時間，團隊會採用不開會的工作日或採用可以安排團隊會議的嚴格時間段。較長的不間斷開發時間並不一定表示開發人員的生產力較高。然而，可以肯定的是，如果開發人員沒有足夠的不間斷時間，就無法實現開發所需的流程。
• 提交提前期： 開發週期中更多的中斷、更多的交接以及過於頻繁地重新開啟任務都是開發任務效率和流程不佳的指標。提交交付時間可以準確地捕捉到這一點，因為它衡量的是更改對最終用戶產生影響所需的總時間。相對較高的提交前置時間（CLT）肯定意味著開發團隊的效率和流程的下降。 CLT 也是 DORA 指標之一。更多相關資訊請參閱此處。
• 平均進行中 (WIP) 工單： 上下文切換無疑是生產力殺手。同時做更多的事情總是意味著需要更多的時間來完成所有事情，並且還會導致不必要的精神疲憊。
  • 兩個平行任務 — 20% 因上下文切換而遺失。
  • 三個平行任務 — 40% 因上下文切換而遺失。
  • — 傑拉爾德·M·溫伯格

#

WIP 票證完美地記錄了開發人員正在並行處理的任務數量。追蹤此生產力指標並嘗試使其始終小於三個任務對於您的開發團隊來說是一個很好的開始實踐。

變革參與

當您查看提高開發人員生產力的指標時，幫助您推動變革的行動將是開發流程的變化。衡量開發人員對團隊正在推動的變革的參與程度有助於了解每個人為糾正團隊流程所付出的努力。每個流程變更都可以有一個與之相關的指標，用於捕獲流程的遵循情況，並且追蹤這些指標的排行榜可以幫助您進行遊戲化並了解哪些開發人員對流程變更計劃做出了良好的貢獻。

這就是大家！

我們看到開發人員的生產力通常被誤解為單一指標或易於追蹤的指標，而不是實際重要的指標。我們追蹤開發人員的生產力並從 SPACE 等框架中汲取靈感，採取全面的方法來提高開發人員的生產力，這絕對至關重要。最好從幾個指標開始，但至少從三個維度選擇這些指標很重要。我們已經討論了詳盡的維度清單以及每個維度中的許多指標，現在您和您的團隊需要找出最有影響力的正確維度和正確指標。

以上是開發人員生產力－如何衡量的詳細內容。更多資訊請關注PHP中文網其他相關文章！