Craig Letavec, PMP, PgMP, MSP — Waynesville, Ohio, USA
計劃與現實的落差#
軟體專案常常陷入超時、超支、品質不足的困境——即使在擁有國際認證的知名開發機構也不例外。原因之一，在於計劃本身缺乏對現實變動的容忍空間。
開發進度天生就會起伏：有時超前，有時落後。許多專案經理的直覺反應是制定更嚴格、更細緻的時程表，結果卻花費大量時間反覆修訂計劃，疲於奔命。
緩衝時間的概念#
**關鍵鏈法（Critical Chain Method）**提供了一個務實的做法：在計劃中加入「緩衝時間（Buffer Time）」，也稱為「現實時間（Reality Time）」。
做法如下：
- 審視專案每個階段（設計、編碼、測試等）
- 估算該階段的總工期
- 在階段末尾加入一個緩衝任務，時間約為該階段總工期的 10%
舉例： 設計階段預估 40 天，加入 4 天緩衝後，總計 44 天。
緩衝時間的用途：
- 若提前完成，可將剩餘緩衝結轉至下一階段
- 若遇到意外，可在不大幅調整整體計劃的情況下吸收延誤
- 對於高風險階段，可設定更大的緩衝比例
核心觀點： 緩衝時間是一種計劃風險管理（Schedule Risk Management），不是在浪費時間。早期建立緩衝，遠比後期出現危機時臨時應對更有效益。
常見陷阱：雙重緩衝#
注意： 避免「雙重緩衝（Double Dipping）」——也就是在每個任務層級已加入額外時間，同時又在階段層級再加緩衝。這個技巧只在任務估算本身不含額外保留時間時才能發揮最佳效果。
面對質疑時站穩立場#
第一次提出這個方法時，管理層通常會想刪除這些「非生產性」的時間。面對這種壓力，要清楚表達立場：這是基本的計劃風險管理，不是鬆散的態度。
技巧： 越早佈局緩衝，應對突發狀況的餘裕就越大。「提前」永遠比「追趕」佔優勢。