【WBS 是什麼】工作分解結構完整教學

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

編輯精選工具monday.com編輯首選時程、任務、進度放在同一個看板上，團隊不用再追 Excel 版本。

甘特圖、看板、時間軸——同一個專案三種視圖切換自動化提醒與指派——進度不用手動更新繁體中文介面免費方案永久使用，不需信用卡250,000+ 團隊使用 · 14 天免費試用全部功能免費建立第一個專案看板 →ClickUp

任務、文件、白板、OKR 放在同一個平台

免費試用Notion

文件、資料庫與專案看板同一個工作區

免費試用

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

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

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

monday.com的WBS 模板，可以輔助你進行WBS 工作分解工作。來源：monday WBS

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

WBS 的 3 大核心組成

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

專案交付物（Deliverables）：專案完成後要交出的最終產品、結果或服務，例如一套新的軟體系統、一棟建築物、一份市場研究報告。

工作包（Work Packages）：為了產出交付物所需的具體工作單元。每個工作包都要小到能被單獨規劃、指派、執行與追蹤。

工作活動（Activities）：完成工作包所需執行的具體步驟，例如工作包「建築設計」底下的「初步設計」「詳細設計」「設計審查」。

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

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

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

任務擁有者：明確指定負責人，責任落到個人，避免互相推諉。

任務預算：分配對應的資源與成本，避免超支。

完成日期：設定截止日，方便判斷是否落後。

任務狀態：定期更新進度（未開始／進行中／已完成／延遲），讓監控有依據。

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

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

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

▲ WBS 7 大核心用途

明確定義專案範圍：每個工作包都是範圍的一部分，把它們加總起來，就是專案「該做的所有事」的完整清單。哪些不在清單上，就不該做——這是控制範疇蔓延最有力的工具。

作為規劃基礎：WBS 是所有後續規劃的地基。有了工作包，你才估得出各項的資源規劃 5 步驟流程與人力配置，並逐項累加出整體預算。這一段也直接連到專案成本管理教學——沒有 WBS，成本估算就只能靠拍腦袋。

分配任務責任：每個工作包都能指派給一位負責人，責任邊界清楚。想更進一步釐清「誰負責、誰核准、誰被諮詢、誰被告知」，可以把 WBS 搭配 RACI 職責分配矩陣完整教學一起用。

追蹤與監控進度：把每個工作包的實際進度對照計劃進度，落後的地方一眼就看得到，不用等到週會才發現。

降低專案風險：把大專案拆小之後，潛在問題會提早浮現。搭配風險管理機制，就能在小問題擴大前處理掉。

促進團隊溝通：WBS 是視覺化的共同語言，讓團隊、客戶與利害關係人對「專案包含什麼、進行到哪」有一致的理解。

作為品質檢查機會：每個工作包的完成，都是一次品質查核點，可以確保專案的每一部分都符合品質標準；一個個工作包驗過去，累積起來就提高了整體專案的品質。

monday.com 的WBS 模板。來源：monday.com

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

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

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

▲ 商業建築專案 WBS 層級

第一層：專案層

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

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

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

第三層：工作包

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

ClickUp 範本庫

第四層及以下（任務）

工作包還可以繼續往下拆成更細的專案流程任務。例如「建築設計」工作包可以拆成「初步設計」「詳細設計」「設計審查」。要拆到第幾層，取決於你需要多細的控制——夠細到每一塊都能被規劃與追蹤即可，但別過度分解，否則管理成本會反過來吃掉效率。腦力激盪拆解時，也可以先用心智圖法拆解專案結構發散，再收斂成正式的 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 依「用什麼當作分解主軸」可分成四種類型。搞懂差異，你才不會硬套錯的結構。

ClickUp 的專案範圍白板範本：先用便利貼列出目標、交付物與排除項目，再往下拆成交付物導向的 WBS。來源：ClickUp

交付物導向（Deliverable-Oriented）：以專案的交付物為主軸，先確定主要交付物，再往下拆成子交付物與工作包。這是最常見、也最被推薦的類型，因為它最不容易漏掉「該交出的東西」。你可以用 ClickUp 的清單與子任務快速搭出這種結構。

活動導向（Activity-Oriented）：以工作或活動為主軸。對重複性、操作導向的專案更順手，但風險是容易只顧著「做動作」而忽略「該交付什麼」。

