人月神話讀後筆記：軟體專案管理不可不慎的經典啟示

為什麼「人月」是軟體專案最危險的迷思？

1. 開發一個軟體系統產品要付出的代價是一般組件程式的九倍。因為產品化是一般組件程式的三倍時間，設計整合測試又是三倍時間，這兩方面的成本計算基本上是獨立的。
2. 以成本會計為基礎的時程預估方式，使我們誤把工作量和專案進度混為一談，人月是一個危險並容易遭到誤解的迷思，因為它假設人力和工時可以互換。

在這本書裡提到，專案管理人員不應該把人/月這樣的標準拿來做為專案規劃的依據，因為當人員多起來後，整個專案的運行會需要花更多的時間在溝通、管理、協調上，人月之間的關係並非線性關係。

並且勿忽略掉新的程式師要學習上手的開發時間，以及要耗費掉的老手的教育時間。因此，在一個已經延遲的專案中增加人手，只會讓它更加落後（這就是著名的 Brooks 法則）。比較建議的方式是重新安排時程、或者刪減工作。

書中也提出了建議的專案軟體時程安排比例：

什麼是「整體概念性」？外科手術團隊如何運作？

從第三章到第七章，都在討論保有『整體概念性』（Conceptual Integrity）的重要。

一個專案的規劃必需出於同一人之手，也就是說，一個專案不應該有兩個領導者。我們必須選出一個能力強的人，來帶領整個專案的開發及方向；我們寧可忽略掉一些可能新奇、或很棒的想法，也必須讓整個專案都能呈現同一個設計理念。此一概念便是這本書一直提及的整體概念性。

在第三章裡，書中提出了一個「外科手術團隊」的做法，來解釋該如何達到整體概念性的目的：

1. 首席程式設計師：整體概念性裡做決策的主腦，負責定義功能、設計程式、測試程式並撰寫文件。（書中也提到，真正優秀的專案管理人員，也應該要寫程式——沒有真正去撰寫程式的 PM，是無法做好專案管理工作的。）
2. 副手：外科醫生的分身，可以做所有首席設計師所做的事、或提出想法，但首席設計師不一定要接納他的想法。
3. 行政助理：幫忙處理首席程式設計師的所有庶務，一位行政助理可同時處理兩個以上團隊的工作。
4. 文件撰寫人員、秘書（負責專案協調事宜及與產品無關的文件）、程式助理、測試員、語言專家、工具專家。

什麼是第二系統效應？為什麼最容易失敗的是第二個專案？

第五章提到了第二系統效應（Second-System Effect）：最容易失敗的專案，反而常是我們第二個設計的系統，原因是加入了太多不相關的功能。第一次成功帶來的自信，會讓設計者在第二個系統裡過度設計。我們要慎防在設計第二個系統時過度設計，靠自律來節制。

團隊之間該如何溝通與傳達設計意念？

第六章在說意念的傳達——設計必須出於同一人之手，哪些有規範、哪些沒有，應定義清楚。書中列出的溝通方式包括：

• 將定義（規格書裡的定義）直接融入實作
• 開會：分為每週召開的會議和公開大會，討論重大議題及無法預見的瑣碎事項
• 多重實作：當規格與程式衝突時，兩方都有可能要更改
• 電話紀錄（現在可用 email）
• 產品測試：專案經理最好的朋友

第七章則探討了巴別塔失敗的原因：

1. 充分的溝通十分重要
2. 工作手冊的結構十分的重要，且每一位成員都應看到全部的文件內容
3. 專案管理的權力結構應該要是樹狀的（也就是第三章所講的整體概念性，任何人都不能同時聽命於兩個老闆），而組織內的溝通結構則應該是網狀的

專案時程預估要注意哪些事？

第八章討論了專案時程預估要注意的重點：

1. 員工只有 50% 的時間真正在寫程式
2. 溝通時間應納入估算
3. 開發程式的類型不同以及大小之間的關係必須算進去——專案大小及費力程度大概是 1.5 的指數關係

此外，必須做好整體空間規劃，不單包括常駐空間，背後有連帶關係的動作也應納入考量（例如記憶體分頁錯亂）。書中提出兩個方法：

• 方法一：確保大家的本事是真正通過程式設計的訓練而來
• 方法二：認知組件是要去創造才有的，每個專案都應有個手冊，專門蒐集關於佇列、搜尋、堆疊、雜湊（hashing）、Sorting 的副程式，且要有兩套方法：一個是用的空間最少的、一個是速度最快的

規劃軟體開發的文件應包含：目標、產品規格、時程、預算、場地配置、組織編製圖。

如何讓計畫「預期改變」與「預期失敗」？

1. 把一次必然的失敗納入正式計劃之中（失敗是成功之母）：

