本周繼續閱讀《人月神話》，本周度過的部分是第十章和第十一章（“提綱挈領”和“未雨綢繆”），以下是對該兩章的感想。
一、提綱挈領

提綱挈領一章描述的是經理與文件的關系。作者一開始便給文件做了定性：文檔的某些部分包含和表達了一些管理方面的工作，其準備工作是集中考慮並使各種討論意見明朗化的時刻，其跟蹤維護是項目監督和預警的機制。

作者通過“計算機產品的文檔”、“大學科系的文檔”和“軟件項目的文檔”，來闡明文檔如何展開上述工作。

我們可以看到，所有的文檔都包含的項目是以下幾個：目標、機構分類、技術要求、時間表、預算。這幾項幾乎包含了一個工程中所有的管理要素。

文檔的必要性在於它的三個具體角色：書面決策、溝通渠道和數據基礎與檢查列表。第一項使得工作規範化、工作目標清晰化（目標、機構分類、技術要求），第二項使得決策被團隊成員所知曉，而第三項則可以讓經理對項目所處的狀態有一個大致的了解（時間表、預算）。

二、未雨綢繆

未雨綢繆的英文是“Plan to Throw One Away”，因此這個中文翻譯不太恰當。實際上這一章講的是，應該實行實驗性開發，並且隨時做好丟棄原本成果的準備，而不是把第一次開發所得的產品提交給客戶去使用。

實際上對於大多數項目，第一次開發的系統很有可能是太大、太慢或者是難以使用的，且新的技術和概念的產生很可能使已有的系統開發出來就已經過時。解決辦法簡單粗暴——從零開始，設計一個更靈巧、方便、小巧的系統。但是實際上，在開發之前，這些問題是無法得到解決的，畢竟項目經理不能未蔔先知。

因此，這個問題變成了“是否拋棄原型，亦或將原型直接發布給客戶？”，對此，作者的結論是“為舍棄（變更）而計劃，無論何時，都一定要這樣做”。

如何變更計劃系統呢？作者描述的不多，而唯一被強調的一點是：使用高級語言和自文檔技術，以減少變更引起的錯誤。

變更引起的問題，最大的一點就是BUG，而維護系統、修復BUG的過程，被作者形象地稱作是“前進兩步，後退一步”，因為維護系統消除BUG之時，會以20-50%的幾率引進新的BUG。而解決方式則是，使用能消除、至少是能指明副作用的程序設計方法，且盡可能使用較少的人員和接口。

《人月神話》讀書筆記之四