WBS 拆解不好，時程再精細也沒用
很多 PM 把時間花在精細化甘特圖、或是反覆調整里程碑日期，但根本問題是 WBS 就拆得不對。 WBS 是整個專案計畫的基礎——工時估算、資源分配、進度追蹤、風險識別，都依賴 WBS 的品質。 WBS 爛，上面蓋的一切都是沙堆上的城堡。
WBS（Work Breakdown Structure，工作分解結構）是把專案範疇拆解成較小、可管理的工作單元的階層式結構。最底層的單元稱為「工作包（Work Package）」，是可以分配給個人或小組、並可以估算工時和成本的最小單位。
錯誤 #1：任務粒度不一致
看一個很典型的例子：有人把「建立整個資料庫架構」和「寄一封確認信給客戶」放在 WBS 的同一層。前者可能需要 3 週，後者 10 分鐘。當這兩個任務出現在同一張甘特圖，進度追蹤就變得毫無意義——大任務塞在裡面，讓整個計畫看起來進展順利，直到截止日前一週才爆出來。
- 設計整個前端介面（3 週）
- 更新一個按鈕顏色（5 分鐘）
- 整合第三方支付系統（2 週）
- 寄測試邀請給 5 位用戶（30 分鐘）
- 完成登入/登出流程設計稿（3 天）
- 完成首頁元件設計稿（2 天）
- 串接支付 API 並完成測試（4 天）
- 完成用戶測試招募與邀請（1 天）
修正方法：使用「8-80 小時法則」——每個工作包（最底層任務）的估算工時，應該在 8 到 80 小時之間。少於 8 小時的任務可以合併，超過 80 小時的任務需要繼續拆解。
錯誤 #2：忽略任務相依性
WBS 拆解完成後，第二步是梳理任務間的相依關係（Dependency）。哪些任務必須在另一個任務完成後才能開始？哪些可以真正並行？
常見的錯誤是：為了讓計畫看起來「時程緊湊」，把很多任務標記為可以同時進行。結果是——資源根本不夠，關鍵路徑沒被識別出來，最先遇到阻礙的那個任務延期，帶動後面一串任務全部延期。
關鍵路徑（Critical Path）是專案中最長的任務鏈，任何一個節點延期，都會直接導致整個專案延期。識別關鍵路徑是時程管理的基礎——你需要知道哪些任務是「絕對不能延的」，才能做好緩衝時間的分配。
修正方法：對 WBS 最底層的每個工作包，明確標記「前置任務（Predecessor）」。完成這個步驟後，用網絡圖（AON 圖）或甘特圖的連結線呈現相依關係，找出關鍵路徑，並在關鍵路徑上的任務加入適當的緩衝（Buffer）。
錯誤 #3：WBS 以「活動」為導向，而非「交付物」
這是學術和教科書最強調的一個原則，但在實際工作中最常被忽略。WBS 的設計理念是以交付物（Deliverable）為導向——每個工作包的名稱，應該是一個你可以驗收、可以說「完成了」的東西，而不是一個動詞的活動描述。
- 研究競品功能
- 開需求確認會議
- 討論技術架構
- 準備測試環境
- 競品分析報告（5 個競品，含截圖）
- 簽核完成的需求確認文件
- 技術架構決策紀錄（含選型理由）
- 可執行的測試環境（附設定文件）
活動型 WBS 的問題是：你永遠不知道這個任務「完成了沒有」。「研究競品功能」這件事可以做 3 天，也可以做 3 個月，沒有明確的驗收標準。交付物型 WBS 讓完成條件清晰，也讓驗收變得可能。
修正方法：檢視 WBS 中每個工作包的名稱。如果它是一個動詞（研究、討論、開會、準備），問自己：「完成這個活動的輸出是什麼？」把輸出作為工作包的名稱。
好的 WBS 自我檢查清單
- 每個工作包都是「交付物」而非「活動」描述
- 最底層工作包估算工時在 8-80 小時之間
- 同一層的工作包粒度大致一致
- 每個工作包都有明確的完成條件（DoD）
- 已標記所有工作包的前置任務
- 關鍵路徑已識別並標記
- WBS 100% 覆蓋所有在範疇內的工作（100% Rule）
延期不是壞運氣，是設計問題
我見過很多 PM 把延期歸因於「需求一直改」、「資源不夠」、「客戶不配合」。這些當然都是真實的挑戰，但它們大多不是延期的根本原因，而是讓延期被放大的因素。
一個設計良好的 WBS，可以讓你在需求變更時快速評估影響範圍；可以讓資源分配更精準；可以讓你在問題早期就看到訊號，而不是在截止日前一週才爆出來。
給時程留 buffer 不是你的工作，建立一個可以預測問題的計畫才是。
常見問題
WBS 應該拆解到多細？
WBS 最底層的工作包（Work Package）通常建議在 8-80 小時之間。太細會讓追蹤變成負擔，太粗則無法有效監控進度。一個實用原則是「2 週法則」：每個工作包應該在 2 週內可以完成並驗收，超過就需要繼續拆解。
WBS 和任務清單有什麼不同？
WBS（工作分解結構）是以交付物為導向的階層式分解，強調「要做出什麼」。任務清單是以行動為導向的清單，強調「要做什麼動作」。WBS 是專案計畫的基礎，任務清單是從 WBS 衍生出來的執行清單。只有任務清單沒有 WBS，很容易遺漏重要的交付物。
專案延期最常見的原因是什麼？
專案延期最常見的根本原因包括：範疇蔓延（Scope Creep）、初期工時估算過於樂觀、任務相依性沒有明確管理、以及資源衝突（同一個人被分配到太多並行任務）。WBS 拆解品質直接影響工時估算的準確度，是預防延期的關鍵前期工作。
在真實情境中練習 WBS 和專案決策？
PM Simulator 用 RPG 遊戲的方式，讓你在真實職場情境中練習 WBS 拆解、資源分配、以及危機處理——失誤在遊戲裡，成長帶到職場上。
了解 PM Simulator →