WBS 字典（WBS Dictionary）是針對 WBS 中每個工作包所撰寫的說明文件，記錄範疇、負責人、時程、成本與驗收標準。這篇教學帶你從定義到實作，掌握 10 大標準欄位、5 步驟撰寫流程，以及 3 種專案類型的完整範例。
什麼是 WBS 字典？
WBS 字典（WBS Dictionary），也稱為工作包說明或工作分解結構詞典，是 PMBOK 標準中定義的專案範疇基準文件之一。簡單來說，如果 WBS 圖表是專案的「骨架」，WBS 字典就是讓骨架能動起來的「肌肉」。
很多 PM 花了大量時間建立漂亮的 WBS 樹狀圖，卻在交付給執行團隊後發現：工程師不確定「系統測試」到底要測哪些項目、行銷同事不知道「內容製作」的驗收標準是什麼。這就是光有 WBS 圖表不夠的核心問題——圖表只告訴你「要做什麼」，字典才告訴你「怎麼做、做到什麼程度、誰負責」。
我們團隊在管理跨部門專案時，曾經只靠 WBS 圖表溝通，結果同一個工作包，PM 理解的範疇和執行者理解的範疇差了將近 40%。自從導入 WBS 字典後，這類認知落差幾乎消失了。
WBS 字典解決的三個核心問題：
- 範疇模糊：明確定義每個工作包「包含什麼」和「不包含什麼」
- 責任不清：指定每個工作包的負責人與相關利害關係人
- 驗收爭議：事先定義量化的完成標準，避免交付時的主觀判斷
如果你正在準備 PMP 考試或想提升企劃書的品質，理解 WBS 字典是不可跳過的基本功。
WBS 字典包含哪些內容？
一份完整的 WBS 字典由 10 個標準欄位組成。以下逐一說明每個欄位的定義、填寫邏輯，以及哪些是必填、哪些可依專案規模選填。
| 欄位名稱 | 說明 | 必填 / 選填 |
|---|---|---|
| 工作包代碼（WBS Code） | 對應 WBS 圖表中的編號，如 1.2.3 | 必填 |
| 工作包名稱 | 簡短描述該工作包，如「使用者驗收測試」 | 必填 |
| 工作說明（Scope of Work） | 詳細描述工作內容，包含「包含什麼」與「不包含什麼」 | 必填 |
| 負責人 / 負責單位 | 該工作包的主要負責人，建議只指定一人 | 必填 |
| 預計開始與完成日期 | 與專案時程表對齊的起迄時間 | 必填 |
| 預估工時與成本 | 完成該工作包所需的人時數與預算金額 | 選填（中大型專案建議必填） |
| 所需資源 | 人力、設備、材料、軟體授權等 | 選填 |
| 前置作業（依賴關係） | 必須先完成哪些工作包才能開始此項 | 選填（有依賴關係時必填） |
| 驗收標準（Acceptance Criteria） | 量化的完成條件，如「通過率達 95% 以上」 | 必填 |
| 假設與限制條件 | 執行此工作包的前提假設與已知限制 | 選填 |
成本欄位如何向上彙整
這是很多 PM 忽略的實務重點：WBS 字典中每個工作包的成本估算，應該能夠逐層向上彙整成專案總預算。例如，「1.2.1 場地租賃」估算 NT$50,000、「1.2.2 設備租借」估算 NT$30,000，那麼上層的「1.2 場地準備」預算就是 NT$80,000。這種由下而上的估算方式，比 PM 憑經驗拍腦袋的數字準確得多。
如果你的團隊需要更精確的時間管理，工時欄位也適用同樣的彙整邏輯。
實際填寫範例：辦公室裝修專案
以下是一個工作包的完整字典條目，讓你看到每個欄位實際填寫的樣子：
| 欄位 | 內容 |
|---|---|
| 工作包代碼 | 1.3.2 |
| 工作包名稱 | 油漆粉刷工程 |
| 工作說明 | 對 3F 辦公區域（約 120 坪）進行牆面批土、底漆、面漆施作。包含：牆面清潔、裂縫填補、兩道底漆、兩道面漆。不包含：天花板噴漆、外牆施作。 |
| 負責人 | 王建明（工程部） |
| 預計日期 | 開始：3/15，完成：3/28 |
| 預估工時與成本 | 240 人時，NT$180,000（含材料費 NT$60,000） |
| 所需資源 | 油漆工 4 人、批土材料、底漆 20 桶、面漆 15 桶、噴漆設備 2 組 |
| 前置作業 | 1.3.1 水電管線配置完成 |
| 驗收標準 | 牆面平整度誤差 ≤ 2mm/m、色差 ΔE ≤ 1.5、無流掛/起泡/剝落 |
| 假設與限制 | 假設施工期間無連續雨天（影響乾燥時間）；限制：僅能在非上班時段施工 |
WBS 字典 vs. WBS 圖表：兩者如何搭配使用
這是最常被混淆的概念。很多人以為做完 WBS 圖表就等於完成了工作分解，但其實兩者的功能完全不同。
| 比較項目 | WBS 圖表 | WBS 字典 |
|---|---|---|
| 格式 | 樹狀圖 / 階層清單 | 表格 / 文件 |
| 用途 | 展示專案的整體結構與層級 | 詳細說明每個工作包的執行細節 |
| 主要使用者 | PM、高階主管、利害關係人 | 執行團隊、工作包負責人 |
| 更新頻率 | 較少更新（結構變動時） | 較頻繁（細節調整時） |
| 回答的問題 | 「專案要做哪些事？」 | 「每件事怎麼做、做到什麼程度？」 |
標準搭配流程
正確的使用順序是：先建立 WBS 圖表，確認專案的分解結構沒有遺漏，再逐一為最底層的工作包撰寫字典條目。我們團隊的做法是先用流程圖工具畫出 WBS 結構，確認利害關係人都同意後，再進入字典撰寫階段。
舉個實際例子：在一個軟體開發專案中，開發主管看到 WBS 圖表上有「1.4 系統測試」這個工作包，但他不確定測試範圍是否包含效能測試。翻開 WBS 字典，工作說明欄位清楚寫著：「包含功能測試、整合測試、效能測試（負載 1,000 人同時上線）；不包含安全性滲透測試（由資安團隊另案處理）。」這就是字典的價值——消除模糊空間。
WBS 字典與工作說明書（SOW）的差異
另一個常見混淆是 WBS 字典和 SOW（Statement of Work）。關鍵差異在於：SOW 是對外文件，用來與客戶或外部廠商約定工作範疇；WBS 字典是對內文件，用來指導執行團隊的日常作業。兩者可能描述同一件工作，但受眾和詳細程度不同。
如何撰寫 WBS 字典：5 步驟實務流程
以下是我們團隊實際使用的撰寫流程，從 WBS 分解完成到字典正式納入專案文件，共 5 個步驟。
Step 1：完成 WBS 分解至工作包層級
在開始寫字典之前，你的 WBS 必須已經分解到「工作包」層級。判斷是否夠細的實務法則是 8/80 法則：每個工作包的預估工時應介於 8 小時（1 天）到 80 小時（2 週）之間。低於 8 小時代表分得太細，管理成本會超過執行成本；超過 80 小時代表還不夠細，難以有效追蹤進度。
如果你的團隊還沒建立 WBS，可以先參考 monday.com 的 WBS 範本，它提供了現成的階層結構，你只需要根據專案需求調整即可。
Step 2：為每個工作包建立字典條目
不要從空白頁開始。 這是我們踩過最大的坑——第一次寫 WBS 字典時，PM 打開一份空白 Excel，結果每個工作包的欄位格式都不一致，後續彙整時花了雙倍時間。
正確做法是先建立一份標準範本（包含上一節提到的 10 個欄位），然後為每個工作包複製一份條目，逐欄填寫。在 monday.com 中，你可以用自訂欄位功能建立這些欄位，每個工作包就是一個任務項目，字典內容直接寫在任務描述和自訂欄位中。
Step 3：與負責人確認內容並完成審核
這一步是最容易被跳過的，也是最關鍵的。如果 PM 單方面填寫字典內容，執行者可能對工作範疇、時程估算或驗收標準有完全不同的理解。
我們的做法是：PM 先填寫 70% 的內容（代碼、名稱、大致範疇、日期），然後請工作包負責人補充剩下的 30%（詳細工作說明、資源需求、驗收標準）。最後由 PM 審核整體一致性，確認沒有遺漏或衝突。
審核時特別注意：
- 相鄰工作包之間是否有範疇重疊或空白
- 依賴關係是否合理（A 完成才能開始 B，但 B 的開始日期卻早於 A 的結束日期）
- 成本加總是否超出專案預算
對於需要正式核准的專案（如政府標案或大型企業內部專案），建議在字典中加入「核准人」和「核准日期」欄位，並保留簽核紀錄。
Step 4：設定驗收標準
驗收標準是 WBS 字典中最常被跳過、也最重要的欄位。沒有驗收標準的工作包，就像沒有終點線的賽跑——你永遠不知道什麼時候算「完成」。
模糊 vs. 清晰的驗收標準對照：
| 模糊寫法 ❌ | 清晰寫法 ✅ |
|---|---|
| 負責行銷 | 撰寫 3 篇部落格文章，每篇 1,500 字以上，於 5/15 前完成，通過主管審核 |
| 完成系統測試 | 執行 200 個測試案例，通過率 ≥ 95%，嚴重缺陷（P1/P2）數量為 0 |
| 設計完成 | 交付 UI 設計稿 15 頁，符合品牌規範手冊，經客戶簽核確認 |
好的驗收標準必須具備三個特徵：可量化（有數字）、可觀察（有具體產出物）、有時限（有截止日期）。這和撰寫商業模式中的關鍵指標是同樣的邏輯。
Step 5：納入專案文件管理系統，設定版本控制
WBS 字典不是寫完就放著的靜態文件。專案執行過程中，範疇可能變更、時程可能調整、資源可能重新分配——每次變更都必須同步更新字典，並記錄版本。
版本控制的最低要求：
- 每次修改記錄「修改日期」、「修改人」、「修改原因」
- 保留前一版本（不要直接覆蓋）
- 重大變更需走變更管理流程，經核准後才更新
實務上，我們團隊用 monday.com 的活動日誌功能來追蹤每個工作包的修改歷程。每次有人更新任務描述或自訂欄位，系統會自動記錄誰在什麼時間改了什麼內容，省去手動維護版本紀錄的麻煩。
WBS 字典實務範例
以下提供 3 種不同專案類型的完整工作包字典範例，你可以直接對照套用到自己的專案中。
範例 A：IT 系統導入專案——使用者驗收測試（UAT）
| 欄位 | 內容 |
|---|---|
| 工作包代碼 | 3.4.2 |
| 工作包名稱 | 使用者驗收測試（UAT） |
| 工作說明 | 由業務單位代表執行 ERP 系統的使用者驗收測試。包含：建立測試案例 50 個、執行測試、記錄缺陷、回歸測試。不包含：系統效能測試（由 IT 部門負責，見 3.3.5）。 |
| 負責人 | 林雅婷（業務部副理） |
| 預計日期 | 開始：6/1，完成：6/21（共 15 個工作天） |
| 預估工時與成本 | 320 人時（4 人 × 10 天全職 + 協調會議），NT$0（內部人力，不另計成本） |
| 所需資源 | 測試環境 1 套、測試帳號 8 組、會議室（每日 1 小時站會）、缺陷追蹤工具授權 |
| 前置作業 | 3.4.1 系統整合測試完成且 P1/P2 缺陷歸零 |
| 驗收標準 | 50 個測試案例全數執行完畢，通過率 ≥ 95%，P1 缺陷為 0，P2 缺陷 ≤ 2 且有修復計畫 |
| 假設與限制 | 假設測試環境資料已完成匿名化處理；限制：測試人員僅能在上班時間執行（不加班） |
這個範例的重點在於「不包含」的說明——明確排除效能測試，避免業務單位和 IT 部門之間的責任灰色地帶。如果你的團隊也在進行數位轉型相關專案，這種邊界劃分尤其重要。
範例 B：活動企劃專案——場地佈置與設備架設
| 欄位 | 內容 |
|---|---|
| 工作包代碼 | 2.3.1 |
| 工作包名稱 | 場地佈置與設備架設 |
| 工作說明 | 於活動前一天完成主會場（可容納 300 人）的佈置工作。包含：舞台搭建（6m × 4m）、音響設備架設與測試、LED 背板安裝、桌椅擺設（圓桌 30 張 × 10 人座）、動線指引牌設置。不包含：餐飲區佈置（見 2.3.2）、報到區設備（見 2.3.3）。 |
| 負責人 | 張家豪（活動執行組長） |
| 預計日期 | 開始：9/14 08:00，完成：9/14 22:00（1 天） |
| 預估工時與成本 | 80 人時（10 人 × 8 小時），NT$250,000（含設備租賃 NT$150,000 + 人力 NT$60,000 + 材料 NT$40,000） |
| 所需資源 | 舞台工班 4 人、音響技師 2 人、燈光技師 1 人、佈置人員 3 人、3.5 噸貨車 1 台 |
| 前置作業 | 2.2.1 場地租賃合約簽訂、2.2.3 設備租賃確認 |
| 驗收標準 | 舞台結構安全檢查通過、音響測試全場無死角（最後一排音量 ≥ 75dB）、LED 背板顯示正常、桌椅數量與配置圖一致 |
| 假設與限制 | 假設場地方於 9/14 07:00 開放進場；限制：噪音管制 22:00 後不得施工 |
這個範例強調的是資源與時程的精確度。活動專案的特性是時間壓縮、容錯空間極小，所以資源欄位必須列到「幾人、幾台車」的程度。
範例 C：產品開發專案——原型設計與使用者測試
| 欄位 | 內容 |
|---|---|
| 工作包代碼 | 1.5.3 |
| 工作包名稱 | 原型設計與使用者測試 |
| 工作說明 | 根據需求規格書（見 1.4.2）製作高保真互動原型，並招募目標用戶進行易用性測試。包含：原型設計（核心流程 5 條）、測試腳本撰寫、招募受測者 8 人、執行一對一測試、彙整測試報告。不包含：視覺設計定稿（見 1.6.1）。 |
| 負責人 | 陳思穎（UX 設計師） |
| 預計日期 | 開始：4/7，完成：4/25（共 15 個工作天） |
| 預估工時與成本 | 160 人時（設計 80h + 測試準備 40h + 執行與分析 40h），NT$95,000（含受測者酬勞 NT$12,000 + 原型工具授權 NT$3,000 + 設計人力 NT$80,000） |
| 所需資源 | Figma 企業版授權 1 席、易用性測試錄影設備、測試場地（安靜會議室）、受測者招募管道 |
| 前置作業 | 1.4.2 需求規格書核准、1.5.1 使用者旅程地圖完成 |
| 驗收標準 | 5 條核心流程原型完成且可互動操作、8 位受測者全數完成測試、任務完成率 ≥ 80%、SUS 易用性分數 ≥ 68 分、測試報告含改善建議 ≥ 10 項 |
| 假設與限制 | 假設受測者招募可在 5 個工作天內完成；限制：受測者須符合目標用戶 persona（25-40 歲、有線上購物經驗） |
這個範例的亮點在於驗收標準使用了業界標準指標（SUS 易用性分數），讓「好不好用」從主觀感受變成可量化的數字。
不同團隊規模的調整建議
不是每個專案都需要填滿 10 個欄位。根據團隊規模調整：
- 5 人以下小型團隊：保留 5 個核心欄位（代碼、名稱、工作說明、負責人、驗收標準），其他口頭溝通即可
- 10-30 人中型團隊：標準版，全欄位填寫，確保跨部門資訊對齊
- 30 人以上大型專案：加入 RACI 矩陣連結，標示每個工作包的負責（R）、當責（A）、諮詢（C）、知會（I）角色
WBS 字典範本與工具推薦
知道了 WBS 字典的內容和撰寫方法，接下來的問題是：用什麼工具來建立和管理它？
用 Excel / Google Sheets 建立 WBS 字典範本
如果你的團隊還沒有專案管理工具，Excel 或 Google Sheets 是最低門檻的起點。以下是具體的欄位設定步驟：
- 建立工作表結構：第一列（Row 1）設定 10 個欄位標題（A 欄：工作包代碼、B 欄：工作包名稱⋯⋯J 欄：假設與限制）
- 凍結首列：選取第一列 → 檢視 → 凍結窗格，方便向下捲動時仍能看到欄位名稱
- 設定資料驗證：「必填/選填」欄位用條件格式標記（必填欄位標題底色設為黃色）
- 建立下拉選單：負責人欄位用資料驗證建立團隊成員下拉選單，避免打字錯誤
- 加入篩選器：啟用自動篩選，方便依負責人、日期或狀態篩選特定工作包
Excel 的優點是幾乎零學習成本，但缺點也很明顯：多人同時編輯容易衝突、沒有自動通知功能、版本控制靠人工。當專案規模超過 20 個工作包時，你會開始感受到 Excel 的限制。
如果你想進一步提升 Excel 技能，Coursera 上的 Excel 課程可以幫你掌握更進階的資料管理技巧。
專案管理工具中的 WBS 字典功能
當專案複雜度提升，專用工具能大幅降低管理成本。以下是我們實測過的 4 款工具比較：
| 比較項目 | monday.com | ClickUp | Notion | MS Project |
|---|---|---|---|---|
| WBS 字典支援方式 | 自訂欄位 + 任務描述 | 自訂欄位 + 文件功能 | 資料庫頁面 + 屬性 | 原生 WBS 字典欄位 |
| 適合團隊規模 | 5-200 人 | 5-100 人 | 1-30 人 | 20-500 人 |
| 費用 | 約 NT$400/人/月起 | 免費方案可用，進階約 NT$250/人/月起 | 免費方案可用 | 約 NT$1,000/人/月 |
| 學習曲線 | 低（拖拉操作） | 中（功能多需探索） | 低（但需自行建結構） | 高（企業級工具） |
| 版本追蹤 | 自動活動日誌 | 自動歷史紀錄 | 頁面歷史紀錄 | 基準比較功能 |
| 自動化通知 | ✅ 內建 | ✅ 內建 | ⚠️ 需搭配整合 | ⚠️ 需搭配 Teams |
| 開始使用 | 免費試用 → | 免費試用 → | 免費使用 → | — |
我們團隊的實際選擇是 monday.com。 原因很具體：我們需要為每個工作包設定自訂欄位（對應字典的 10 個欄位），同時需要自動化功能——例如，當某個前置工作包標記為「完成」時，自動通知下一個工作包的負責人可以開始作業。這個自動化規則在 6 個月內觸發了超過 40 次，每次都省去了 PM 手動追蹤和通知的時間。（推薦試試 monday.com 的免費方案，不需要信用卡就能開始。）
你是哪種團隊？工具選擇指南
- 5 人以下、剛開始接觸專案管理：先用 Google Sheets 或 Notion 免費版，把字典的習慣建立起來
- 5-15 人跨部門協作：monday.com 是我們的首選，自訂欄位和自動化通知能解決跨部門溝通的痛點
- 技術團隊跑 Scrum：ClickUp 的 Sprint 功能可以和 WBS 字典整合使用
- 15 人以上的大型專案：monday.com 企業方案或 MS Project，視現有工具生態系決定
WBS 字典與 Agile 方法論的關係
如果你的團隊採用 Agile 或混合式方法論，你可能會問：「我們跑 Scrum，還需要 WBS 字典嗎？」
答案是：純 Agile 環境通常不使用 WBS 字典，因為 Product Backlog 和 User Story 已經扮演了類似的角色。但在以下情境中，WBS 字典仍然有價值：
- 混合式專案：前期規劃用瀑布式（需要 WBS 字典），開發階段用 Agile
- 固定範疇合約：客戶要求明確的工作分解和交付物定義
- 跨團隊大型專案：即使各團隊內部跑 Agile，團隊之間的介面仍需要 WBS 字典來定義邊界
我們團隊在執行一個混合式的產品開發專案時，就是用 WBS 字典定義各團隊的交付邊界，團隊內部則用 Sprint Backlog 管理日常工作。這種做法兼顧了高層的可見性和團隊的靈活性。
如果你對 Agile 方法論有興趣，可以透過 Coursera 的專案管理課程深入學習。
結論
WBS 字典看起來是一份「額外的文件」，但它解決的是專案管理中最根本的問題——確保每個人對「要做什麼、做到什麼程度」有一致的理解。
本文重點回顧：
- WBS 字典是 WBS 圖表的補充文件，圖表展示結構，字典說明細節
- 10 個標準欄位中，工作說明和驗收標準是最關鍵的兩個，也是最常被忽略的
- 撰寫流程 5 步驟：分解 WBS → 建立條目 → 與負責人確認 → 設定驗收標準 → 版本控制
- 驗收標準必須可量化：從「負責行銷」改寫為「撰寫 3 篇 1,500 字文章，於 5/15 前完成」
- 工具選擇依團隊規模：小團隊用 Sheets/Notion，中型團隊用 monday.com，大型專案用企業級工具
你的下一步行動：選一個目前正在進行的專案，挑出 3 個最重要的工作包，用本文的範本格式撰寫字典條目。從 3 個開始，不要一次寫完全部——先建立習慣，再逐步擴展。
想把這篇文章的方法論付諸實踐？第一步：在 monday.com 用WBS 範本建立新看板，為每個工作包新增自訂欄位，10 分鐘就能建好你的第一份 WBS 字典框架。免費方案不需要信用卡。
WBS 字典常見問題
WBS 字典一定要做嗎？小專案也需要嗎？
不是每個專案都需要完整的 WBS 字典。判斷標準：當工作包超過 10 個、涉及跨部門協作、或有外部廠商參與時，強烈建議建立。5 個工作包以下的小專案，用口頭溝通加上簡單的任務描述通常就夠了。
WBS 字典應該由誰來寫？
PM 主導架構和格式，工作包負責人填寫具體細節（工作說明、資源需求），PM 最後審核驗收標準和整體一致性。千萬不要由 PM 一個人閉門造車——執行者最了解實際需要什麼。
專案執行中途可以修改 WBS 字典嗎？
可以，但必須走變更管理流程。記錄修改日期、修改人、修改原因，並保留前一版本。重大範疇變更（如新增或刪除工作包）需要利害關係人核准。
WBS 字典和工作說明書（SOW）有什麼不同？
SOW 是對外文件，用來與客戶或廠商約定合約範疇；WBS 字典是對內文件，用來指導執行團隊。同一個工作項目可能同時出現在兩份文件中，但 WBS 字典的細節程度通常更高。如果你需要撰寫 SOW，可以參考 ClickUp 的 SOW 範本。
WBS 字典要多詳細才夠？
實務原則：讓一個不熟悉專案的新成員，讀完某個工作包的字典條目後，能獨立理解該工作包的範疇、交付物和完成標準。如果新成員讀完還需要問 3 個以上的問題才能開始工作，代表你的字典還不夠詳細。
Agile 團隊需要 WBS 字典嗎？
純 Agile 團隊通常以 Product Backlog 和 User Story 取代 WBS 字典。但混合式方法論（前期瀑布 + 開發 Agile）、固定範疇合約、或跨團隊大型專案中，WBS 字典仍然是定義團隊交付邊界的重要工具。
