【WBS 是什麼】工作分解結構完整教學｜6步驟＋範本

WBS（Work Breakdown Structure，中文為「工作分解結構」）是一種把大型專案依交付成果層層拆解成可管理「工作包」的專案管理工具。 本文完整教學 WBS 的 3 大核心組成、6 步驟建立流程、3 大設計原則與 4 種分解方法，附 4 款工具比較表與 Excel 範本欄位，並用網站開發實例帶你從零拆解專案。

WBS 是什麼？WBS 中文、意思與 3 大核心組成一次搞懂

WBS 是「Work Breakdown Structure」的縮寫，WBS 中文就是「工作分解結構」——一種在專案管理中最基礎、也最常被使用的規劃工具。它的意思很單純：把一個龐大、複雜、看起來無從下手的專案，依照「交付成果」的邏輯層層往下拆，直到每一塊都小到可以指派給一個人、估得出工時、追蹤得到進度為止。這些被拆到最底層、可獨立管理的最小單位，就叫做「工作包（Work Package）」。

WBS 只回答一個問題：「這個專案到底包含哪些工作？」而不談「什麼時候做」——時間安排是甘特圖的事，後面章節會說明兩者差異。

想省下自己畫樹狀圖的時間，可以直接套用 monday 的 WBS 模板，把每個工作包當成一列任務往下展開就好。

WBS 的 3 大核心組成

一份合格的 WBS，一定要標示出這三個層次的內容：

• 專案交付物（Deliverables）：專案完成後要交出的最終產品、結果或服務，例如一套新的軟體系統、一棟建築物、一份市場研究報告。
• 工作包（Work Packages）：為了產出交付物所需的具體工作單元。每個工作包都要小到能被單獨規劃、指派、執行與追蹤。
• 工作活動（Activities）：完成工作包所需執行的具體步驟，例如工作包「建築設計」底下的「初步設計」「詳細設計」「設計審查」。

這三者是 WBS 圖上「必須畫出來」的骨架，缺一個，這份 WBS 就不完整。

4 項輔助欄位：讓 WBS 從「清單」變「可管理」

光有骨架還不夠。實務上，每個工作包還要補上四項資訊，才能真正拿來管理：

• 任務擁有者：明確指定負責人，責任落到個人，避免互相推諉。
• 任務預算：分配對應的資源與成本，避免超支。
• 完成日期：設定截止日，方便判斷是否落後。
• 任務狀態：定期更新進度（未開始／進行中／已完成／延遲），讓監控有依據。

這四項通常不會全部畫進 WBS 樹狀圖裡（否則資訊爆炸、反而看不懂），而是以批註、欄位，或一份獨立的「WBS 字典」來記錄。如果你想知道每個工作包該記錄哪些欄位、怎麼寫才完整不遺漏，可以參考我們整理的 WBS 字典撰寫教學，那篇專文把 10 大欄位與 3 種產業範例逐項拆給你看。

WBS 7 大核心用途｜為什麼專案經理都靠它管理專案

WBS 之所以被幾乎每一位專案經理當成規劃起點，是因為它一次解決了 7 個問題：

• 明確定義專案範圍：每個工作包都是範圍的一部分，把它們加總起來，就是專案「該做的所有事」的完整清單。哪些不在清單上，就不該做——這是控制範疇蔓延最有力的工具。
• 作為規劃基礎：WBS 是所有後續規劃的地基。有了工作包，你才估得出各項的資源規劃 5 步驟流程與人力配置，並逐項累加出整體預算。這一段也直接連到專案成本管理教學——沒有 WBS，成本估算就只能靠拍腦袋。
• 分配任務責任：每個工作包都能指派給一位負責人，責任邊界清楚。想更進一步釐清「誰負責、誰核准、誰被諮詢、誰被告知」，可以把 WBS 搭配 RACI 職責分配矩陣完整教學一起用。
• 追蹤與監控進度：把每個工作包的實際進度對照計劃進度，落後的地方一眼就看得到，不用等到週會才發現。
• 降低專案風險：把大專案拆小之後，潛在問題會提早浮現。搭配風險管理機制，就能在小問題擴大前處理掉。
• 促進團隊溝通：WBS 是視覺化的共同語言，讓團隊、客戶與利害關係人對「專案包含什麼、進行到哪」有一致的理解。
• 作為品質檢查機會：每個工作包的完成，都是一次品質查核點，可以確保專案的每一部分都符合品質標準；一個個工作包驗過去，累積起來就提高了整體專案的品質。

