1. 績效獎金在軟體業的根本問題#

在許多行業中，績效獎金（Incentive Pay）被視為理所當然的激勵手段。然而 Joel 認為，在軟體開發領域，這種做法不僅無效，還可能造成嚴重的副作用。問題的根源在於：軟體開發的產出極難客觀衡量。

• 用程式碼行數衡量？工程師會寫出冗長的程式碼
• 用修復 bug 的數量衡量？工程師會刻意製造 bug 再修復
• 用完成功能的數量衡量？工程師會挑簡單的功能做，迴避困難但重要的工作
• 用客戶滿意度衡量？工程師會只做使用者看得到的表面功夫，忽略架構品質

任何可量化的指標，一旦被用來決定獎金，就會立刻被「最佳化」——但被最佳化的是指標本身，而非你真正想改善的事情。這就是 Goodhart’s Law 的體現：「當一個指標變成目標，它就不再是好的指標。」

2. 內在動機 vs. 外在獎勵#

心理學研究持續顯示，對於需要創造力與複雜思考的工作，外在獎勵（金錢、獎品）不僅效果有限，甚至會削弱內在動機：

2.1 內在動機的力量#

真正驅動優秀工程師的因素包括：

• 自主性（Autonomy）：對自己的工作方式與技術選擇有掌控感
• 精通感（Mastery）：持續學習與成長，解決越來越難的問題
• 目的感（Purpose）：知道自己的工作對使用者或世界有意義
• 工藝榮耀感：寫出優雅、高效、可維護的程式碼本身就是獎勵

2.2 外在獎勵如何破壞內在動機#

當你開始用金錢獎勵原本就有內在動力的行為時，會發生一個微妙的心理轉變：

• 工程師開始把工作視為「為了獎金而做」，而非「因為有趣而做」
• 一旦獎金消失或不如預期，動力會急劇下降——甚至低於從未有過獎金時的水準
• 原本出於專業自豪感的行為（如主動重構、寫文件、幫助同事），因為「沒有獎金」而被放棄

這不代表金錢不重要。工程師當然需要合理的薪資。但合理的薪資與績效獎金是完全不同的概念。前者是基本尊重，後者是試圖用金錢操控行為。

3. 績效獎金對團隊合作的毒害#

軟體開發本質上是團隊活動。當績效獎金與個人表現掛鉤時，會產生一系列破壞團隊合作的效應：

• 知識囤積：如果幫助同事不算在自己的績效裡，為什麼要花時間教人？
• 搶功諉過：成功的專案人人搶功，失敗的專案互相推責
• 內部競爭：同事變成競爭對手，而非合作夥伴
• 迴避困難工作：高風險、高價值但不確定能成功的專案沒人願意碰
• 短視近利：為了本季的獎金數字，犧牲長期的程式碼品質與架構健康

4. 更好的替代方案#

Joel 建議，與其用績效獎金來「激勵」工程師，不如專注在創造一個讓人自然想做好工作的環境：

4.1 給予合理且有競爭力的薪資#

• 薪資應該反映市場水準與個人能力，而非綁定到特定績效指標
• 一旦薪資到位，金錢就不再是日常工作的驅動力
• 薪資審核應該基於整體貢獻與成長，而非短期數字

4.2 打造優質的工作環境#

• 安靜的辦公空間，讓工程師能進入心流狀態
• 好的工具與硬體設備
• 合理的工作時數，避免長期加班
• 信任與自主權

4.3 建立有意義的工作文化#

• 讓工程師了解產品對使用者的影響
• 鼓勵技術分享與學習
• 表揚那些難以量化但對團隊極為重要的貢獻（如 mentoring、知識分享、主動改善流程）

最好的激勵不是胡蘿蔔加大棒，而是讓人覺得自己的工作有意義、自己被信任、自己正在成長。當這些條件到位時，優秀的工程師會自然地發揮出最好的表現——不需要任何獎金制度。

5. 總結：付好薪水，然後忘掉錢這件事#

Joel 的建議精煉成一句話就是：付給工程師足夠好的薪水，讓他們不需要擔心錢，然後把精力放在創造一個讓他們能做出最好工作的環境。

績效獎金看似是一個簡單、「科學」的管理工具，但它忽略了軟體開發的複雜本質與人類動機的微妙之處。真正的管理智慧不在於設計精巧的獎金公式，而在於理解什麼讓好的工程師想留下來、想做好工作。