人月神話（二）：人月就是個謊言

前言

這篇作者直接開門見山說：缺乏合理的時間進度，是造成專案延遲最主要的原因，比其他所有因素加起來的影響還大。

但這問題會一直發生吧？專案估算過度樂觀時常不是真正的樂觀，而是因為中途發現需求與原先預估的有差異。就有點像是大家以為原先的道路是正確的，但走了一段才發現是死路，這時候只能回頭重走，但回頭重走的時間成本往往會被忽略。

應該說怎麼可能會預估得到會走錯路？

針對這個問題，作者點出了一個關鍵心態，正是這個心態讓我們容易忽略掉那些潛在的錯路。

工程師的通病：過度樂觀

作者很直白的說：所有的程式設計師都是樂觀主義者。

我們總相信這次一定會順利、我剛剛修完最後一個 Bug 了、應該差不多了、可以上線了之類的鬼話。

就像人生十大錯覺一樣

結果呢？Bug 總是會用各種你想像不到的方式再冒出來。或者這個流程一定沒問題，結果使用者一看發現不太對勁。

這種樂觀，來自於我們工作的介質太容易駕馭了。寫程式不像蓋房子要搬木頭、不像雕刻要跟石頭對抗。我們只需要鍵盤和螢幕，想法就能直接變成程式碼。這種純思考的創作方式，讓我們以為一切都在掌控之中。

但問題在於：我們的思考本身是有缺陷的。所以 Bug 永遠會存在，而我們的樂觀，往往只是錯覺。

難怪我永遠都會把 ticket 的點數少估

人月：一個危險的神話

這章最核心的概念就是：人月（Man-Month）是一個危險且具有欺騙性的單位。

它暗示著人力和時間可以互換——需要 12 人月的工作，可以讓 3 個人做 4 個月，也可以讓 12 個人做 1 個月。

會相信這種道理代表你也相信 10 個孕婦一個月就能生一個小孩ＸＤ

作者提了幾種情況：

1. 完全可分割的任務：像收割麥子，加人確實能縮短時間。
2. 無法分割的任務：無論多少個媽媽，懷孕都需要十個月。很多軟體開發的流程，特別是測試和除錯，就是這種性質。
3. 需要溝通的可分割任務：這是最常見的情況。加人確實能分擔工作，但溝通成本會隨之增加。人越多，溝通成本越高，效益會打折扣。
4. 關係錯綜複雜的任務：溝通成本可能會完全抵消分工帶來的好處，甚至讓情況變得更糟。

如果每個人都要跟其他所有人溝通，工作量會按照 n(n-1)/2 遞增。

三個人的溝通量是兩個人的三倍，四個人是六倍。這還沒算上開會，沒有算上那個人可能是個溝通能力極低的人。

系統測試：最容易被低估的環節

作者提供了一個他的經驗法則：

• 1/3 用於計畫
• 1/6 用於寫程式
• 1/4 用於元件測試與早期系統測試
• 1/4 用於系統測試

測試加起來佔了一半的時間，而寫 Code 只佔 1/6。

現實中，大多數專案都低估了測試所需的時間。結果呢？延遲往往發生在專案的尾聲，這時候人力成本已經到頂、客戶已經在等、其他依賴你產品的商業活動也都卡住了。這種「末期爆炸」的代價，遠比預期延遲的成本高太多了。

專案救火越救越大

這章的結尾，作者丟出了那句著名的法則：

Adding manpower to a late software project makes it later.
向進度落後的專案增加人手，只會使進度更加落後。

這聽起來很反直覺，但原因其實很簡單：

1. 新人需要培訓：這會消耗原有成員的時間。
2. 任務需要重新分配：已經完成的工作可能會被打亂。
3. 溝通成本增加：人越多，協調越複雜。
4. 系統測試需要延長：因為整體情況變得更複雜了。

所以，當專案落後的時候，最糟糕的反應其實是加人。這就像用汽油滅火，只會讓火越燒越大。

結語

這一章讀完，有種被醍醐灌頂的感覺。

我們常常在專案延遲的時候，第一個念頭就是「找更多人來幫忙」。但作者告訴我們，這通常只會讓事情更糟。真正該做的，是重新評估時程、縮減範圍、或是坦然接受延遲。

人月，終究只是一個神話。我們不應該被這個看似合理的單位所欺騙。所以到底怎樣是好的估算？

在這章還沒有答案，就繼續看下去吧！