📓 人月神話

🎯 什麼情境該想到我

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

⚙️ 怎麼用

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

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

該怎麼做：

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

🧪 我實際套用的紀錄

• 2026-07-15：（待填）

⚠️ 注意

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

🔗 相關工具

• 工具-概念完整性 —— 為什麼加人會變慢的根本原因：人一多，設計的一致性就散掉
• 工具-降低在製品WIP —— 落後時真正有效的做法，不是加人而是少開幾條戰線
• 工具-找出並管理約束點 —— 加人之前該先問的問題：瓶頸在哪，加在非瓶頸處等於零

🎯 什麼情境該想到我

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

⚙️ 怎麼用

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

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

🧪 我實際套用的紀錄

• 2026-07-15：（待填）

⚠️ 注意

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

🔗 相關工具

• 工具-布魯克斯定律 —— 因果關係，人一多概念完整性就散，這是加人會變慢的深層原因
• 工具-介面設計原則 —— 落地方式，一致的介面風格是概念完整性最具體的載體
• 工具-通用語言 —— 另一條路徑，讓工程與業務共用同一套詞彙，模型才不會各說各話

🎯 什麼情境該想到我

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

⚙️ 怎麼用（分清兩種複雜度）

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

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

🧪 我實際套用的紀錄

• 2026-07-15：（待填）

⚠️ 注意

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

🔗 相關工具

• 工具-管理複雜度 —— 為什麼沒有銀彈：本質複雜度砍不掉，工具只能砍附屬複雜度
• 工具-簡單清楚至上 —— 實務上的替代方案，與其等銀彈不如持續把東西做簡單