釀成大災難

一天一天地遲到#

Brooks 在本章提出了他最常被引用的觀察之一：

「一個專案是如何延遲一年的？……一天一天地延遲的。」（How does a project get to be a year late? … One day at a time.）

摧毀專案時程的，不是龍捲風般的戲劇性危機，而是白蟻——那些每天悄悄啃噬進度的微小延誤。一個功能「只差一兩天」、一次會議「比預期多花了半天」、一個臭蟲「再花一個下午就好」。這些看似無害的小延遲，累積起來就是一場大災難。

沒有人會在某一天早上醒來宣布「我們的專案延遲了六個月」。延遲是漸進的、無感的。當你終於意識到問題的嚴重性時，通常已經為時已晚。

里程碑（milestone）是追蹤進度的基本工具，但它們必須具備以下特性：

Brooks 特別強調里程碑必須是銳利的（sharp）。所謂銳利，是指不存在「大致完成」或「幾乎做好了」這種灰色地帶。

當里程碑的定義模糊時，它就從里程碑（milestone）變成了磨石（millstone）——不是幫助你追蹤進度，而是讓你被虛假的進度感所拖累。

這是專案中最危險的藉口之一。當團隊 A 發現團隊 B 的進度落後時，很容易產生一種想法：「既然他們也遲到了，我們不急。」

這種心態的毒性在於它會像傳染病一樣擴散。每個團隊都在等待別人先完成，結果所有人同時放慢腳步。原本只有一個部分延遲的專案，最終演變為所有部分都延遲。

Brooks 的建議很簡單：不論其他團隊的進度如何，每個團隊都必須全力趕上自己的時程。 唯有如此，當延遲的部分最終完成時，其他部分才能立即銜接。

PERT 圖（Program Evaluation and Review Technique）是一種網路分析方法，用來視覺化任務之間的依賴關係。它的核心概念是關鍵路徑（critical path）——從專案開始到結束，最長的一條任務鏈。

關鍵路徑決定了專案的最短完成時間。任何位於關鍵路徑上的任務延遲，都會直接導致整個專案延遲。非關鍵路徑上的任務則有一定的浮動時間（slack），即使稍微延遲也不影響最終交付日期。

PERT 圖的價值不僅在於規劃階段。在專案執行過程中，隨著實際進度與計畫產生偏差，關鍵路徑可能會改變。持續更新 PERT 圖，才能及時發現新的風險。

Brooks 指出，專案管理中最根本的問題之一是：壞消息不會自動向上傳遞。基層程式設計師知道進度落後，但這個資訊在向上報告的過程中會被層層過濾、美化，甚至完全消失。

為什麼會這樣？因為角色衝突（role conflict）。報告狀態的對象，同時也是評估績效的主管。沒有人願意在老闆面前承認自己的工作落後了。

Brooks 建議嚴格區分兩種會議：

如果狀態檢視會議中，報告壞消息的人會被當場質問或批評，那麼下次就不會再有人報告壞消息了。主管必須刻意營造一個安全的環境，讓誠實的報告成為常態。

Brooks 提出一個具體的技巧：在里程碑報告中同時顯示兩個日期——計畫日期（scheduled date）和預估完成日期（estimated completion date）。這種格式將「原始計畫」與「目前現實」明確分開，讓偏差變得一目了然，而不需要任何人主動「承認」延遲。

Brooks 建議在大型專案中設立一個小型的計畫與控制團隊（Plans and Controls team），通常只需要 2 到 3 人。這個團隊的職責是：

這個團隊不隸屬於任何開發團隊，因此能夠提供不受利益衝突影響的客觀觀點。