對於工程經理和首席技術官（CTO）來說，定義和衡量一個程序員的生產力是非常複雜的任務。這主要是因爲軟件開發的產出通常是無形的（比如代碼、算法等），與傳統的物理產品（比如汽車、電器等）不同，這使得生產力很難用傳統的衡量方式來量化。
在軟件行業中，定義和衡量程序員的生產力有點像追尋“白色巨鯨”，這是一個幾乎無法捉摸的目標。
儘管如此，這個問題仍然非常重要，因爲它關係到公司的投資決策和價值觀，也是開發者自己職業焦慮的一個重要來源：你怎麼知道你是否做得足夠多，無論是工作中還是工作外？當你所做的一切都是無形的，應該如何衡量它？它到底能否被衡量？
在這篇文章中，我們將討論生產力衡量的最大陷阱，以及幾種有效的衡量方式。
在軟件開發中，就像在任何其他領域一樣，很多人認爲生產力是輸入和輸出的問題。”輸入”包括全職開發者每週的工作時間和年均薪水，這些都是容易量化的。而”輸出”則包括開發者定期產生的軟件特性、文檔、部署以及修復漏洞等。人們可能認爲提高開發者的生產力就是簡單地增加他們的工作時間或提高他們的薪水。但現實遠比這複雜，開發者和軟件的運作方式並不是那麼直接或容易量化的，因此不能僅通過增加工作時間或薪水來簡單地提高生產力。
一、輸入衡量的問題
工作時間常常被默認地用作衡量工作績效的代理指標，這種方法通常是公司未經深思熟慮地默認採用的，因爲它簡單易行。然而，這樣的方法可能導致一個過於注重工時而不是實際工作成果的工作環境。
除了遠程工作成爲常態的疫情時期之外，僅限工作時間的環境的症狀很容易識別。在這樣的環境中，人們過於關注在辦公室度過多少時間，而不是關注完成了多少有質量的工作。嘗試提前幾個小時離開辦公室的員工可能會遭遇其他人的批評或懷疑，而那些經常加班或週末工作的員工則可能被視爲更有價值或更高效。這種以工時爲中心的文化有一個明顯的缺陷，那就是它鼓勵開發者把更多時間花在工作上，而不是關注他們實際完成了什麼工作。
長期下來，這種文化會導致一個大家都在忙於工作，但實際完成的工作卻很少的環境。這與提高員工或團隊生產力的目標是相悖的，因爲它不鼓勵有效、高質量的工作，而只是鼓勵長時間的工作。這樣的環境不僅無法準確地衡量或提升生產力，還可能導致員工過度勞累和士氣低落。
問題還不止於此。
如果我們簡單地認爲所有的工作都是積極有效的，那是錯誤的。開發者在身體或心理狀態不佳（比如疲憊、分心或生病）時所做的工作可能會是“負面工作”，即效果不佳到需要後續修正，這實際上會增加總體的工作量。軟件開發是一項複雜、抽象和需要高度專注的工作，因此受到開發者心理狀態的強烈影響。
不僅如此，除了明顯的輸入因素（如工作時間）之外，還有一系列隱藏的輸入因素（如焦慮、抑鬱、職業倦怠、有毒的工作文化等）也會影響生產力。如果公司文化過於嚴格，不允許有靈活的工作時間或休假安排，那麼開發者就很可能會做出負面工作。加班可能會導致他們完成的工作量反而比早點回家要少，而且由於疲勞，他們第二天的工作效率也可能會降低。這樣的環境不僅不會提高生產力，反而會產生負面效果。
另一方面，儘管使用工作時間作爲衡量標準是不理想的，並可能在多數情況下削弱生產力，但它至少在表面上具有一定程度的“公平性”。如果兩個開發者的工作時間相同，至少在這個方面，他們被視爲平等。也就是說，他們在時間投入方面都沒有偷懶，也沒有做超過他們應當做的工作。
這意味着，如果他們的生產力未達到預期，他們至少在時間上做了投入。與其他某些績效指標相比，“工作時間”這一指標並沒有明確地激勵人們去產出低質量的代碼。雖然以工作時間作爲唯一的衡量標準是一個不夠好的方法，而且在很多情況下甚至會削弱生產力，但還有更糟糕的指標值得我們討論。
考慮一下軟件開發的另一個明顯的輸入：金錢。
給人們更多的金錢並不會直接使他們更有生產力，儘管在某種程度上和在一定範圍內，更高的薪資可能會有助於提高生產力，但這種影響相對較弱。時間和金錢都是一種“輔助性”的輸入，與真正的生產力只有微弱的聯繫。換句話說，這些都是外部給予的東西（一個由僱主給出，另一個由員工給出），但它們與創造有用軟件的能力只是次要關聯的。
總結來說，依靠這些輸入指標來衡量生產力是不夠準確的。軟件開發不是一個可以用簡單方程式來描述的過程，也不是一種可以通過流水線方式來完成的工作。相比於過分關注輸入（如時間和金錢），更應該關注輸出，即實際完成的工作質量和量。
輸出衡量的陷阱
一些人錯誤地以代碼行數或者版本控制中的提交次數來衡量一個軟件開發者的生產力。然而，這些指標實際上並不能反映出軟件開發的真正價值或質量。代碼行數和提交次數更像是開發過程中的副產品，而不是最終結果。代碼的目標應該是解決實際問題，所以一個沒有解決問題的代碼行可能比根本沒有代碼還要糟糕。這就像用電廠產生的廢料量或國會通過的法案數量來衡量其實際價值，這些指標與實際價值只是有一定的關聯，但並不是直接反映價值。
其次，這些指標很容易被操縱。例如，如果一個開發者的薪酬與他們寫的代碼行數掛鉤，那麼他們可能會在很短的時間內寫出大量無用或冗餘的代碼，從而賺取更多的錢，而這對實際的項目或企業並沒有任何價值。
“當一個衡量標準變成目標，它就不再是一個好的衡量標準。” ——古德哈特定律
儘管許多開發者明白這一點，但令人尷尬的是，代碼提交和代碼行數仍然被用作一種顯示能力的“孔雀羽毛”。例如，當人們聽說谷歌有超過二十億行代碼，或者Windows團隊每天有超過8400次代碼推送時，他們可能會覺得非常震驚，即使這些數字並不是使這些產品有價值的原因。
無論如何，我們可以把這些指標加入到無效指標的列表中。即使一些看似更合理的指標（比如修復的錯誤數、完成的任務或發佈的新功能）也可能導致不良行爲或不希望出現的結果。如果以修復錯誤數量作爲目標，開發者可能故意編寫有問題的軟件，然後再修復它，以達到高的“生產力”水平。如果目標是發佈更多的新功能，開發者可能會急於完成任務，從而編寫出質量較低、性能差的軟件。如果目標是完成更多的任務，這可能導致團隊成員之間的競爭，大家都可能去爭取那些相對容易或被高估的任務，而不是真正對項目有價值的任務。即使在最好的團隊中，這些糟糕的測量標準也會成爲一個難以忽視的障礙，影響團隊的整體表現和產出。
一些組織出於極度的偏執，爲了監控員工生產力而在員工的電腦上安裝間諜軟件。這種軟件可以跟蹤員工的每一個動作，包括鼠標移動、鍵盤敲擊和屏幕截圖。在這種高度審查的環境下，很難想象員工如何能夠進行有創造性的工作。這種做法的最大失敗在於它不能準確地衡量對企業或其客戶真正有意義的事情。
舉例來說，如果一個很有生產力的開發者在Reddit上花費了大量時間，或者他們的鼠標移動不是很活躍，是否應該因此對他們進行懲罰？或者，如果一個開發者在編程工具（比如Visual Studio）中輸入了很多文字，但人際交往能力很差，是否應該提拔他們？有些經理可能會根據這些表面指標來作出決策，但希望大多數人會有更高的判斷力，不會因爲這些淺層次的數據而做出錯誤的決策。
如何正確地衡量生產力
現在你已經瞭解了一些最糟糕的可能用於衡量生產力的指標，讓我們討論一些好的指標。個人績效很難用具體指標來衡量，通常只能二分地表示某個團隊成員是否有貢獻。而且，遠程衡量個人績效更加複雜。
軟件開發團隊的工作不是由一羣孤立的個體獨自完成的，而是由團隊中每個成員的工作產出相互依賴和相互影響的結果。個體成員的工作互動和貢獻之間存在複雜的相互依賴關係，而這些細微的差異和互動通常難以由外部觀察者準確衡量。
舉例來說，有些團隊成員可能在個人工作量方面不是很高，但他們對團隊的影響是積極的，因爲他們的幫助和影響使得其他團隊成員更加高效。這些個體對於高效的工程團隊來說是一種祕密武器，但他們的生產力很難用個體層面的指標來衡量。另一些團隊成員可能不會頻繁地發佈新功能，但他們在代碼的維護、測試和重構方面發揮作用，以幫助團隊成員更快速、更順暢地開發功能。同樣，他們的個體績效也難以量化，但他們對整個團隊生產力的貢獻是巨大的。即使對於那些經常發佈新功能的程序員來說，他們的個體生產力也會在短期內有所波動，這使得嘗試用具體的指標來追蹤生產力變得困難。
因此，最好讓個人貢獻者自行和互相衡量他們的個人績效。
團隊的績效要比個人績效更容易觀察和衡量。最有效地跟蹤團隊績效的方法可能是詢問：這個團隊是否能夠在幾周到幾個月的時間內連續交付有用的軟件？這與敏捷開發原則中的第三項原則相一致：“經常性地交付工作的軟件，時間跨度從幾周到幾個月，更短的時間跨度更佳。”一個能夠定期交付有用軟件的團隊被認爲是高效的。而不能做到這一點的團隊應該被追問爲什麼無法如此做。通常情況下，團隊缺乏生產力背後都有合理的原因；大多數生產力低下的團隊都渴望提高生產力，而大多數高效的團隊也渴望進一步提高他們的績效。
團隊生產力可以相對容易地在組織層面進行觀察和衡量。因爲團隊成員通常非常瞭解彼此的貢獻，無論這些貢獻是否可以用具體數據來衡量，所以任何個人生產力方面的嚴重不足都可以通過良好的組織習慣來發現。這包括經理和直接下屬之間經常進行一對一的面談，定期收集匿名的誠實反饋，以及鼓勵每個團隊成員積極報告他們的成就並對他們的失敗負責。
在軟件開發領域，人的因素比趨勢圖和原始數據更爲重要。軟件開發更依賴於人際關係和溝通，而且應該注重培養積極的工作文化。當責任心和健康的溝通融入工作文化時，可以更容易地發現影響生產力的關鍵問題，並由最有能力解決這些問題的人來處理。
速度通常被許多組織用作衡量團隊生產力的首選指標。速度是一個綜合度量，衡量團隊隨時間完成任務的能力，通常考慮到開發者對每個任務相對複雜性的估算。它可以回答類似於“這個團隊在接下來的兩週內可以完成多少工作？”這樣的問題。速度主要用於規劃工作，而不是用於回顧性評估，因此，任何試圖將激勵機制與速度關聯的人都會發現，在受到壓力時，速度的準確性會受到影響。瞭解團隊、部門或公司的速度對於優先考慮功能開發、與客戶設定期望以及規劃產品未來非常重要。
在衡量團隊生產力時，沒有比“任務乘以複雜性”更具有用處的度量標準。一些工具嘗試通過測量提交、代碼行數或編碼所花費的時間來進行衡量，但這些度量在團隊規模上並不比在個人規模上更具有實際意義。團隊完成的代碼工件數量或他們在這些工件上花費的時間與他們的貢獻價值之間根本沒有直接關係。
許多組織在沒有明確的硬性度量的情況下也可以取得成功。在這些組織中，他們深刻理解有用的軟件是他們的最終目標，同時也是開發工作的主要結果，雖然這很難用具體數字來衡量。在這種情況下，開發人員有更大的自由度，可以在他們感到最富生產力的時間和地點發揮他們的最佳能力。工作時間可能不一定遵循傳統的9點到5點，有些人可能更喜歡在早晨或深夜工作，而其他人可能會分散工作時間，這種靈活性被視爲一種優勢而非問題。這種方法強調了真正的生產力，而不是試圖通過可觀察的啓發式規則來加以限制，同時也使得更廣泛的人才，包括有孩子的家長和殘疾人，可以更容易地參與職場。關於結果導向工作環境（ROWE）、遠程工作、減少開會時間和彈性工作時間的好處已經有很多文章和言論，這些都只是明智的生產力措施的體現。
衡量的選擇會影響你最終獲得的結果。因此，你應該只衡量那些你真正、真正關心的事情，無論它們是否可以用圖表或數字來表示。對於一些人來說，處理那些無法用數字表示的工作可能會感到沮喪。然而，在像軟件開發這樣具有微妙和抽象性質的工作中，如果我們過於深陷於細節，就會適得其反，不符合我們的目標，即創造有用的軟件。因此，我們應該專注於真正重要的事情，而不是試圖通過數字或圖表來衡量一切。
國內比較主流的2款研發績效度量工具盤點
1.PingCode
覆蓋研發管理全生命週期，研發效能上滿足：企業研發效能評估、研發團隊效能度量、項目交付數據分析、個人效能指標統計等場景的需求。具備自動採集研發全生命週期數據、效能度量指標體系（比如交付質量、交付效率、交付能力，流程上覆蓋了需求、開發、CI/CD、測試、發佈）、自定義的數據分析報表、建立效能度量分析模型。（官網：PingCode）
2.思碼逸
爲研發團隊提供了研發數據彙總分析的一站式入口，度量指標包括效率、質量及人才三方面，從高管、團隊Leader、項目/產品經理、開發者等視角，幫助研發團隊各角色成員客觀、全面地洞察研發流程及成果。（官網：https://www.merico.cn/ ）
以上就是關於如何衡量研發部門績效的陷阱、方法、工具的討論，希望對大家有所啓發。
常見問答（FAQ）
爲什麼傳統的生產力指標在衡量研發人員生產力時可能不適用？
答：傳統的生產力指標，如任務完成速度或產出量，通常不適用于衡量研發人員的生產力，主要有以下幾個原因：創造性和複雜性：研發工作通常涉及高度的創造性和複雜性，這些因素難以用簡單的數字或速度來衡量。質量與數量的權衡：在研發中，質量通常比數量更重要。快速完成任務但犧牲了代碼質量或項目可維護性是不可取的。長期影響：研發項目通常有長期的影響，而傳統的生產力指標往往只關注短期成果。
如何平衡個體和團隊生產力的衡量？
答：在衡量研發人員生產力時，個體和團隊兩者都是重要的。以下是一些平衡兩者的方法：個體目標與團隊目標的對齊：確保個體目標與團隊和組織的長期目標一致。團隊合作的考覈：除了個人的技術能力，團隊合作和溝通能力也應納入考覈範圍。集體責任和個人責任：在項目失敗或成功時，應識別是團隊整體的問題還是個別成員的問題，並據此進行評估。
如何避免衡量生產力的過程導致的不良影響？
答：衡量生產力的過程有時可能導致不良影響，如過度競爭或壓力。以下是一些避免這些問題的建議：透明和公平：確保衡量標準和過程對所有人都是透明和公平的。持續反饋和調整：不應僅在年終或項目結束時進行評估，而應提供持續的反饋和機會進行調整。避免單一指標：依賴單一指標可能導致員工“玩弄”系統以提高自己的評分。應使用多維度的評估方法。