衡量 | 約耳趣談軟體

1. 衡量的陷阱：Campbell’s Law#

Joel 以 Campbell’s Law 作為這篇文章的核心警告：

「任何量化社會指標越是被用於社會決策，就越會受到腐蝕壓力，也越容易扭曲和破壞它原本要衡量的社會過程。」

翻譯成軟體開發的語境：當你開始用某個指標來評估或獎懲工程師時，那個指標就會立刻失去它的意義。因為人們會開始針對指標本身進行最佳化，而非最佳化指標所代表的目標。

衡量不是壞事。用衡量結果來做自動化決策才是壞事。數字是用來輔助人類判斷的，不是用來取代人類判斷的。

這可能是最廣為人知的錯誤指標：

用修復 bug 的數量來衡量工程師的貢獻，會導致：

按功能數量計績效：

軟體開發之所以特別抗拒簡單的量化衡量，是因為它的本質特性：

產出是知識密集型的：程式碼的價值不在於它的數量，而在於它解決的問題與做出的設計決策
品質是多維度的：效能、可維護性、可讀性、安全性、可擴展性——這些維度之間經常存在取捨，無法用單一指標概括
影響是長期的：今天寫的一段看似簡單的程式碼，可能在三年後因為架構設計良好而為公司節省了數個月的開發時間——但這個貢獻在短期指標中完全不可見
最重要的貢獻往往不可見：mentoring 新人、提出關鍵的設計建議、在 code review 中阻止了一個嚴重的設計錯誤——這些都是極有價值但難以量化的貢獻

這不是說軟體開發完全無法衡量。而是說，對軟體開發的衡量需要更多的人類判斷，而非更多的自動化指標。

Joel 的建議是：衡量結果，而非產出。你不需要知道工程師寫了多少行程式碼，你需要知道產品是否變得更好、使用者是否更滿意、系統是否更穩定。

好的管理不是設計出一套完美的指標系統然後自動運行。好的管理需要：

一個思想實驗

想像兩位工程師：

如果只看數字，工程師 A 完勝。但如果深入了解：

這就是為什麼數字不能取代判斷。

Joel 並非反對所有形式的衡量。數字在以下場景中仍然有用：

一個好的經驗法則：如果一個指標會被用來決定某人的獎金或晉升，那它幾乎一定會被博弈。把指標當作「觀察窗」而非「裁判」——用它來發現需要關注的領域，然後用人類的判斷來做決策。

Joel 對衡量的忠告可以濃縮成一句話：好的管理需要判斷力，而判斷力不能被公式取代。

數字可以告訴你「發生了什麼」，但不能告訴你「為什麼」和「該怎麼辦」。當管理者試圖用指標來取代深入了解團隊的工作時，他們不是在提升效率——他們是在破壞團隊中最寶貴的東西：信任、自主性與內在動機。