一句話總結：WBS 不只是一張分解圖，它是範圍、資源、責任、進度、風險、溝通與品質這七件事的共同起點。

WBS 3 大層級＋編號系統｜1.1.1 怎麼編、工作包切多細

WBS 沒有固定的層級數量，深度取決於專案的規模與複雜度。但為了方便理解，我們用最經典的商業建築案例，把它拆成三個主要層級，再加上第四層以下的任務。

第一層：專案層

最高層就是整個專案，屬於摘要級別，代表專案的總體目標與範圍。以商業建築為例，這一層可能只寫「新商業建築專案」。

第二層：主要交付物或階段

第二層把專案拆成主要的交付物或階段，每一塊都有自己的目標。商業建築的例子中，這一層可能是「設計」「施工」「專案關閉」。

第三層：工作包

第三層把每個主要交付物再拆成工作包，也就是需要被完成、才能產出交付物的具體工作。例如「設計」階段可以拆成「建築設計」「電氣設計」「管道設計」。

第四層及以下（任務）

工作包還可以繼續往下拆成更細的專案流程任務。例如「建築設計」工作包可以拆成「初步設計」「詳細設計」「設計審查」。要拆到第幾層，取決於你需要多細的控制——夠細到每一塊都能被規劃與追蹤即可，但別過度分解，否則管理成本會反過來吃掉效率。腦力激盪拆解時，也可以先用心智圖法拆解專案結構發散，再收斂成正式的 WBS 樹狀圖。

WBS 編號系統怎麼編？1.1、1.1.1 的邏輯

很多人畫完 WBS 卻不知道怎麼幫工作包編號。其實規則非常直觀，用「階層小數點」表示父子關係即可：

• 第一層：整個專案編號為 1。
• 第二層：往下依序 1.1、1.2、1.3……每個都是專案 1 的子項。
• 第三層：在 1.1 底下的工作包編為 1.1.1、1.1.2、1.1.3……
• 第四層：再往下就是 1.1.1.1、1.1.1.2，以此類推。

小數點的位數＝這個項目的層級深度。看到編號就知道它在樹的哪一層、屬於誰的下面，這也是後續對照甘特圖、預算表、追蹤表時最好用的唯一識別碼。

工作包要切多細？用 8–80 小時法則判斷。 這是實務上最常用的標準：一個工作包的預估工時，落在 8 到 80 小時（大約一個工作天到兩個工作週）之間最理想。低於 8 小時，代表你拆太細、管理負擔太重；超過 80 小時，代表這塊太大、風險藏在裡面看不到，該再往下拆一層。另一個檢核點是「一份狀態報告週期」——如果一個工作包跨越好幾次進度回報都還做不完，通常就是切太粗了。

WBS 4 大類型解析｜如何選出最適合你專案的分解方式

WBS 依「用什麼當作分解主軸」可分成四種類型。搞懂差異，你才不會硬套錯的結構。

• 交付物導向（Deliverable-Oriented）：以專案的交付物為主軸，先確定主要交付物，再往下拆成子交付物與工作包。這是最常見、也最被推薦的類型，因為它最不容易漏掉「該交出的東西」。你可以用 ClickUp 的清單與子任務快速搭出這種結構。
• 活動導向（Activity-Oriented）：以工作或活動為主軸。對重複性、操作導向的專案更順手，但風險是容易只顧著「做動作」而忽略「該交付什麼」。
• 組織導向（Organization-Oriented）：以參與的組織或團隊為主軸，先列出各團隊，再為每個團隊指派交付物與工作包。適合責任分工明確的專案。
• 混合型（Hybrid）：結合上述類型，例如先用交付物拆解，再為每個交付物指派負責的團隊。大型複合專案幾乎都會用到混合型。