組織導向（Organization-Oriented）：以參與的組織或團隊為主軸，先列出各團隊，再為每個團隊指派交付物與工作包。適合責任分工明確的專案。

混合型（Hybrid）：結合上述類型，例如先用交付物拆解，再為每個交付物指派負責的團隊。大型複合專案幾乎都會用到混合型。

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

你的專案類型

建議 WBS 類型

為什麼適合

軟體開發、新品上市

交付物導向

以最終產出為核心，範圍最不易遺漏

維運、重複性專案

活動導向

流程固定，用活動排列更直覺

矩陣型組織

組織導向

責任歸屬清楚，方便跨部門分工

大型複合專案

混合型

同時兼顧交付物與組織責任

▲ 如何選擇 WBS 類型

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

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

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

▲ 建立 WBS 6 步驟

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

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

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

使用Notion 來設定你的KPI。來源：Notion KPI

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

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

Notion試用 Notion AI——摘要、翻譯、寫作輔助直接在筆記裡用（付費方案內含）

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

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

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

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

使用 Typeform 來一鍵設計你的問卷。來源：Typeform

第四步：建立 WBS 圖

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

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

選擇一個你喜歡的模板來創建WBS。來源：ClickUp

第五步：分配責任

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

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

第六步：評估與驗證 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 定義「做什麼」，但要落地執行，還得搭配呈現「什麼時候做、做到哪」的視圖。先用一張表看懂各視圖的分工：

視圖類型

搭配用途

適合情境

甘特圖

排時程、標依賴關係、看關鍵路徑

有明確前後順序的專案

時間軸

快速視覺化各任務的時間段落

需要向團隊同步整體節奏

行事曆

對齊截止日與里程碑

期限導向、需求盯 deadline

看板

追工作狀態、限制在製品（WIP）

迭代式、狀態流轉頻繁的團隊

搭配甘特圖／時間軸

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

促進跨部門或跨團隊協調：甘特圖把每個工作包的負責團隊與時程攤在同一張圖上，誰要在什麼時間交出什麼、誰在等誰的產出，一目了然，跨部門協調不必來回開會確認。

更有效地處理變更請求：當某個工作包的時程或範圍要變動，甘特圖的依賴關係會立刻顯示它會連帶影響哪些後續任務，讓你評估變更衝擊、重新安排時更有依據。

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

提高溝通效率：把所有工作包的時間段落視覺化在一條軸上，團隊與利害關係人一眼就能掌握專案的整體進程，不必逐項口頭說明。

監控和控制專案進度：把實際進度對照時間軸上的計劃進度，落後的區段馬上浮現，方便及時介入調整。

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

▲ 從 WBS 到時間軸 4 步驟

monday.com的甘特圖工具。來源：Gantt Software | monday.com

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

搭配行事曆

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

提早識別風險和問題：當某個關鍵任務在行事曆上被標記為延遲，你會立刻看到它牽動的後續任務——例如「設計審查」晚了兩天，緊接著的「開發」「測試」全部往後順延，交付日期可能因此跳票。把這種連鎖反應提早攤在行事曆上，就能在問題擴大前重新調度。

促進團隊協作：所有人共用同一份行事曆，誰在什麼時間點該交付什麼、彼此的工作如何銜接，都清清楚楚，減少因資訊落差造成的等待與重工。

搭配看板

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

用 WIP 限制促進聚焦：替「進行中」這一欄設定在製品（WIP）上限，強制團隊一次只專注處理少數幾個工作包，做完一張才能再拉一張進來，避免同時開太多任務、每件都做一半卻什麼都交不出來。

支援迭代進行：待辦、進行中、已完成三欄的流動，讓團隊能以小批量、持續交付的方式推進工作，一個工作包完成就馬上流到下一階段，特別適合需求會隨進度不斷調整的專案。

monday.com的看板工具。來源：monday.com Kanban

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

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

比較項目

工作分解結構 WBS

甘特圖 Gantt Chart

定義

把專案拆成更小、可管理的工作包

繪製任務的開始與結束日期

主要目的

定義並組織「所有工作內容」

視覺化「時間規劃」

呈現方式

樹狀圖，節點是工作包／任務

橫條圖，長度代表持續時間

時間因素

本身不含時間

時間就是核心

依賴關係

不直接表示

明確標示任務先後依賴

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

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

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

工具