1. 表格驅動技術：將設定值寫在表格檔案之中
2. 軟體開發十分容易面臨無窮無盡的改變，因此要將改變量化，使組織利於改變
3. 軟體測試在維護時期要用更多的資源（要做迴歸測試），也會需要「進一步、退兩步」——任何修改都有可能破壞掉原有的軟體結構

開發工具與程式語言的選擇有多重要？

第十二章在講開發工具的重要性。通常我們開發時的工具機器和最後程式要跑的目標機器是不一樣的，因此我們需要採用成熟的機器，避免「偶爾出現、偶爾正常」的問題被忽略。程式語言的選擇也是工具選擇之一，書中提到採用高階語言可以大量提高生產力。

如何避免錯誤的發生？

在專案開發中要如何避免錯誤的發生？第十三章提到了幾點重點：

1. 整體概念性的具備：避免不同開發人員做出彼此不協調的假設。具備整體概念性的軟體容易使用、易於開發，也比較不容易發生錯誤。
2. 規格審查：規格書應交給獨立的測試小組進行審查，而不應該給程式設計人員去審查。
3. 由上而下的設計方式：這是一種持續細分精製的步驟——先勾勒出粗略的工作定義和執行方案以得到主要的結果，然後做更深入的探討，看看跟我們真正要的東西有何不同。也就是把大步驟細分成幾個更小的步驟。
4. 結構化程式設計：由 Dijkstra 所提出，說明由某一節點到另一個節點的最短路徑方式。

如何避免大災難的發生？

要如何避免大災難的發生，有以下幾點：

1. 里程碑應明確、不模稜兩可，要明顯到無法讓人自己騙自己，可以輕易查證。
2. 團隊應充滿幹勁。我們亦可提出計劃評核圖（PERT chart）或要徑時程表（critical-path schedule）來顯示什麼做完才可以做什麼，並告訴我們什麼事情是重要的、需要先做。

PERT chart 的三個時間估計值：

• a：最樂觀時間（Optimistic Time），為最短時間
• m：最可能時間（Most Likely Time），為適中時間
• b：最悲觀時間（Pessimistic Time），為最長時間

要徑的概念：通過網路最長的路徑，稱為要徑。若最長路徑的作業延遲了，整個專案就延遲；若要縮短專案完成時間，只要縮短要徑作業的工期即可。要完成專案，所有的路徑都必須通過。

1. 避免隱匿不報的狀況發生：為了避免下面的人明知專案延遲卻不往上報，在組織上應降低角色衝突（老闆不應干涉部屬可以自己解決的問題），並且訂定一些審查技巧。

延伸閱讀

• 人月神話讀後筆記：為什麼延遲的專案不能靠加人救？：同樣聚焦 專案管理、人月神話，可接著比較不同情境的做法。
• 沒有銀彈 – 軟體工程的本質性與附屬性工作：同樣聚焦 軟體工程、人月神話，可接著比較不同情境的做法。
• 沒有銀彈：軟體工程的本質性與附屬性工作：同樣聚焦 軟體工程、人月神話，可接著比較不同情境的做法。

常見問題

Q什麼是「人月迷思」？

人月迷思指的是「人力和工時可以互換」的錯誤假設。軟體專案不是純勞力工作，人數增加後溝通、管理、協調成本會非線性上升，所以「3 人月的工作 3 個人做 1 個月完成」往往不成立。

Q為什麼延遲的專案不該再加人？

新人需要教育與上手時間，會消耗老手本來就能投入開發的產能，同時增加溝通成本，這就是 Brooks 法則：「在已經延遲的軟體專案中增加人手，只會讓它更加延遲。」書中建議改為重新安排時程或刪減工作範圍。

Q什麼是第二系統效應？

第二系統效應指一個設計者的第二個系統最容易失敗，因為第一次成功帶來的自信會使他加入過多功能、過度設計。防範之道是靠自律節制，專注於核心概念而非功能堆疊。

Q什麼是整體概念性？為什麼重要？

整體概念性（Conceptual Integrity）指整個系統呈現一致的設計理念，最好出於同一人之手。具備整體概念性的軟體容易使用、易於開發，也比較不容易發生錯誤，因為不同開發人員不會做出彼此不協調的假設。

Q書中建議的專案時程該怎麼分配？

《人月神話》建議：1/3 時間規劃、1/6 時間寫程式、1/4 組件測試和早期系統測試、1/4 系統測試和完成所有組件。換句話說，寫程式其實只占整個專案的六分之一，測試與規劃才是大宗。

參考資料

• Brooks, F. P.，《The Mythical Man-Month》（人月神話）

最後更新

2026-08-28（原文發布於 2012-08-15，本文保留原始筆記內容並補上 GEO 結構。）

關於作者 {#author}

Claire Chang ｜ 企業 AI 導入與流程轉型顧問。專注於 AI Agent 架構設計、ERP 系統整合與企業 AI 治理。

首次發布：2012-08-15