文件假說 | 人月神話：軟體專案管理之道

文件假說的由來#

「文件假說」這個詞彙借自聖經學術研究，原指舊約聖經由多份獨立文件彙編而成的理論。Brooks 借用這個概念，提出一個類似的主張：任何專案的管理，都可以用一小組關鍵文件來支撐。這些文件不需要很多，但缺一不可。

文件的價值不在於它記錄了什麼，而在於撰寫文件的過程迫使你做出決策。許多混沌不明的問題，在你試圖將它寫成文件的那一刻就必須釐清。

Brooks 列出了軟體專案中不可或缺的核心文件清單：

系統要做什麼？為誰做？達成什麼商業目標？這份文件定義了專案存在的理由，是所有後續決策的基礎。

即使用者手冊或架構文件。這是系統外部行為的完整描述——使用者會看到什麼、能做什麼。Brooks 在前幾章已經詳細論述了規格書的重要性。

包含里程碑、截止日期和各項任務的時間分配。時程是管理者追蹤進度的主要工具。

資金的分配計畫。這包含人力成本、設備成本和其他資源的配置。

誰負責什麼？向誰匯報？團隊之間如何協調？這份文件定義了人員的角色與責任。

團隊的實體空間安排。在 Brooks 的時代，這包括辦公室和機房的分配。在今天，這可能延伸到遠端協作工具和溝通管道的規劃。

成本預估、市場預測和定價策略。這些數字驅動著商業決策。

為了說明這組文件的通用性，Brooks 以一個大學資訊科學系為例：

這個類比展示了一個重要事實：無論管理的是軟體專案還是學術機構，所需的核心文件結構驚人地相似。這暗示了管理的本質具有跨領域的共通性。

如果你在管理一個專案卻說不出上述七份文件的內容，那麼很可能有些關鍵決策尚未做出——你只是還沒意識到而已。

Brooks 認為這些關鍵文件同時服務三個目的：

撰寫文件的過程本身就是決策的過程。當你試圖寫下「系統應該如何處理 X 情境」時，你就不得不做出選擇。許多在口頭討論中可以含糊帶過的問題，在落筆的那一刻都無處遁形。

文件是將決策傳遞給所有相關人員的載體。口頭傳達容易走樣、遺忘或產生歧義；書面文件則提供了一個穩定、可查閱、可追溯的溝通媒介。

文件構成了一個資料庫，管理者可以透過它追蹤專案的當前狀態、歷史變更和未來計畫。定期更新文件並比較實際進度與預期計畫，是專案管控的核心機制。

不要把文件當作一次性的工作產出。文件應該是活的——隨著專案推進持續更新。過時的文件比沒有文件更危險，因為它會傳達錯誤的資訊。

Brooks 在本章再次引用了康威定律：系統的設計反映了組織的溝通結構。因此，組織架構圖本身就是一份設計文件——它不僅定義了誰向誰匯報，更隱含地決定了系統將如何被分割和整合。

這意味著管理者在繪製組織架構圖時，應該同時意識到自己正在做一個系統架構的決策。

Brooks 在本章的結尾提出了一個精闢的觀點：

管理者的任務不是親自做出所有決策，而是確保所有必要的決策都被做出。

文件就是實現這個目標的工具。當你看到文件中有空白、有含糊、有矛盾時，就代表有決策尚未完成。管理者的工作是識別這些空白，並推動相關人員去填補它們。

缺少文件的專案不是「敏捷」，而是「失控」。敏捷開發減少的是不必要的文件，而非關鍵的決策記錄。上述七份核心文件，無論你採用什麼開發方法論，都是不可省略的。