Neal Ford — Atlanta, Georgia, USA

打破對開發者生產力的迷思#

初次接手軟體專案的專案經理，常帶著一個錯誤假設：「就算找不到頂尖人才，用普通開發者湊數也有一定幫助。」這個假設在軟體開發領域完全不成立。

研究數據顯示，優秀開發者的生產力遠超普通開發者，差距可達數個數量級（Orders of Magnitude）——也就是十倍、百倍的差距，而不只是「好一點點」。

軟體不是挖溝，基礎品質決定一切#

挖溝的工作裡，就算效率差的工人也能挖出一個洞。但軟體開發不同：

• 今天寫的程式碼是明天的地基
• 若基礎由平庸的開發者搭建，優秀的開發者必須先花大量時間修補缺陷，才能繼續前進
• 一個表現差的團隊成員，從團隊中移除往往比加入一個優秀的人更有效

核心觀念： 平庸的開發者不只是「貢獻較少」，他們還會拖慢其他人的速度（降低 Velocity），讓整體產出遠低於僅有少數優秀人才的團隊。

「加人」的反效果#

許多非技術背景的專案經理直觀地認為：專案落後就加人，就像多雇幾個搬運工能加快裝貨速度。這個類比在軟體開發中會適得其反。

根據 n(n-1)/2 公式，溝通渠道數量隨人員增加呈指數成長：

每增加一個成員，就需要花費時間讓他上手，同時也將其他人從工作中拉走。對一個已落後的專案加人，只會讓它更加落後。

常見陷阱： 許多企業軟體開發進展緩慢，根本原因正是這兩個迷思的疊加效應——既依賴平庸開發者，又在落後時不斷加人，結果雪上加霜。

正確的投資策略#

建議：

• 給優秀開發者強大的工具 — 這是提升品質和速度最直接的方式
• 不要為了「湊人頭」而招募 — 需要「保母」的差勁開發者，只會消耗優秀開發者的精力
• 捨得花錢招募和培養頂尖人才 — 無論短期還是長期維護，這都是最划算的投資

軟體太複雜，無法套用工廠裝配線的邏輯。開發者是工匠，不是工人。

補充： Velocity（速度）是敏捷開發中的常用術語，指團隊或個人在固定時間內能交付的工作量，用於衡量開發進度的節奏。