【專案規劃】6大步驟完整教學｜含WBS範例＋工具比較表

專案規劃是專案管理五大流程中的第二階段，透過定義範疇、分解工作、排定時程與分配資源，為專案建立可執行的行動藍圖。

什麼是專案規劃？定義、位置與核心輸出物

專案規劃是在專案啟動（Initiation）階段取得授權後，正式進入執行前的關鍵準備工作。它的目的是把模糊的專案目標轉化為具體、可追蹤、可執行的計劃文件，讓每個團隊成員都清楚「做什麼、誰負責、什麼時候完成」。

在 PMBOK 的專案管理流程中，規劃是五大階段的第二步：

1. 啟動（Initiation）：定義專案存在的理由，取得授權
2. 規劃（Planning）：建立完整的執行藍圖 ← 本文重點
3. 執行（Execution）：按計劃交付工作成果
4. 監控（Monitoring & Controlling）：追蹤偏差、修正方向
5. 結案（Closing）：驗收成果、歸檔經驗

一份完整的專案規劃會產出以下 5 個核心文件：

1. 範疇說明書（Scope Statement）：定義交付物、排除項目、驗收標準
2. WBS 工作分解結構：將專案分解為可管理的工作包
3. 時間表與里程碑：包含甘特圖、關鍵路徑與緩衝時間
4. 資源計劃：人力配置、預算分配、工具選擇
5. 風險登記表（Risk Register）：已識別風險、機率評估、應對策略

這些文件合在一起就是所謂的「專案計劃書」——它是規劃階段最重要的輸出物，涵蓋範疇、時間表、預算、品質標準、人員配置、溝通方式和風險應對等所有面向。規劃階段的品質直接決定專案成敗，接下來我們先從規劃前必須釐清的四大問題框架開始。

專案規劃前必須釐清的 4 大問題框架

在打開任何工具、畫任何甘特圖之前，你需要先用 Why / Who / What-How-When / Where 四個維度檢視專案。這四個問題沒有明確答案就開始規劃，等於在沙地上蓋房子。

Why — 這個專案為什麼要做？

這是最容易被跳過、卻最根本的問題。「Why」不只是「老闆說要做」，而是要釐清專案目的與組織策略的對齊關係。

舉例來說，一家化妝品公司要推出新的粉底液產品——這個專案的「Why」可能是「開拓 20–25 歲年輕族群的新市場」，也可能是「滿足現有客戶對更多色號的需求」。兩個 Why 會導致完全不同的規劃方向：前者需要投入行銷預算做市場教育，後者則著重在產品開發和供應鏈調整。

如果 Why 沒有釐清，團隊在執行過程中就會對優先順序產生分歧——行銷部門覺得應該砸預算打廣告，產品部門覺得應該先把色號做齊，最後兩邊都做了一半，什麼都沒做好。

確認 Why 之後，還要確保它與組織的策略規劃一致——如果公司今年的策略是「提高客單價」，但你的專案目標是「衝訂單量」，兩者就會產生衝突。

Who — 利害關係人是誰？團隊怎麼組？

利害關係人識別是規劃階段最容易被跳過、卻最常在執行階段引爆問題的步驟。操作上分兩步：

第一步：列出所有利害關係人清單。 不只是老闆和團隊成員，還包括會被專案成果影響的人——客服部門、法務、外部供應商、甚至終端使用者。

第二步：用影響力/關注度矩陣分類。 根據每個人對專案的「影響力」和「關注度」，決定你要花多少精力管理他們的期望：

	高關注度	低關注度
高影響力	密切管理（如：專案贊助人、部門主管）	保持滿意（如：高層主管、董事會）
低影響力	保持知情（如：終端使用者、客服團隊）	定期監控（如：其他部門同事）

這張矩陣在後續建立溝通計劃時會直接派上用場——「密切管理」的人需要每週面對面更新，「定期監控」的人可能只需要月報即可。

團隊組建方面，除了考慮專業技能，有些主管也會根據成員的 MBTI 性格特質去分配任務，讓外向型成員負責客戶溝通、細節導向的成員負責品質檢核，各展所長。這不是硬性規則，但在台灣越來越多團隊會把性格特質納入分工考量。

What-How-When — 做什麼、怎麼做、什麼時候完成？