如何選？對照你的專案類型直接套

如果你的團隊跑的是敏捷式 Sprint 開發流程，交付物導向的 WBS 也能和 Backlog、Sprint 規劃無縫接上——把交付物對應成 Epic，工作包對應成 Story，邏輯是一致的。

6 步驟建立 WBS｜含 100% 原則、MECE 原則與 4 種分解方法

這是整篇的核心。建立 WBS 通常拆成 6 個步驟，我在每一步都標出「什麼情況最容易出錯」，這是新手最常踩的坑。

第一步：定義專案目標與範圍

先把目標寫清楚，最好符合 SMART 目標並對應到可衡量的 KPI，後面追蹤才有依據。

容易出錯：範圍沒定義清楚就急著拆，結果 WBS 越拆越發散，最後長出一堆不在原始目標裡的工作。

第二步：識別主要階段與交付物

把專案拆成主要階段或交付物。以開發網站為例，可能是「需求收集」「設計」「開發」「測試」「部署」。

容易出錯：把「階段」和「交付物」混在同一層，導致第二層邏輯不一致、之後對不齊。同一層請維持同一種分解邏輯。

第三步：細分工作包與任務

把每個階段再拆成可獨立完成的工作包，例如「需求收集」拆成「識別利害關係人」「設計問卷」「進行訪談」。做問卷這類任務可以用 Typeform 快速產出、一鍵分享。

容易出錯：這是新手最常翻車的一步——工作包切太粗，導致無法指派也追蹤不到；或切太細，反而把管理時間都吃光。判斷標準回到前面的 8–80 小時法則，並搭配工時估算 3 大方法交叉驗證。

第四步：建立 WBS 圖

用工具把結構畫成樹狀圖：專案是樹根，往下是階段／交付物、工作包，最後是任務。畫圖的同時就能順手排出依賴關係，接到專案時間表 5 步驟建立教學。

容易出錯：一開始就在 Excel 硬畫樹狀圖，改一次就整張跑版。用專案管理工具的內建層級結構會省下大量調整時間。

第五步：分配責任

為每個工作包指派負責人。責任落到個人，工作才不會懸空。

容易出錯：一個工作包掛兩個以上「共同負責人」而沒指定主責——出事的時候誰都以為對方會處理。

第六步：評估與驗證 WBS

最後檢查：每項工作都被涵蓋了嗎？每個工作包都對應得到一項交付物或目標嗎？和專案範圍一致嗎？利害關係人有共識嗎？

容易出錯：驗證只找自己人看。跳過關鍵利害關係人的確認，等執行到一半才發現漏了一大塊交付物。

WBS 設計三大原則（用網站開發範例對照）

• 100% 規則：WBS 必須涵蓋專案範圍的 100%，每一層子項加總，剛好等於上一層。以網站專案為例，1.1～1.7（專案計劃、需求分析、設計、開發、測試、部署、專案結束）加起來，就是整個「開發新網站」；沒被列進來的工作，就不該做。
• MECE 原則：每一層必須「互相排斥、完全窮盡」（Mutually Exclusive, Collectively Exhaustive）。同一件事只能出現在一個工作包裡。例如「編寫程式碼」和「建立資料庫」不重疊、不遺漏，才符合 MECE。
• 工作包規模：每個工作包要小到能被單獨規劃、執行、控制，套用 8–80 小時法則。若「設計界面」估出來要 200 小時，代表它太大，該再往下拆成「線框圖」「視覺稿」「切版」。

常見的 4 種分解方法（回答「工作分解主要有哪四項方法」）

很多人問「工作分解主要有哪四項方法」——注意，這問的是「怎麼拆」的方法，不是上一章的「類型」。實務上最常用這四種：

• 由上而下法（Top-Down）：從整個專案出發，先定大階段，再逐層往下拆。範圍清楚、有經驗的專案最適合。
• 由下而上法（Bottom-Up）：先讓團隊列出所有想得到的具體任務，再往上歸類成工作包與階段。適合創新、範圍還不明朗的專案。
• 類比法（Analogy）：拿過去類似專案的 WBS 當範本改，速度最快，最適合重複性高的專案。
• 腦力激盪法（Brainstorming）：全員一起發散，把便利貼或心智圖上的點子收斂成 WBS。適合跨部門、需要集思廣益的專案。

