人月神話讀後筆記：為什麼延遲的專案不能靠加人救？

為什麼「人月」是一個危險的迷思？

以成本會計為基礎的時程預估方式，使我們誤把工作量和專案進度混為一談。人月是一個危險並容易遭到誤解的迷思，因為它假設人力和工時可以互換。

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

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

開發軟體系統產品要多付出多少代價？

開發一個軟體系統產品，要付出的代價是一般組件程式的九倍。因為產品化是一般組件程式的三倍時間，設計整合測試又是三倍時間，這兩方面的成本計算基本上是獨立的。

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

什麼是「整體概念性」？為什麼專案不該有兩個領導者？

從第三章到第七章，都是在討論保有「整體概念性」的重要。

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

外科手術團隊是怎麼運作的？

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

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

什麼是第二系統效應？

在第五章的地方，提到了第二系統效應：最容易失敗的專案，反而是我們第二個設計的系統，原因是加入了太多不相關功能。我們要慎防在設計第二個系統的時候過度設計，保持自律。

意念要怎麼在團隊之間傳達？

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

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

巴別塔為什麼會失敗？

在第七章探討了巴別塔失敗的原因，對應到軟體專案有三點啟示：

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

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

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

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

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

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

軟體開發需要規劃哪些文件？

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

同時，要把一次必然的失敗納入正式計劃之中（失敗是成功之母）：

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

開發工具的選擇有多重要？

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

如何避免錯誤的發生？

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

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

如何避免大災難的發生？

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

1. 里程碑應要明確、不模稜兩可，要明顯到無法讓人自己騙自己，可以輕易查證
2. 團隊應充滿幹勁，我們亦可提出計劃評核圖（PERT chart）或要徑時程表（critical-path schedule）來顯示什麼做完才可以做什麼，並告訴我們什麼事情是重要的、需要先做
3. 避免隱匿不報的狀況發生：為了避免下面的人明知專案延遲卻不往上報，在組織上應降低角色衝突（老闆不應干涉部屬可以自己解決的問題），並且訂定一些審查技巧

其中 PERT chart 的三個時間估計值：

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

延伸閱讀

• 人月神話讀後筆記：軟體專案管理不可不慎的經典啟示：同樣聚焦 專案管理、人月神話，可接著比較不同情境的做法。
• 沒有銀彈 – 軟體工程的本質性與附屬性工作：同樣聚焦 軟體工程、人月神話，可接著比較不同情境的做法。
• 沒有銀彈：軟體工程的本質性與附屬性工作：同樣聚焦 軟體工程、人月神話，可接著比較不同情境的做法。

常見問題

Q什麼是「人月迷思」？

人月迷思指的是誤以為人力和工時可以互換，以為增加人就能縮短時程。實際上人員增加後，溝通、管理、協調的成本會大幅上升，人與月之間並非線性關係，所以在一個已經延遲的專案中增加人手，只會讓它更加落後。

Q什麼是「第二系統效應」？

第二系統效應指的是：最容易失敗的專案，往往是一個人（或團隊）設計的第二個系統，因為設計者在第二個系統中傾向加入太多不相關的功能，造成過度設計。避免的方法是保持自律、克制膨脹功能的衝動。

Q什麼是「整體概念性」？

整體概念性是指整個系統呈現同一套設計理念，由同一人之手主導規劃。具備整體概念性的軟體容易使用、易於開發，也比較不容易發生錯誤，因為不同開發人員不會做出彼此不協調的假設。

Q什麼是「外科手術團隊」？

外科手術團隊是《人月神話》提出的團隊組織方式：由一位首席程式設計師負責所有關鍵決策與設計，其他人（副手、行政助理、文件撰寫人員、測試員、工具專家等）提供支援，以此確保設計出於同一人之手、維持整體概念性。

Q什麼是要徑（Critical Path）？

要徑是專案網路圖中通過最長的一條路徑。若要徑上的作業延遲，整個專案就會延遲；反過來說，要縮短專案完成時間，就要從縮短要徑作業的工期下手。

Q已經延遲的專案該怎麼辦？

書中建議不要增加人手（那會因為溝通成本與新人上手時間讓專案更落後），而是重新安排時程，或者刪減工作範圍。

最後更新

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

關於作者 {#author}

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

首次發布：2012-08-15