這三個問題是規劃的核心，也是後續 6 大步驟會詳細展開的部分。在這個階段，你需要先建立初步的框架：

• What（做什麼）：定義專案的交付物和範疇邊界
• How（怎麼做）：決定方法論（瀑布式、敏捷式或混合式）和執行策略
• When（什麼時候完成）：設定里程碑和最終期限

以一個投資有限的遊戲軟體產品為例：What 可能是「開發一款手機休閒遊戲，包含 10 個關卡和基本社交功能」；How 是「用 Unity 引擎開發，採用 2 週一個 Sprint 的敏捷式流程」；When 是「3 個月內完成 Beta 版，第 4 個月上架 App Store」。這三個問題的答案會直接決定你需要多少人、多少預算、以及用什麼工具。

專案目標必須遵循「SMART」原則，才能讓團隊有明確的方向和可衡量的成果。以台灣電商團隊的雙 11 活動專案為例：

• ❌ 模糊目標：「提升雙 11 業績」
• ✅ SMART 目標：「在 11/1–11/11 期間，透過站內促銷活動與 LINE 推播，將 GMV 從去年同期的 NT$800 萬提升至 NT$1,200 萬（成長 50%），退貨率控制在 8% 以下」

這個目標是具體的（Specific：GMV 成長 50%）、可衡量的（Measurable：NT$1,200 萬）、可達成的（Achievable：基於去年數據設定）、相關的（Relevant：對應公司年度營收目標）、有時限的（Time-bound：11/1–11/11）。

Where — 在哪裡工作？用什麼工具協作？

這個問題在疫情後變得特別重要。你的團隊是全員辦公室、完全遠端、還是混合模式？不同的工作地點會直接影響溝通方式和工具選擇：

• 全員辦公室：可以依賴白板、面對面站會，工具需求較低
• 完全遠端：需要非同步溝通工具（如 Notion、Slack）和視訊會議軟體
• 混合模式：需要確保線上和線下成員的資訊同步，工具選擇最關鍵

Where 也包含「用什麼工具管理專案」——這會在後面的工具推薦章節詳細說明。重點是：工具選擇應該在規劃階段就確定，不是等到執行時才讓每個人用自己習慣的工具，最後資訊散落在 5 個不同平台。

範疇邊界：明確寫出「不做什麼」

回答完四大問題後，最後要把範疇邊界寫成正式文件。一份有效的範疇說明書必須包含三個元素：

1. 交付物（Deliverables）：專案結束時要產出什麼？例如：「完成官網改版，包含首頁、產品頁、結帳流程共 12 個頁面」
2. 排除項目（Exclusions）：明確寫出「不做什麼」。例如：「本次改版不包含 APP 介面、不包含 SEO 內容撰寫」
3. 驗收標準（Acceptance Criteria）：怎樣算「做完了」？例如：「所有頁面在 Chrome、Safari、Edge 三大瀏覽器通過 QA 測試，載入速度 ≤ 3 秒」

範疇蔓延（Scope Creep）預防提醒： 規劃階段沒有定義「排除項目」是最常見的失敗原因。當老闆在執行中途說「順便把 APP 也改一下吧」，如果範疇說明書上沒有白紙黑字寫著「APP 不在本次範疇內」，你就很難拒絕——然後時間和預算就爆了。

專案規劃 6 大步驟完整教學

回答完前面四大問題後，你已經有了目標、知道利害關係人是誰、劃定了範疇邊界、也確認了工作模式。接下來進入規劃的核心——6 個步驟，把這些資訊轉化為可執行的計劃。

步驟 1 — 建立 WBS（工作分解結構）

WBS（Work Breakdown Structure）是把整個專案從上到下拆解成更小、更容易管理的工作包。它是所有後續步驟的基礎——沒有 WBS，你無法準確估算時間、分配資源或識別風險。

以「公司官網改版」專案為例，WBS 可以分解為 3 層：

第 1 層：專案名稱

• 公司官網改版

第 2 層：主要階段

• 1.0 需求分析
• 2.0 UI/UX 設計
• 3.0 前端開發
• 4.0 測試與上線

第 3 層：工作包