免費方案

WBS 呈現方式

適合對象

monday.com

提供永久免費方案（席次／看板數有限，詳見官網）

看板欄位＋子項目層級，可切甘特圖

5–15 人跨部門團隊（我們的首選）

ClickUp

Free Forever 永久免費（免費空間有限）

清單／看板／甘特圖多視圖＋子任務

技術團隊、跑 Sprint 的專案

Notion

個人版永久免費

頁面巢狀＋資料庫欄位

新創、小團隊、想把文件和 WBS 放一起

Miro

3 個可編輯白板永久免費

無限畫布拖拉樹狀圖

需要視覺化腦力激盪的團隊

monday.com

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

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

monday.com：群組是階段、每列是工作包，「現有網站問題分析」旁的 2 是子項目

推薦工具 · 聯盟連結

monday

250,000+ 團隊在用

monday.com｜一張看板管好任務、負責人與期限

免費版永久使用 + 14 天 Pro 試用——試用期間甘特圖、時間軸、自動化全開，200+ 範本直接套用，10 分鐘就能開第一個專案

看板、甘特圖、時間軸三種視圖（甘特圖為 Standard 方案起）自動化到期提醒、指派通知、狀態同步（Standard 起 250 次/月）200+ 範本：專案進度、週報、需求清單直接套用整合 Gmail、Slack、Zoom——進度不用到處問

免費建立第一個專案看板 →

免費版 2 人永久使用 · 不需信用卡 · 250,000+ 團隊在用

ClickUp

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

ClickUp WBS模板。來源：ClickUp

Notion

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

Notion WBS 模板。來源：Notion WBS

Miro

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

Miro WBS模板。來源：Work Breakdown Structure (WBS) Template | Miro

你是哪種團隊？ 下面的分界主要參考各家免費方案的席次上限，以及團隊規模變大後對跨部門協作、權限管理的需求遞增——人數少時免費方案通常就夠用，人數越多、協作越複雜，就越需要付費方案的管理功能。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 可以這樣拆：

▲ 網站開發專案 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 工作分解結構範本（Excel）

三層階層式 WBS 表，含 WBS 編號、負責人、預估工時、前置作業與狀態下拉選單，另附填寫說明（100% 原則、8–80 小時工作包）。輸入 Email，下載連結立即寄到你的信箱；之後每週會收到實用的工具與範本精選，隨時可退訂。

寄給我範本

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

WBS 中文＝工作分解結構，核心是把大專案依交付物層層拆成可管理的工作包，包含 3 大組成（交付物、工作包、活動）＋4 項輔助欄位。

6 步驟：定義範圍→識別階段與交付物→細分工作包→建立 WBS 圖→分配責任→評估驗證。

3 大原則：100% 規則（涵蓋全部範圍）、MECE（不重疊不遺漏）、工作包套 8–80 小時法則。

4 種分解方法：由上而下、由下而上、類比、腦力激盪，實務上混用。

工具搭配：WBS 定義「做什麼」，甘特圖／看板／行事曆負責「何時做、做到哪」。

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

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

推薦工具 · 聯盟連結

monday

250,000+ 團隊在用

monday.com｜一張看板管好任務、負責人與期限

免費版永久使用 + 14 天 Pro 試用——試用期間甘特圖、時間軸、自動化全開，200+ 範本直接套用，10 分鐘就能開第一個專案

看板、甘特圖、時間軸三種視圖（甘特圖為 Standard 方案起）自動化到期提醒、指派通知、狀態同步（Standard 起 250 次/月）200+ 範本：專案進度、週報、需求清單直接套用整合 Gmail、Slack、Zoom——進度不用到處問

免費建立第一個專案看板 →

免費版 2 人永久使用 · 不需信用卡 · 250,000+ 團隊在用

電子報 · 每週二工具更新得比文章快《借力 Lever Stack》每週二整理 AI 與生產力工具的新功能與省時做法——5 分鐘讀完，隨時退訂。免費訂閱由《借力 Lever Stack》每週電子報寄送 · 隨時可退訂

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 再把它拆成怎麼做。

專案經理 PM 編輯部

專案經理 PM 編輯部 — 專案管理教學、Excel／PDF 範本與工具比較。文章標示發佈日期與更新版本；內容有誤，附上網址與段落告訴我們，核對後更正。

評測方法論 →回報更正 →