實務上這四種常混用：先由上而下搭骨架，再由下而上補細節，同時參考歷史類比範本，缺口用腦力激盪補齊。

WBS 搭配甘特圖、看板、行事曆｜4 種工具整合比較表

WBS 定義「做什麼」，但要落地執行，還得搭配呈現「什麼時候做、做到哪」的視圖。先用一張表看懂各視圖的分工：

搭配甘特圖／時間軸

把 WBS 拆出來的工作包放上甘特圖或時間軸，就能排出開始／結束日期與依賴關係，並看出哪些是關鍵路徑。除了排時程，甘特圖還有兩個常被忽略的作用：

• 促進跨部門或跨團隊協調：甘特圖把每個工作包的負責團隊與時程攤在同一張圖上，誰要在什麼時間交出什麼、誰在等誰的產出，一目了然，跨部門協調不必來回開會確認。
• 更有效地處理變更請求：當某個工作包的時程或範圍要變動，甘特圖的依賴關係會立刻顯示它會連帶影響哪些後續任務，讓你評估變更衝擊、重新安排時更有依據。

時間軸的重點則在「向團隊同步整體節奏」：

• 提高溝通效率：把所有工作包的時間段落視覺化在一條軸上，團隊與利害關係人一眼就能掌握專案的整體進程，不必逐項口頭說明。
• 監控和控制專案進度：把實際進度對照時間軸上的計劃進度，落後的區段馬上浮現，方便及時介入調整。

想更嚴謹地估算含不確定性的時程，可以再疊上 PERT 時程分析的三點估算法。整個流程可以濃縮成四步：

（想省下自己畫樹狀圖的時間？可以先試 monday.com 的免費方案，看板內建層級結構，拆完直接切換成甘特圖檢視。）

搭配行事曆

把工作包的截止日丟進時間排程行事曆，每個人都能清楚看到自己這週該交什麼。行事曆最大的好處是把「抽象的工作包」變成「具體的日期」，deadline 一到自動提醒。它還帶來兩個管理上的好處：

• 提早識別風險和問題：當某個關鍵任務在行事曆上被標記為延遲，你會立刻看到它牽動的後續任務——例如「設計審查」晚了兩天，緊接著的「開發」「測試」全部往後順延，交付日期可能因此跳票。把這種連鎖反應提早攤在行事曆上，就能在問題擴大前重新調度。
• 促進團隊協作：所有人共用同一份行事曆，誰在什麼時間點該交付什麼、彼此的工作如何銜接，都清清楚楚，減少因資訊落差造成的等待與重工。

搭配看板

把每個工作包當成一張卡片放上看板，用「待辦／進行中／已完成」三欄流轉，卡片從左往右移動，狀態一目了然，不用開口問就知道每件事進行到哪。看板特別適合迭代式的排程節奏，它有兩個關鍵機制：

• 用 WIP 限制促進聚焦：替「進行中」這一欄設定在製品（WIP）上限，強制團隊一次只專注處理少數幾個工作包，做完一張才能再拉一張進來，避免同時開太多任務、每件都做一半卻什麼都交不出來。
• 支援迭代進行：待辦、進行中、已完成三欄的流動，讓團隊能以小批量、持續交付的方式推進工作，一個工作包完成就馬上流到下一階段，特別適合需求會隨進度不斷調整的專案。

WBS ≠ 甘特圖：別再搞混這兩個

最後提醒：WBS 和甘特圖經常一起用，但本質完全不同，別弄錯。

正確的用法是：先用 WBS 定義並組織所有工作，再用甘特圖把這些工作排上時程。

WBS 工具推薦｜4 款軟體比較＋Excel 範本這樣建

WBS 可以用 Excel 畫，但只要牽涉到團隊協作、版本追蹤、與其他專案文件連動，用專業的 WBS 工具會省下大量時間。下面比較 4 款主流工具，先看總覽再看細節。各家差異也可對照專案管理工具的完整整理。