• 1.1 利害關係人訪談
• 1.2 競品分析報告
• 1.3 需求規格書撰寫
• 2.1 線框圖（Wireframe）設計
• 2.2 視覺設計稿
• 2.3 設計審核與修改
• 3.1 首頁開發
• 3.2 產品頁開發
• 3.3 結帳流程開發
• 4.1 功能測試
• 4.2 跨瀏覽器相容性測試
• 4.3 正式上線部署

常見錯誤： WBS 分解太粗（整個專案只有 3 個工作包，無法準確估時）或太細（超過 5 層，管理成本比執行成本還高）。一般建議控制在 3–4 層，最底層的工作包應該是一個人在 1–2 週內可以完成的任務。

在 monday.com 上，你可以用「群組」對應 WBS 的第 2 層階段，用「項目」對應第 3 層工作包，再用子項目拆分更細的任務——整個 WBS 結構直接變成可追蹤的看板。

步驟 2 — 制定時間表與里程碑

有了 WBS 之後，下一步是為每個工作包估算時間，並設定里程碑。里程碑不是隨便挑一個日期，它必須符合 3 個標準：

1. 可驗證：有明確的完成標準（不是「差不多做好了」）
2. 有交付物：完成時會產出一份具體文件或成果
3. 代表階段完成：標誌著專案從一個階段進入下一個階段

以官網改版為例，里程碑可以是：

• M1：需求規格書簽核完成（第 2 週）
• M2：設計稿通過審核（第 5 週）
• M3：開發完成進入測試（第 9 週）
• M4：正式上線（第 11 週）

時間表最常用甘特圖來呈現，它能清楚顯示任務之間的先後關係（例如「設計稿通過審核」才能開始「前端開發」）和並行任務（例如「競品分析」和「利害關係人訪談」可以同時進行）。

在 monday.com 的時間線視圖中，你可以拖拉調整任務時間、設定任務相依性（dependency），當前置任務延遲時，後續任務會自動順延——這比手動更新 Excel 甘特圖省下大量時間。

常見錯誤： 沒有預留緩衝時間（buffer）。如果每個任務都排得剛剛好，第一個任務延遲 2 天，整條關鍵路徑就全部延遲。建議在每個階段的里程碑前預留 10–15% 的緩衝時間。更多排程技巧可以參考排程管理教學。

步驟 3 — 資源分配與 RACI 責任矩陣

資源分配要考慮兩個維度：人力（誰做）和工具/預算（用什麼做）。

人力分配最實用的工具是 RACI 矩陣，它用四個角色定義每個任務的責任歸屬：

• R（Responsible）：實際執行任務的人
• A（Accountable）：最終負責、有決策權的人（每個任務只能有一個 A）
• C（Consulted）：需要諮詢意見的人
• I（Informed）：需要被告知進度的人

以官網改版為例：

任務	PM	設計師	前端工程師	行銷主管
需求規格書	A	C	C	R
UI 設計稿	I	R	C	A
前端開發	A	C	R	I
上線部署	A	I	R	I

常見錯誤： 同一個人同時被指定為 3 個以上任務的 R（Responsible），導致資源過載。在填完 RACI 矩陣後，橫向檢查每個人的 R 數量——如果某人的 R 超過其他人的兩倍，就需要重新分配。（推薦試試 monday.com 的工作負載視圖，它能自動顯示每個成員的任務量，一眼看出誰被過度分配。）

步驟 4 — 建立溝通計劃

專案失敗最常見的原因不是技術問題，而是溝通問題。溝通計劃要在規劃階段就確定，不是等到出問題才臨時開會。

最基本的做法是預先設定固定的溝通節奏——例如每週一早上 10 點開 30 分鐘的專案進度會議，讓所有成員都能提前準備更新內容，避免臨時被抓去開會卻什麼都說不出來。

一份完整的溝通計劃至少要包含以下 5 個欄位：

利害關係人	資訊類型	頻率	管道	負責人
專案贊助人	進度摘要 + 風險警示	每週一次	面對面會議	PM
團隊成員	任務更新 + 阻礙排除	每日站會	monday.com 更新功能	Scrum Master / PM
行銷部門	上線時程 + 素材需求	每兩週一次	Email + 共享文件	PM
終端使用者代表	測試回饋收集	測試階段每週	Typeform 問卷	QA 負責人

