讀完這章你要能回答：一個專案的工時該怎麼拆？為什麼「人月」幾乎總是被低估？我手上這個季度真正能交付多少工程量？

估算不是猜數字，而是用可驗證的基準去推算。最常見的估算災難，來自一個錯誤的直覺：「寫程式碼是工作的主體」。實際上，編碼只佔整體工時的一小部分，測試與整合才是真正吃時間的地方。

排程拆分：編碼其實是少數#

一個成熟的軟體任務，時間分配大致如下：

注意：測試（元件測試 + 系統測試）合計約佔一半工時，卻是最常被低估的部分。當有人說「程式碼三天就寫完了」，真正的問題是：剩下測試與整合的那大半時間，排進去了嗎？

把這個拆分當成排程的「健康檢查」：如果你的計畫裡測試時間遠少於編碼時間，那它一定是樂觀偏誤的產物。

工時隨規模超線性增長#

工作量並非與規模線性成長。隨著系統變大，模組間的耦合、溝通與整合成本會讓總工時呈現超線性（superlinear）增長，一個常用的經驗近似為：

$$ \text{Effort} \approx k \times \text{Size}^{1.5} $$

其中 $\text{Size}$ 可以是程式碼行數、功能點或模組數量，$k$ 為團隊/領域相關的係數。

這條公式的實務意義：

• 規模翻倍，工時不只翻倍（$2^{1.5} \approx 2.83$ 倍）。
• 「把任務切小」之所以有效，正是因為避開了指數區間——小批次的單位成本更低。
• 大型專案若沿用小專案的線性外推來估算，幾乎注定爆量。

生產力基準：別用名目產能排程#

排程最危險的假設，是把每個人當成 100% 稼動、且全程在寫程式碼的機器。真實世界的折扣很大：

絕對不要規劃 100% 稼動。把名目產能直接填進排程，等於把所有不確定性都當成零。預留 ~20% 給清理與意外，是讓計畫「能被執行」而非「只能被展示」的關鍵。

實務上把這幾條串起來，就是一個可防呆的估算流程：

1. 用 $k \times \text{Size}^{1.5}$ 推出總工時的量級。
2. 套上排程拆分（記得測試佔一半），檢查各階段比例是否合理。
3. 用「每人每季 ~10 有效工程週、保留 20% 緩衝」換算成可承諾的交付範圍。

這套基準的好處，是把「拍腦袋的樂觀」換成「可以被質疑與校準的數字」。

本章要點#

1. 編碼不是主體：規劃 1/3、寫碼 1/6、測試合計約一半——測試最常被低估。
2. 工時超線性：$\text{Effort} \approx k \times \text{Size}^{1.5}$，規模翻倍工時更多，切小才划算。
3. 一天只有半天在寫碼：名目工時要先打對折。
4. 協調有代價：高協調團隊生產力可能降到 ~1/6，加人不等於加產能。
5. 高階語言是槓桿：用對抽象層級約有 5 倍效益。
6. 別排滿：以每人每季 ~10 有效工程週估算，並預留 ~20% 清理緩衝。