monday.com

monday.com 是我們的首推工具。它用彈性看板來建立與視覺化 WBS：每個工作包就是一列任務，往下展開子項目就是層級結構，欄位可自訂負責人、狀態、優先級、預算與截止日，等於把前面提到的「3 大組成＋4 項輔助欄位」一次全裝進去。做完 WBS 後，同一份資料能無縫切換成甘特圖、時間軸、行事曆、看板，不用重建。

實際用起來最省事的是自動化：monday.com 提供延遲自動通知等自動化規則，可以讓落後在擴大前就被抓出來，不用等週會（可設定的觸發條件與細節請至官網查看最新方案）。它也有永久免費方案且不需要信用卡（席次與看板數量有限，詳細請見官網最新方案），先拿一個小專案試拆最沒壓力。

ClickUp

ClickUp 是第二推薦，特別適合技術導向團隊。它提供清單、看板、甘特圖、時間軸多視圖，並用子任務＋檢查清單把工作包再往下拆。跑 Scrum 的團隊會喜歡它把 Sprint、任務、文件放在同一平台。它有永久免費的 Free Forever 方案，也提供 Unlimited、Business 等付費方案（實際價格與方案內容以官網最新公告為準）。

Notion

Notion 適合已經習慣用它寫文件的小團隊：新增一個頁面代表專案，底下用子頁面代表工作包，每頁可放任務、筆記、附件，再用資料庫做自訂的追蹤系統。好處是 WBS 和專案文件不用切換工具。要注意的是，Notion 官方的部分 WBS 專用模板屬付費項目，個人版本身則是永久免費。

Miro

Miro 是線上協作白板，無限畫布讓你自由拖拉出樹狀 WBS，搭配便利貼與豐富圖形，特別適合團隊一起腦力激盪、把發散的點子收斂成正式結構，再匯出給其他工具排程。

你是哪種團隊？ 下面的分界主要參考各家免費方案的席次上限，以及團隊規模變大後對跨部門協作、權限管理的需求遞增——人數少時免費方案通常就夠用，人數越多、協作越複雜，就越需要付費方案的管理功能。5 人以下、剛接觸專案管理，先用 Notion 免費版把架構搭起來；5–15 人跨部門協作，直接上 monday.com（我們的首選）；技術團隊跑 Scrum，選 ClickUp；15 人以上的大型專案，走 monday.com 的企業方案。

關於「WBS 模板／Excel 範本」怎麼準備：如果你堅持用 Excel，一份好用的 WBS 表至少要有這幾欄——WBS 編號、工作包名稱、負責人、預估工時、前置作業、狀態下拉選單，並在說明欄註記 100% 原則與 8–80 小時工作包的檢核標準。不過 Excel 最大的痛點是多人改一次就跑版，所以更省事的做法是直接套用上表工具的內建 WBS 範本，把 Excel 欄位對應成工具欄位就好。

想直接拿現成的 Excel WBS 範本來改？輸入 Email，下載連結立即寄到你的信箱；之後每週會收到實用的工具與範本精選，隨時可退訂。

WBS 範例｜一個網站開發專案的完整拆解教學

假設要開發一個新的公司網站，這個專案的 WBS 可以這樣拆：

1 開發新網站

• 1.1 專案計劃：1.1.1 建立專案計劃、1.1.2 獲得核准
• 1.2 需求分析：1.2.1 收集需求、1.2.2 編寫需求規格、1.2.3 獲得核准
• 1.3 網站設計：1.3.1 建立網站架構、1.3.2 設計界面、1.3.3 獲得核准
• 1.4 網站開發：1.4.1 編寫程式碼、1.4.2 建立資料庫
• 1.5 運行測試：1.5.1 執行單元測試、1.5.2 執行整合測試、1.5.3 執行使用者驗收測試
• 1.6 部署：1.6.1 部署到生產環境、1.6.2 進行性能測試
• 1.7 專案結束：1.7.1 評估專案結果、1.7.2 編寫專案報告