除了例行溝通，還要預先定義升級機制（Escalation Path）：當任務延遲超過 3 天、預算超支超過 10%、或發生重大風險時，由誰在多長時間內向誰上報？這個機制不寫下來，出事時大家只會互相推諉。

步驟 5 — 風險識別與應對策略

風險管理不是等問題發生才處理，而是在規劃階段就把可能的風險攤開來，預先準備應對方案。以下是台灣專案最常見的 5 大風險類型：

風險描述	機率	影響	應對策略
需求變更（客戶/主管中途改需求）	H	H	建立變更控制流程，所有變更需書面申請並評估影響
關鍵人員離職（核心工程師離開）	M	H	確保每個關鍵任務至少有 2 人熟悉，建立知識文件
供應商延誤（外包設計公司交件遲到）	M	M	合約中加入延遲罰則，預留 1 週緩衝時間
預算凍結（公司臨時縮減預算）	L	H	規劃階段就區分「必要」和「可選」功能，預算縮減時砍可選項
技術債（舊系統整合問題）	H	M	開發前進行技術可行性評估，預留 20% 開發時間處理整合

在 ClickUp 的風險管理模板中，你可以為每個風險設定自訂欄位（機率、影響、負責人、應對策略），並用自動化規則設定：當風險狀態從「監控中」變為「已發生」時，自動通知相關負責人。

步驟 6 — 設定專案基準（Baseline）與更新機制

當以上 5 個步驟都完成後，你需要做一件很多 PM 會忽略的事：凍結基準（Baseline）。

基準是規劃完成時的「快照」——包含範疇基準、時間基準、成本基準。它的作用是在執行階段提供比較的基礎：「我們現在比原計劃快了還是慢了？超支了還是省下了？」沒有基準，你就無法衡量專案績效。

在 monday.com 中，你可以在時間線視圖中儲存基準版本，之後任何調整都會與基準對比顯示差異——紅色代表延遲，綠色代表提前。

何時應該更新計劃（而非只是追蹤偏差）？ 三種情況：

1. 範疇變更：經過正式變更控制流程核准的新增或刪除交付物
2. 重大風險發生：風險登記表中的高影響風險實際發生，需要啟動應對計劃
3. 資源異動：關鍵人員離開、預算調整、供應商更換

更新計劃時，必須同步更新基準，並通知所有利害關係人——這就是為什麼溝通計劃要在規劃階段就建好。

敏捷 vs. 瀑布式規劃：如何選擇適合你的方法？

前面 6 個步驟是以傳統瀑布式（Waterfall）方法為基礎的規劃流程。但如果你的團隊跑 Scrum 或 Kanban，規劃方式會有顯著差異。

比較維度	瀑布式規劃	敏捷式規劃
計劃詳細程度	一次規劃完所有細節，產出完整專案計劃書	只規劃下一個 Sprint（2–4 週），細節逐步展開
更新頻率	有變更時才更新（通常數週到數月）	每個 Sprint 結束後回顧並調整
範疇管理	範疇在規劃階段凍結，變更需走正式流程	範疇持續演進，透過 Product Backlog 排序優先級
適用情境	需求明確、法規要求嚴格（營建、製造、政府標案）	需求會變、需要快速迭代（軟體開發、產品設計）
風險應對	規劃階段一次識別，執行中監控	每個 Sprint 都重新評估風險

3 個問題幫你決定用哪種方法：

1. 需求是否明確？ 如果客戶能在專案開始前就確認 80% 以上的需求，用瀑布式；如果需求會隨市場反饋持續調整，用敏捷式。
2. 交付週期多長？ 6 個月以上的長期專案適合瀑布式（或混合式）；3 個月以內的短期專案適合敏捷式。
3. 客戶參與程度？ 客戶只在開頭和結尾參與 → 瀑布式；客戶每 2 週都要看 Demo → 敏捷式。

混合式（Hybrid）規劃的適用場景： 在台灣，很多團隊的實際情況是「硬體用瀑布、軟體用敏捷」。例如製造業的新產品開發專案，模具開發和產線建置用瀑布式規劃（因為變更成本極高），但配套的 APP 或控制軟體用 Scrum 迭代開發。這種混合模式下，你需要在瀑布式的里程碑中預留「軟體 Sprint 同步點」，確保兩條線不會脫節。

