📌 30 秒摘要(Layer 3)

軟體工程管理的祖師級經典。核心洞見:人和月不能互換——把人力加到已經落後的專案,只會讓它更落後(溝通成本呈平方成長、還要訓練新人)。要做出好系統,關鍵在概念完整性(由少數架構師守護一致的設計理念)。而且軟體的本質複雜度無法靠單一技術消除——沒有銀彈

🗺 心智圖(Canvas)

人月神話

📓 人月神話

The Mythical Man-Month

⏳ 人月與進度

🎯 什麼情境該想到我

當專案已經落後、你(或老闆)想「多找幾個人來趕上進度」時——先讀這條。

⚙️ 怎麼用

「為落後的軟體專案增加人手,只會讓它更落後。」
原因:

  1. 新人要學習時間,還會佔用現有成員來帶。
  2. 溝通成本呈平方成長:n 個人有 n(n-1)/2 條溝通路徑。
  3. 可分割但需協作的任務,切得越碎、協調越貴。

該怎麼做:

  • 及早重新規劃範圍/砍需求,而不是加人。
  • 真要加人,越早越好(越接近死線越無效),且要能切出獨立、少溝通的工作。
  • 保護 工具-概念完整性,別讓加人稀釋設計一致性。

🧪 我實際套用的紀錄

  • 2026-07-15:(待填)

⚠️ 注意

  • 例外是「完全可平行、無需溝通」的任務;但軟體開發極少屬於此類。

🔗 相關工具

人月是神話 人力與時間不可簡單互換

溝通成本呈平方成長 n 人有 n(n-1)/2 條溝通路徑

新人要訓練 加人到落後專案,短期只會更慢

🏛 概念完整性

🎯 什麼情境該想到我

當多人協作、系統各處風格/慣例開始發散、「每個模組像不同人寫的」時。

⚙️ 怎麼用

「概念完整性是系統設計中最重要的考量。」 一個一致、可預期的系統,勝過功能多但零散的系統。

  1. 由少數架構師守護統一的設計理念:整體概念集中決策,避免委員會式的拼湊。
  2. 架構與實作分離:架構師定「做什麼、對外長怎樣」,實作者決「怎麼做」。
  3. 寧可少做幾個功能,也要維持一致性:不一致的多功能,認知成本比少功能更高。
  4. 用共同的慣例、通用語言(工具-通用語言)讓一致性可延續。

🧪 我實際套用的紀錄

  • 2026-07-15:(待填)

⚠️ 注意

  • 「集中把關」不是獨裁;架構師要傾聽實作者回饋,但最終保持概念一致。

🔗 相關工具

架構與實作分離 由少數架構師守護一致的設計理念

寧可少幾個功能 也要維持統一的設計理念

⚠️ 第二系統效應

設計第二個系統時最危險 第一個保守、第二個放縱

過度設計、堆砌功能 把所有壓抑的點子一次塞進去

🔫 沒有銀彈

🎯 什麼情境該想到我

當有人(或你自己)期待「導入某個新語言/框架/AI 工具,生產力就會十倍跳升、問題全解」時。

⚙️ 怎麼用(分清兩種複雜度)

「沒有任何單一技術或管理上的突破,能在十年內讓生產力、可靠性、簡單性提升一個數量級。」

  1. 本質複雜度(Essential):來自問題本身的複雜(需求、概念、狀態)——工具消不掉,只能靠好的設計與思考馴服。
  2. 附屬複雜度(Accidental):來自工具/語言/流程的笨拙——這部分工具能改善(但邊際遞減)。
  3. 判斷任何「銀彈」宣稱:它解的是附屬複雜度還是本質複雜度?宣稱能消滅本質複雜度的,多半是幻想。

🧪 我實際套用的紀錄

  • 2026-07-15:(待填)

⚠️ 注意

  • 這不是反對工具;工具能除附屬複雜度。只是別期待它解決「問題本身很難」這件事。

🔗 相關工具

本質複雜度 軟體固有的複雜,無法靠工具消除

附屬複雜度 工具與語言可解的那一部分

👥 外科手術隊伍

小而精的團隊 圍繞少數頂尖者組織

明確分工 其餘成員支援「主刀者」,而非平均分攤

Link to original

🧰 這本書給我的工具

✨ 關鍵重點(Layer 1–2)

  • 布魯克斯定律:為落後的軟體專案增加人手,只會讓它更慢。
  • 人月是神話:人力與時間不可簡單互換;可分割且需溝通的任務,加人反而更糟。
  • 概念完整性:系統設計最重要的是一致性,寧可少幾個功能也要維持統一的設計理念;架構與實作分離。
  • 第二系統效應:人在設計第二個系統時最危險,容易過度設計、堆砌功能。
  • 沒有銀彈:區分本質複雜度(無法消除)與附屬複雜度(工具可解);沒有單一突破能讓生產力十倍成長。
  • 外科手術隊伍:小而精、圍繞少數頂尖者組織團隊。

💬 金句原文(Layer 0)

  • 「為落後的專案增加人手,會使它更加落後。」
  • 「概念完整性是系統設計中最重要的考量。」

🔗 相關