這份 WBS 把專案拆成 7 個主要階段，每個階段再拆成具體任務。回頭驗證一下：1.1～1.7 加總剛好涵蓋整個網站專案（100% 原則），各工作包彼此不重疊（MECE），編號一看就知道父子關係——這就是一份合格的 WBS。順帶一提，這裡的「獲得核准」出現在多個階段，正是把利害關係人的確認點編進 WBS 的好做法；若要進一步做關鍵路徑與時程分析，可搭配 PERT 專案時程分析。

結論：把 WBS 從概念變成你手上的第一張圖

• WBS 中文＝工作分解結構，核心是把大專案依交付物層層拆成可管理的工作包，包含 3 大組成（交付物、工作包、活動）＋4 項輔助欄位。
• 6 步驟：定義範圍→識別階段與交付物→細分工作包→建立 WBS 圖→分配責任→評估驗證。
• 3 大原則：100% 規則（涵蓋全部範圍）、MECE（不重疊不遺漏）、工作包套 8–80 小時法則。
• 4 種分解方法：由上而下、由下而上、類比、腦力激盪，實務上混用。
• 工具搭配：WBS 定義「做什麼」，甘特圖／看板／行事曆負責「何時做、做到哪」。

想把方法論立刻付諸實踐？第一步：打開 monday.com，用內建的 WBS 模板建立新看板，把專案填進第一層、往下展開工作包、指派負責人與截止日，很快就能完成你的第一份工作分解結構。它的免費方案不需要信用卡，跨團隊即時協作、拆完直接切甘特圖，比在 Excel 畫樹狀圖省事太多，是我們日常管理專案時最順手的起點。

如果讀完還有任何疑問，或想針對自己的專案討論怎麼拆，別害羞——訂閱我們的網站或在下方留言，我們會盡力幫你解答。好了，就說到這，我們下篇文章再見！

WBS 常見問題 FAQ

WBS 是什麼意思？

WBS 是 Work Breakdown Structure 的縮寫，中文為「工作分解結構」，是一種把專案的工作與交付物拆成更小、更易管理部分的專案管理工具。它以樹狀結構呈現，最底層的可管理單位稱為「工作包」，每個工作包都是專案交付結果的一部分。

工作分解主要有哪四項方法？

常用的四種分解方法是：由上而下法（從整體逐層往下拆）、由下而上法（先列具體任務再往上歸類）、類比法（沿用過去類似專案的範本）、腦力激盪法（團隊集思廣益再收斂）。實務上多半混用：先由上而下搭骨架，再由下而上補細節。

WBS 如何拆解？

依三步走：先確定專案的主要交付物；再把每個交付物拆成可獨立完成的工作包；持續往下拆到符合 8–80 小時法則、能被單獨規劃與追蹤為止。過程中隨時用 100% 原則檢查「有沒有涵蓋全部範圍」，用 MECE 原則檢查「有沒有重複或遺漏」。

WBS 的主要目的是什麼？

主要目的是幫助專案經理與團隊更有效地規劃、排程、分配資源、追蹤與控制專案。透過把大專案拆小，團隊能更清楚理解範圍與複雜度，也更容易識別與管理風險。

WBS 和甘特圖有什麼不同？

WBS 專注於「工作內容」，用樹狀圖把專案拆成工作包，本身不含時間；甘特圖專注於「時間」，用橫條圖呈現任務的起訖日期與依賴關係。兩者常一起用：先用 WBS 定義所有工作，再用甘特圖排時程。

WBS 有哪些限制？

最大的限制是，如果專案初期沒把 WBS 定義好、組織清楚，後續管理會非常吃力。此外，WBS 需要隨專案變化不斷更新，會耗費額外時間與資源。它也只回答「做什麼」，不處理時程與依賴，必須搭配其他工具才完整。

WBS 和 SOW（工作說明書）有什麼關係？

SOW（Statement of Work，工作說明書）描述專案的範圍、目標與交付內容，是「文字版」的範疇界定；WBS 則是把 SOW 所定義的範圍，進一步拆解成結構化、可執行的工作包。簡單說：SOW 先講清楚要交付什麼，WBS 再把它拆成怎麼做。