專案規劃工具推薦

工具只是輔助，但選對工具能讓規劃效率倍增。以下是 3 款適合不同團隊規模和需求的工具，依適用情境分別推薦。

Monday.com — 時間線視覺化最直覺

Monday.com 最大的優勢是時間線視圖的直覺操作——拖拉就能調整任務時間，設定相依性後前置任務延遲會自動推移後續任務，不需要手動重算整張甘特圖。

適用情境： 需要跨部門協作、視覺化甘特圖的 5–50 人團隊。以內容排程專案為例，最實用的功能是自動化規則——例如設定「任務延遲超過 2 天自動通知負責人和主管」，這個規則在過去半年觸發了超過 20 次，每次都讓問題在擴大前被處理，以前要等到週會才發現。

價格： 免費方案最多 2 人使用（不需要信用卡），付費方案 NT$450/人/月起（3 人以上）。

ClickUp — 目標追蹤 + 風險管理最強

ClickUp 的強項在於目標追蹤與風險管理的深度整合。它的「Goals」功能可以把專案目標拆解為可量化的 Key Results，並自動從任務完成率計算目標達成進度。搭配風險管理模板，你可以在同一個平台完成從目標設定到風險監控的完整規劃。

適用情境： 需要 OKR 追蹤 + 風險管理的中大型技術團隊，特別是跑 Scrum 的軟體開發團隊。ClickUp 的 Sprint 管理功能和自訂欄位比 monday.com 更靈活，但學習曲線也更陡。

價格： 免費版功能已經很完整，付費方案 NT$300/人/月起。

Notion — 彈性文件 + 資源矩陣

Notion 不是傳統的專案管理工具，但它的數據庫功能非常適合建立 RACI 矩陣、利害關係人登記冊、會議記錄等規劃文件。如果你的團隊預算有限、需要高度客製化的文件管理，Notion 是最靈活的選擇。

適用情境： 預算有限的 5 人以下小型團隊，或是需要把專案規劃文件和知識庫整合在同一平台的團隊。

價格： 免費版可用（個人使用無限制），付費 NT$320/人/月起。

工具選擇速查表

功能維度	Monday.com	ClickUp	Notion
時間線/甘特圖	⭐⭐⭐ 拖拉操作最直覺	⭐⭐ 功能完整但介面較複雜	⭐ 需搭配時間軸視圖，功能基本
資源管理	⭐⭐⭐ 工作負載視圖一目了然	⭐⭐ 可自訂但需要設定	⭐⭐ 用數據庫建立 RACI 矩陣
風險追蹤	⭐⭐ 需搭配自訂欄位	⭐⭐⭐ 內建風險管理模板	⭐ 需自行建立數據庫
價格（付費起）	NT$450/人/月	NT$300/人/月	NT$320/人/月
開始使用	免費試用 →	免費試用 →	免費試用 →

你是哪種團隊？

• 5 人以下、剛開始接觸專案管理 → 先用 Notion 免費版建立基本文件
• 5–15 人跨部門協作 → monday.com（視覺化最強）
• 技術團隊跑 Scrum → ClickUp（Sprint + 目標追蹤整合最好）
• 15 人以上的大型專案 → monday.com 企業方案（自動化 + 跨看板報表）

更多工具比較可以參考我們的專案管理軟體工具推薦完整評測。

專案規劃書範本：完整結構與免費資源

很多人搜尋「專案規劃」其實是在找一份可以直接套用的範本。以下是一份完整專案規劃書應包含的 7 個章節，你可以把它當作結構指引，用任何工具都能套用：

1. 專案概述：專案名稱、贊助人、PM、啟動日期、預計結束日期
2. 專案目標與成功標準：SMART 目標 + 可量化的成功指標
3. 範疇說明書：交付物清單、排除項目、驗收標準
4. WBS 與時間表：工作分解結構 + 甘特圖 + 里程碑
5. 資源計劃與 RACI 矩陣：人力配置、預算分配、職責矩陣
6. 溝通計劃：利害關係人溝通矩陣 + 升級機制
7. 風險登記表：已識別風險、機率/影響評估、應對策略

免費資源推薦：

• ClickUp 內建規劃模板：註冊免費帳號後，在模板中心搜尋「Project Plan」，可以直接套用包含 WBS、時間線、風險追蹤的完整規劃模板
• Notion 社群模板：搜尋「Project Planning」，有大量社群貢獻的免費模板，適合小型團隊快速上手

想了解如何撰寫更完整的專案文件，可以參考我們的企劃書撰寫教學。

結論

以下是本文的核心重點：

• 規劃前先用 Why/Who/What-How-When/Where 四大框架檢視專案：搞清楚為什麼要做、誰參與、做什麼和怎麼做、在哪裡協作——這四個問題沒答案就不要開始畫甘特圖
• WBS 是一切的起點：先把專案拆解成 3–4 層的工作包，後續的時間估算、資源分配、風險識別才有依據
• RACI 矩陣防止資源過載：每個任務只能有一個 A（Accountable），填完後橫向檢查每個人的 R 數量
• 溝通計劃和升級機制要寫下來：不是等出問題才開會，而是規劃階段就決定「誰、什麼時候、用什麼方式」溝通
• 凍結基準才算完成規劃：沒有基準，執行階段就無法衡量績效

你的下一步行動： 打開 monday.com，用「專案啟動模板」建立一個新看板，把本文的 6 個步驟對應到看板的群組結構——10 分鐘就能建好你的第一個專案規劃框架。免費方案不需要信用卡，直接開始。

專案規劃常見問題（FAQ）

什麼是專案規劃？

專案規劃是專案管理五大流程中的第二階段，目的是將專案目標轉化為可執行的行動計劃。核心輸出物包含範疇說明書、WBS、時間表、資源計劃和風險登記表。

專案規劃的輸出是什麼？

專案規劃的主要輸出是「專案計劃書（Project Plan）」，它包含以下子計劃：範疇管理計劃、時間表（含甘特圖與里程碑）、成本/預算計劃、品質管理計劃、人力資源計劃（含 RACI 矩陣）、溝通管理計劃、以及風險管理計劃（含風險登記表）。這些文件合在一起，就是指導專案從執行到結案的完整藍圖。

專案規劃和專案執行有什麼不同？

規劃階段的產出是「計劃文件」——你在定義要做什麼、怎麼做、誰來做；執行階段的產出是「實際成果」——團隊按照計劃交付工作。兩者的分界點是「基準凍結」：當範疇、時間、成本三個基準都確認並獲得贊助人簽核後，專案正式從規劃進入執行。

什麼是 WBS？如何建立？

WBS（Work Breakdown Structure，工作分解結構）是將專案從上到下拆解成更小工作包的工具。建立步驟：第一步，從專案的最終交付物開始，拆解為 3–5 個主要階段（第 2 層）；第二步，將每個階段再拆解為具體的工作包（第 3 層），每個工作包應該是一個人在 1–2 週內可完成的任務。詳細教學請參考我們的 WBS 完整教學。

專案規劃需要多久時間？

依專案規模而定：小型專案（5 人以下、3 個月內）通常 1 週可完成規劃；中型專案（5–15 人、3–6 個月）需要 2–4 週；大型專案（15 人以上、6 個月以上）可能需要 1–2 個月。關鍵不是花多少時間，而是確保 5 個核心輸出物都完成且獲得利害關係人認可。

如何管理專案風險？

風險管理分 4 步：識別（列出所有可能的風險）→ 評估（判斷每個風險的發生機率和影響程度）→ 應對（制定避免、轉移、接受或降低風險的策略）→ 監控（持續追蹤風險狀態，發生時啟動應對計劃）。建議使用風險矩陣（機率 × 影響的 2×2 表格）來排序優先處理的風險。

小型團隊（5 人以下）需要正式的專案規劃嗎？

需要，但可以簡化。5 人以下的團隊不需要寫 30 頁的專案計劃書，但至少要有：一份 1 頁的範疇說明書（寫清楚做什麼、不做什麼）、一張簡單的時間表（用 monday.com 或 Excel 甘特圖）、以及口頭確認的 RACI 分工。規劃的目的不是產出文件，而是確保團隊對「做什麼、誰負責、什麼時候完成」有共識。台灣很多中小企業跳過規劃直接開工，結果是做到一半才發現大家對目標的理解不一樣——回頭修正的成本遠高於花 1 天做規劃。