專案範圍（Project Scope）是明確界定專案「做什麼」與「不做什麼」的文件，是防止範疇蔓延的第一道防線。這篇文章提供 5 種產業情境的完整範例、6 大核心組成要素解析，以及可直接套用的撰寫流程與範本。
什麼是專案範圍（Project Scope）？
專案範圍的定義很簡單：它是一份明確劃定專案邊界的文件，告訴所有利害關係人「這個專案會做哪些事」以及「不會做哪些事」。
聽起來直覺，但在台灣職場中，我們團隊觀察到一個反覆出現的問題——很多 PM 把「專案目標」直接當成「專案範圍」來填。目標是「提升客戶滿意度 20%」，範圍是「導入客服系統、建立 FAQ 知識庫、訓練客服人員」。兩者層次完全不同。
範圍沒定義清楚的代價是什麼？範疇蔓延（Scope Creep）。根據 PMI 的統計，超過 50% 的專案都經歷過範疇蔓延，而其中大多數的根本原因就是「一開始沒把範圍寫清楚」。一個看似無害的「順便加個功能」，累積下來就是延期兩個月、預算超支 30%。
在進一步看範例之前，先釐清三個常被混淆的文件：
| 文件名稱 | 核心用途 | 涵蓋內容 | 何時產出 |
|---|---|---|---|
| 專案範圍說明書（Scope Statement） | 界定專案邊界 | In-Scope、Out-of-Scope、交付成果、驗收標準 | 規劃階段初期 |
| 工作範圍（SOW, Scope of Work） | 定義具體任務與交付物 | 任務清單、時程、付款條件、驗收方式 | 合約簽訂前 |
| 專案章程（Project Charter） | 正式授權專案啟動 | 專案目的、高階範圍、預算上限、專案經理授權 | 啟動階段 |
簡單記：章程是「為什麼做」，範圍是「做什麼」，SOW 是「怎麼做、做到什麼程度」。如果你正在撰寫完整的專案啟動文件，可以參考企劃書的撰寫架構，兩者搭配使用效果更好。
專案範疇說明書的 6 大核心組成
不管你的專案是 IT 導入、行銷活動還是內部流程改善，一份完整的專案範疇說明書都包含以下 6 個欄位。我們團隊在實際操作中發現，缺少任何一個欄位，後續都會產生爭議。
① 專案目標（Objectives）
目標要符合 SMART 原則——具體、可衡量、可達成、相關、有時限。
- ❌「導入新系統，提升效率」（模糊到無法驗收）
- ✅「在 Q3 結束前完成 ERP 系統上線，使採購流程處理時間從平均 5 天縮短至 2 天」
台灣 IT 導入專案常見的目標寫法問題是「只寫質化目標，不寫量化指標」。沒有數字，就沒有驗收基準。
② 交付成果（Deliverables）
列出專案會產出的所有具體成果，並區分「最終交付」和「中間里程碑」。
- 最終交付：上線的 ERP 系統、完成的行銷活動報告
- 中間里程碑：需求規格書、原型設計、UAT 測試報告
每個交付成果都要能被「看到」或「驗證」。如果你寫不出具體的產出物名稱，代表這個項目還需要進一步拆解。
③ 納入範圍（In-Scope）
明確列出本次專案涵蓋的所有工作項目。寫法要具體到「看了就知道要做什麼」的程度。
- ❌「系統開發」
- ✅「開發採購模組（含供應商管理、訂單管理、驗收管理三個子功能）」
④ 排除範圍（Out-of-Scope）
這是整份文件中最容易被忽略、卻最能防止範疇蔓延的欄位。
我們的經驗是：Out-of-Scope 清單要比 In-Scope 更詳細。因為利害關係人不會質疑你「要做的事」，他們會不斷追加「你沒說不做的事」。
例如 IT 導入專案中，以下項目如果沒有明確寫在 Out-of-Scope，幾乎 100% 會被要求「順便做」：
- 舊系統資料清洗與移轉
- 使用者教育訓練（超過 2 小時的部分）
- 與第三方系統的串接
- 行動裝置版本開發
⑤ 假設與限制（Assumptions & Constraints）
假設是「我們認為成立、但尚未被驗證的前提」；限制是「已知的硬性邊界」。
- 假設範例：客戶將在第 2 週前提供完整的業務流程文件
- 限制範例：總預算不超過 NT$500 萬；專案團隊僅有 4 名全職開發人員
把假設寫清楚的好處是：當假設不成立時，你有正當理由調整範圍或時程。
⑥ 驗收標準（Acceptance Criteria）
定義「怎樣算完成」。這個欄位直接決定了專案結案時會不會吵架。
- ❌「系統運作正常」
- ✅「系統在 100 位同時使用者的情境下，頁面載入時間不超過 3 秒；所有核心功能通過 UAT 測試，零 Critical Bug」
驗收標準越具體，結案時的爭議越少。如果你在設定目標時需要更系統化的方法，可以參考艾森豪矩陣來區分優先順序。
5 種情境的專案範圍範例（含填寫說明）
以下 5 個範例涵蓋台灣職場最常見的專案類型。每個範例都按照上述 6 大組成撰寫，你可以直接參考格式並替換成自己的內容。
IT 系統導入專案範圍範例
情境：一家 200 人的中型製造業公司，要導入 ERP 系統取代現有的 Excel 作業流程。
| 欄位 | 內容 |
|---|---|
| 專案目標 | 在 6 個月內完成 ERP 採購模組上線，將採購流程處理時間從 5 天縮短至 2 天，錯誤率降低 80% |
| 交付成果 | ① 需求規格書 ② 系統設計文件 ③ 採購模組（供應商管理、訂單管理、驗收管理） ④ UAT 測試報告 ⑤ 使用手冊 ⑥ 2 小時使用者教育訓練 |
| 納入範圍 | 採購模組開發與部署、與現有會計系統的 API 串接、核心使用者教育訓練（2 小時 × 3 場）、上線後 30 天技術支援 |
| 排除範圍 | 舊系統資料清洗與移轉（由客戶 IT 部門自行處理）、庫存模組開發（列入第二期）、行動裝置版本、超過 30 天的技術支援、硬體採購與網路環境建置 |
| 假設與限制 | 假設：客戶在第 3 週前提供完整業務流程文件；限制：預算上限 NT$350 萬、開發團隊 4 人 |
| 驗收標準 | 所有核心功能通過 UAT 測試（零 Critical Bug、Minor Bug ≤ 5）；100 位同時使用者下頁面載入 ≤ 3 秒 |
填寫重點：IT 專案最常見的爭議來自「排除範圍」沒寫清楚。特別是「教育訓練」和「舊系統資料移轉」——這兩項幾乎每次都會被客戶認為「應該包含在內」。提前寫進 Out-of-Scope，能省下無數次的會議爭論。
我們團隊在管理類似的 IT 導入專案時，會用 monday.com 的看板功能 把 In-Scope 和 Out-of-Scope 分成兩個群組。當客戶提出新需求時，直接在看板上拖曳到對應群組，所有人即時看到範圍變動——比在 Email 裡來回確認有效率得多。
行銷活動專案範圍範例
情境：一家消費品品牌要舉辦週年慶線上活動，包含官網活動頁、社群推廣和 KOL 合作。
| 欄位 | 內容 |
|---|---|
| 專案目標 | 在活動期間（10 天）達成官網流量較去年同期成長 50%，活動頁轉換率 ≥ 3% |
| 交付成果 | ① 活動企劃書 ② 官網活動頁（含 RWD） ③ 3 支社群短影音 ④ 2 位 KOL 合作貼文 ⑤ 活動結案報告 |
| 納入範圍 | 活動主視覺設計、官網活動頁前端開發、社群短影音製作（3 支）、KOL 篩選與合作洽談（2 位）、Google Ads 投放管理 |
| 排除範圍 | 品牌 Logo 重新設計、實體門市佈置、客服人力調度、額外社群貼文（超出 3 支短影音的部分）、SEO 長期優化 |
| 假設與限制 | 假設：KOL 在活動前 2 週完成內容審核；限制：總預算 NT$80 萬（含 KOL 費用）、設計師 1 人 |
| 驗收標準 | 活動頁在 iOS/Android/桌面三平台正常顯示；短影音觸及率 ≥ 10,000/支；結案報告在活動結束後 5 個工作天內交付 |
填寫重點：行銷專案最常見的範疇蔓延是「創意發想」的邊界。客戶說「這個主視覺不夠好，再想幾個方案」——如果沒有在範圍中明確寫「主視覺提供 3 個方案，客戶選定後修改 2 次為限」，你會陷入無限修改的迴圈。
另一個經典陷阱：客戶在活動上線前一週說「順便幫我們發幾篇社群貼文吧」。這就是為什麼「額外社群貼文」要明確寫在排除範圍。
軟體開發專案範圍範例
情境：一個 8 人的軟體團隊要為既有產品開發「報表匯出」新功能模組，採用 Scrum 敏捷開發。
| 欄位 | 內容 |
|---|---|
| 專案目標 | 在 3 個 Sprint（6 週）內完成報表匯出模組，支援 PDF 與 Excel 兩種格式，上線後使用者滿意度 ≥ 4.0/5.0 |
| 交付成果 | ① Product Backlog（已排序） ② 報表匯出功能（PDF + Excel） ③ API 文件 ④ 自動化測試腳本 ⑤ 上線部署文件 |
| 納入範圍 | 報表匯出功能開發（PDF、Excel 格式）、現有報表模板套用、API 端點開發、單元測試與整合測試、CI/CD 部署設定 |
| 排除範圍 | 新報表模板設計（使用現有模板）、CSV 格式支援（列入後續 Sprint）、行動版 App 適配、效能壓力測試（由 QA 團隊另案處理） |
| 假設與限制 | 假設：現有報表引擎支援 PDF 輸出，不需額外購買第三方套件；限制：團隊 8 人中僅 3 位後端工程師可投入 |
| 驗收標準 | 所有 User Story 通過 Definition of Done；匯出 1000 筆資料的報表 ≤ 10 秒；零 Critical/Major Bug |
填寫重點：敏捷專案的範圍定義和傳統瀑布式不同。瀑布式是「一開始就鎖死所有範圍」，敏捷是「在 Epic/Story 層級定義範圍邊界，但 Sprint 內的具體實作可以調整」。
實務上的做法是： 1. Epic 層級定義 In-Scope / Out-of-Scope（這個不變） 2. Sprint 層級從 Product Backlog 中挑選 Story 進入 Sprint Backlog 3. 每個 Sprint Review 時確認範圍是否需要調整
這種做法讓團隊保有彈性，同時不會失控。如果你的團隊正在導入敏捷，ClickUp 的 Sprint 管理功能 可以在同一個平台上管理 Backlog 和範圍文件，避免資訊散落在不同工具裡。
內部流程改善專案範圍範例
情境：一家 50 人的貿易公司要將紙本採購流程數位化，目標是減少人工作業時間。
| 欄位 | 內容 |
|---|---|
| 專案目標 | 在 3 個月內完成採購流程數位化，將每筆採購單處理時間從 45 分鐘縮短至 15 分鐘 |
| 交付成果 | ① 現況流程分析報告 ② 新流程設計文件 ③ 數位化採購表單（含電子簽核） ④ 使用者操作手冊 ⑤ 導入後成效評估報告 |
| 納入範圍 | 現有採購流程訪談與分析、新流程設計、數位表單建置、電子簽核流程設定、3 場使用者訓練、導入後 2 週的問題排除 |
| 排除範圍 | 供應商管理系統開發、會計系統串接、採購政策修訂（由管理部門負責）、手機 App 開發 |
| 假設與限制 | 假設：各部門主管同意在第 2 週前完成流程訪談；限制：不額外採購軟體，使用現有 Microsoft 365 環境 |
| 驗收標準 | 新流程上線後連續 2 週，90% 以上的採購單透過數位流程完成；平均處理時間 ≤ 15 分鐘 |
填寫重點：內部流程改善專案最大的風險不是技術，而是「利害關係人沒有真正同意範圍」。我們見過太多案例——PM 以為範圍已經確認了，結果某個部門主管在導入時才說「我們部門的流程不一樣，這個方案不適用」。
解決方法：在範圍確認階段，讓每個受影響部門的主管書面簽核。口頭同意不算數。如果你的組織還在用紙本簽核，這反而是推動數位轉型的好時機。
範圍確認清單（每個利害關係人都要勾選）：
- [ ] 我已閱讀並理解專案範圍說明書
- [ ] 我同意「納入範圍」中列出的工作項目
- [ ] 我理解「排除範圍」中的項目不在本次專案中處理
- [ ] 我了解範圍變更需透過正式的變更申請流程
活動籌辦專案範圍範例
情境：一家 300 人的科技公司要舉辦年度尾牙，預算 NT$120 萬。
| 欄位 | 內容 |
|---|---|
| 專案目標 | 在 12/20 前完成 300 人年度尾牙活動，員工滿意度調查 ≥ 4.2/5.0 |
| 交付成果 | ① 活動企劃書 ② 場地租借合約 ③ 節目流程表 ④ 活動當天執行 ⑤ 活動照片精修 50 張 ⑥ 滿意度調查報告 |
| 納入範圍 | 場地租借與佈置、餐飲安排（含素食選項）、主持人與音響設備、3 個表演節目安排、摸彩活動（獎品由公司提供）、活動攝影 |
| 排除範圍 | 員工交通接駁（自行前往）、獎品採購（由行政部門處理）、活動影片剪輯（僅提供照片）、二次會場地安排 |
| 假設與限制 | 假設：場地在 11/15 前確認預訂；限制：總預算 NT$120 萬、籌備團隊 3 人 |
| 驗收標準 | 活動當天零重大事故；餐飲供應充足（無斷餐情況）；滿意度調查回收率 ≥ 70% |
填寫重點：活動籌辦專案的範圍判斷邏輯是「誰負責什麼」。場地佈置是你的範圍，但員工交通不是；活動攝影是你的範圍，但影片後製不是。每一項都要明確歸屬，否則活動前一週一定會有人問「影片什麼時候可以看？」
如果你需要設計活動的滿意度調查問卷，可以參考問卷設計的完整教學來確保問卷品質。
專案範疇怎麼寫：5 步驟撰寫流程
知道範例長什麼樣之後，接下來是「怎麼從零開始寫出來」。以下是我們團隊實際使用的 5 步驟流程。
Step 1｜收集需求
和利害關係人訪談時，問這 3 個關鍵問題：
- 「這個專案成功的話，你會看到什麼具體改變？」——這能幫你定義目標和交付成果
- 「有什麼是你覺得『應該包含』但還沒被討論到的？」——這能挖出隱藏需求
- 「有什麼是你『不希望』這個專案去碰的？」——這能直接產出 Out-of-Scope 清單
我們的經驗是，第三個問題最容易被跳過，卻最有價值。很多利害關係人其實心裡有「不想被改變的東西」，但不會主動說出來。
Step 2｜區分 In-Scope / Out-of-Scope
把收集到的所有需求列成清單後，用「需求分類矩陣」快速判斷每一項的歸屬：
| 本次必須完成 | 本次不必完成 | |
|---|---|---|
| 利害關係人明確要求 | ✅ In-Scope（最高優先） | ⚠️ 記錄為「未來考慮」，寫入 Out-of-Scope |
| 利害關係人未提及 | 🔍 確認是否為隱含需求 | ❌ Out-of-Scope |
這個矩陣的關鍵在右上角——利害關係人明確要求、但本次不必完成的項目。這些項目必須被正式記錄在 Out-of-Scope 中，並且在簽核時讓對方確認「我知道這次不做」。
Step 3｜定義驗收標準
每個交付成果都要有對應的驗收標準。寫法公式：「在 [條件] 下，[對象] 能夠 [動作]，且 [量化指標]」。
- ✅「在 100 位同時使用者的條件下，系統能夠正常處理訂單，且頁面載入時間 ≤ 3 秒」
- ❌「系統要跑得快」
如果你發現某個交付成果寫不出驗收標準，通常代表這個交付成果的定義還不夠具體，需要回到 Step 1 重新釐清。
Step 4｜取得簽核
誰需要簽？
- 專案發起人（Sponsor）——必簽
- 各部門利害關係人代表——必簽
- 專案經理——必簽
- 技術負責人（如果是 IT 專案）——建議簽
何時簽？
- 在專案正式進入執行階段之前。一旦開始執行才發現範圍有爭議，修改成本會是規劃階段的 5-10 倍。
一家台灣電商公司曾經因為跳過這個步驟，直接進入開發。結果行銷部門在開發到一半時才說「我們以為會包含 App 推播功能」，導致專案延期 3 週、追加預算 NT$45 萬。如果當初花 30 分鐘讓行銷主管簽核範圍文件，這個問題根本不會發生。
電子簽核可以加速這個流程。我們團隊用 monday.com 的自動化功能 設定了一條規則：當範疇說明書狀態改為「待簽核」時，自動通知所有需要簽核的人，並在 3 天未回覆時自動發送提醒。這讓簽核流程從平均 2 週縮短到 4 天。
Step 5｜建立變更控制機制
範圍簽核後不代表永遠不能改，但改變必須透過正式流程。一份基本的範圍變更申請單（Change Request）應包含：
| 欄位 | 說明 |
|---|---|
| 變更編號 | CR-001、CR-002… |
| 申請人 | 誰提出這個變更？ |
| 變更描述 | 具體要新增/修改/刪除什麼？ |
| 影響評估 | 對時程、預算、人力的影響 |
| 優先等級 | 必要 / 重要 / 可延後 |
| 審核結果 | 核准 / 駁回 / 需更多資訊 |
| 審核人簽名 | 誰有權決定？ |
重點是：任何範圍變更都必須經過影響評估後才能核准。 「加一個小功能」聽起來無害，但累積 10 個「小功能」就是一個月的延期。
如果你想用更系統化的方式管理變更流程，可以參考流程圖的製作方法，把變更審核流程視覺化。
防止範疇蔓延：3 個實務控管技巧
範疇蔓延不是一次性事件，而是漸進式的侵蝕。以下 3 個技巧是我們團隊在多年專案管理中驗證過最有效的做法。
技巧 1｜Out-of-Scope 清單要比 In-Scope 更詳細
這聽起來反直覺，但邏輯很簡單：利害關係人不會質疑你「要做的事」，他們會不斷追加「你沒說不做的事」。
寫 Out-of-Scope 時，把自己想像成最愛追加需求的客戶，問自己：「如果我是客戶，我會覺得哪些東西『理所當然應該包含』？」然後把這些全部寫進排除範圍。
技巧 2｜範圍變更申請（Change Request）標準化
當有人提出新需求時，不要當場答應或拒絕。標準回覆是：「這是一個好想法，請填寫變更申請單，我們會在下次審查會議中評估影響。」
這句話的威力在於：它不是拒絕，而是引導。大多數「隨口提的小需求」在需要填表時就會自動消失——因為提出者自己也覺得「好像沒那麼重要」。
技巧 3｜定期範圍審查會議
建議頻率：
- 短期專案（< 3 個月）：每 2 週一次
- 中期專案（3-6 個月）：每月一次
- 長期專案（> 6 個月）：每月一次，但每季做一次完整範圍重新確認
會議議程範本（30 分鐘）： 1. 回顧目前範圍狀態（5 分鐘） 2. 審查待處理的變更申請（15 分鐘） 3. 確認是否有新的隱含需求浮現（5 分鐘） 4. 更新範圍文件並記錄決議（5 分鐘）
⚠️ 這 5 句話出現時，代表範疇蔓延正在發生： 1. 「這個應該很簡單，順便加一下就好」 2. 「我以為這本來就包含在裡面」 3. 「老闆說要加這個功能」 4. 「客戶昨天 Email 說希望多做一個…」 5. 「這個不算新需求，只是小修改」
當你聽到這些話時，不要恐慌，但要立刻啟動變更控制流程。每一次「例外處理」都會削弱流程的權威性。
在管理團隊的工作負載時，了解主管領導力的核心原則也很重要——有時候說「不」比說「好」更需要勇氣和技巧。
專案範圍管理工具推薦
選擇工具的 3 個判斷維度：團隊規模、預算、與現有工具的整合性。不需要追求功能最多的工具，而是選「你的團隊真的會用」的那一個。
台灣中小企業最常見的 Excel 範圍管理
先說實話：如果你的團隊 < 5 人、專案規模小，用 Excel 管理範圍文件完全可以。我們團隊早期也是從 Excel 開始的。
Excel 的優點：
- 零學習成本，人人都會用
- 格式自由，想怎麼排就怎麼排
- 不需要額外付費
Excel 的致命缺點：
- 版本控制是噩夢——「範圍文件_v3_final_真的final.xlsx」
- 無法即時協作，容易出現資訊落差
- 沒有自動化提醒，變更申請容易被遺忘
- 無法與任務管理整合，範圍文件和實際執行脫節
何時該從 Excel 升級？ 當你發現以下任一情況時：
- 團隊超過 5 人，開始出現「我沒看到最新版」的問題
- 專案同時進行 3 個以上，Excel 檔案管理變得混亂
- 利害關係人分散在不同部門或地點，需要即時協作
- 範圍變更頻繁，需要自動化的審核流程
工具比較表
| 工具 | 適合情境 | 範圍文件功能 | 費用（NT$/月/人） | 免費試用 |
|---|---|---|---|---|
| monday.com | 視覺化管理、跨部門協作 | 工作範圍看板 + WorkDocs 文件 + 自動化簽核流程 | NT$270 起 | 免費試用 → |
| ClickUp | 功能全面、技術團隊 | 文件 + 任務整合 + Sprint 管理 | 免費～NT$210 | 免費試用 → |
| Notion | 中小型團隊、彈性文件 | 自訂模板 + 資料庫 + Wiki | 免費～NT$270 | 免費試用 → |
| Excel / Google Sheets | 小型專案、預算極有限 | 自由格式表格 | 免費 | — |
| MS Project | 大型傳統專案、甘特圖需求 | WBS + 甘特圖 + 資源管理 | NT$300 起 | — |
備註：本表聚焦台灣團隊較常使用的工具。Asana 同樣是優秀的專案管理平台，但在台灣中小企業的採用率相對較低，且中文化支援不如上述工具完整，因此未列入本次比較。有興趣的讀者可自行至 Asana 官網評估。
你是哪種團隊？
- 5 人以下、剛開始接觸專案管理：先用 Notion 免費版 建立範圍文件模板，熟悉流程後再考慮升級
- 5-15 人、需要跨部門協作：monday.com 是我們的首選——視覺化看板讓非 PM 背景的同事也能一眼看懂範圍狀態
- 技術團隊跑 Scrum：ClickUp 的文件 + Sprint + 任務整合度最高，適合需要在同一平台管理所有東西的團隊
- 15 人以上的大型專案：monday.com 企業方案，支援更細緻的權限控管和自動化工作流程
可直接使用的專案範圍範本
以下提供兩種範本結構，你可以根據專案規模選擇適合的版本。
基礎版範本（適合小型專案）
適用情境：團隊 < 10 人、單一部門、專案期程 < 3 個月。一頁 A4 就能寫完。
| 欄位 | 填寫說明 | 字數建議 |
|---|---|---|
| 專案名稱 | 簡潔明確，讓人一看就知道在做什麼 | 10-20 字 |
| 專案目標 | 1-2 個 SMART 目標 | 50-100 字 |
| 交付成果 | 列出 3-5 個具體產出物 | 50-100 字 |
| 納入範圍 | 列出主要工作項目 | 100-150 字 |
| 排除範圍 | 列出明確不做的項目 | 100-200 字 |
| 驗收標準 | 每個交付成果對應 1 個驗收條件 | 50-100 字 |
以下是基礎版範本的空白填寫格式，你可以直接複製到 Google Docs 或 Word 中使用：
專案範疇說明書（基礎版）
| 欄位 | 內容 |
|---|---|
| 專案名稱 | ＿＿＿＿＿＿＿＿＿＿ |
| 專案經理 | ＿＿＿＿＿＿ ／ 部門：＿＿＿＿＿＿ |
| 專案期程 | ＿＿年＿＿月＿＿日 至 ＿＿年＿＿月＿＿日 |
| 專案目標 | 目標 1：在＿＿（時限）前完成＿＿（具體成果），使＿＿（指標）從＿＿改善至＿＿ |
| 目標 2：＿＿＿＿＿＿＿＿＿＿ | |
| 交付成果 | ① ＿＿＿＿＿＿ ② ＿＿＿＿＿＿ ③ ＿＿＿＿＿＿ ④ ＿＿＿＿＿＿ ⑤ ＿＿＿＿＿＿ |
| 納入範圍（In-Scope） | • ＿＿＿＿＿＿＿＿＿＿ |
| • ＿＿＿＿＿＿＿＿＿＿ | |
| • ＿＿＿＿＿＿＿＿＿＿ | |
| 排除範圍（Out-of-Scope） | • ＿＿＿＿＿＿（原因：＿＿＿＿＿＿） |
| • ＿＿＿＿＿＿（原因：＿＿＿＿＿＿） | |
| • ＿＿＿＿＿＿（原因：＿＿＿＿＿＿） | |
| • ＿＿＿＿＿＿（原因：＿＿＿＿＿＿） | |
| 驗收標準 | 交付成果①：在＿＿條件下，＿＿能夠＿＿，且＿＿ |
| 交付成果②：＿＿＿＿＿＿＿＿＿＿ | |
| 簽核 | 專案發起人：＿＿＿＿＿＿ 日期：＿＿/＿＿/＿＿ |
| 利害關係人：＿＿＿＿＿＿ 日期：＿＿/＿＿/＿＿ | |
| 專案經理：＿＿＿＿＿＿ 日期：＿＿/＿＿/＿＿ |
💡 使用提示：排除範圍欄位建議至少填寫 4 項以上，並附上簡短原因說明（例如「列入第二期」、「由其他部門負責」）。這能大幅減少後續的範圍爭議。
完整版範本（適合跨部門或對外客戶專案）
適用情境：跨部門協作、對外客戶專案、專案期程 > 3 個月。通常 3-5 頁。
在基礎版的 6 個欄位之外，完整版額外包含：
| 額外欄位 | 填寫說明 |
|---|---|
| 假設條件 | 列出所有尚未被驗證的前提假設 |
| 限制條件 | 預算、人力、技術、時間的硬性限制 |
| 利害關係人清單 | 姓名、部門、角色、簽核權限 |
| 變更控制流程 | 變更申請的提交方式、審核人、審核時限 |
| 風險登記 | 與範圍相關的主要風險及應對策略 |
| 簽核欄 | 所有需要簽核的人員姓名與日期 |
產業調整建議：
- IT 產業：加入「技術架構限制」和「第三方系統整合範圍」欄位
- 行銷產業：加入「修改次數限制」和「創意審核流程」欄位
- 製造業：加入「設備需求」和「安全規範」欄位
如何取得完整版範本？ 你可以用以下兩種方式快速建立：
- Google Docs / Sheets：將上方基礎版表格複製到 Google Docs，再加入完整版的額外欄位即可。Google Sheets 特別適合需要多人同時編輯的情境。
- monday.com WorkDocs：如果你的團隊已在使用 monday.com，可以直接在 WorkDocs 中建立範疇說明書，好處是範圍文件和任務看板在同一個畫面上——不用在 Word 和專案管理工具之間來回切換。
- Notion：在 Notion 中建立一個資料庫模板，將 6 大核心欄位設為固定屬性，每次新專案直接複製模板即可。Notion 的模板複製功能特別適合需要反覆使用相同格式的團隊。
在撰寫範本時，如果需要視覺化呈現範圍架構，可以參考商業模式九宮格的框架思維——把複雜的資訊結構化到固定的格子裡，讓所有人都能快速理解。
結論
專案範圍不是一份「寫完就放著」的文件，而是專案執行期間持續被參照、被更新的活文件。把範圍寫清楚，不是為了增加行政負擔，而是為了讓所有人對「做什麼」和「不做什麼」有共識——這是專案成功最基本的前提。
回顧本文重點：
- 專案範圍 = 邊界定義：明確界定 In-Scope 和 Out-of-Scope，其中 Out-of-Scope 比 In-Scope 更重要
- 6 大核心組成缺一不可：目標、交付成果、納入範圍、排除範圍、假設與限制、驗收標準
- 5 種情境範例可直接參考：IT 導入、行銷活動、軟體開發、流程改善、活動籌辦，每種都有不同的填寫重點
- 5 步驟撰寫流程：收集需求 → 區分範圍 → 定義驗收 → 取得簽核 → 建立變更控制
- 防止範疇蔓延的關鍵：標準化變更申請流程 + 定期範圍審查會議
你的下一步：選一個即將啟動的專案，用本文的 6 大組成架構寫出第一版範疇說明書。不需要完美，先寫出來、讓利害關係人看過、取得簽核——這比任何完美的範本都有價值。
如果你希望讓這個流程更順暢，可以從在 monday.com 用 WorkDocs 建立第一份範疇說明書開始，搭配看板追蹤每個工作項目的狀態。免費方案不需要信用卡，10 分鐘就能建好你的第一個專案範圍管理框架。
專案範圍常見問題
專案範圍說明書和工作範圍（SOW）有什麼不同？
專案範圍說明書（Scope Statement）定義的是「專案的邊界」——做什麼、不做什麼。工作範圍（SOW, Scope of Work）則更偏向「合約層級的任務清單」，包含具體的工作項目、時程、付款條件和驗收方式。簡單來說，範圍說明書是給專案團隊看的內部文件，SOW 是給客戶或外包廠商看的合約附件。兩者可以互相參照，但用途不同。
小型專案也需要寫專案範圍文件嗎？
需要，但可以簡化。即使是 2-3 人、為期 2 週的小專案，至少也要用一頁 A4 寫清楚「目標」、「交付成果」和「排除範圍」。我們見過太多「小專案」因為沒有書面範圍，最後膨脹成「中型專案」的案例。花 30 分鐘寫一份基礎版範本，能省下後續數十小時的爭議。
專案範圍可以在執行中途修改嗎？
可以，但必須透過正式的變更控制流程。提出變更申請 → 評估對時程、預算、人力的影響 → 由授權人核准或駁回 → 更新範圍文件並通知所有利害關係人。重點是「不能口頭修改」，每一次變更都要有書面記錄。
敏捷專案還需要定義範圍嗎？
需要，只是定義的方式不同。敏捷專案在 Epic 層級定義整體範圍邊界（In-Scope / Out-of-Scope），但在 Sprint 層級保持彈性——每個 Sprint 從 Product Backlog 中挑選要完成的 Story。這種做法既有明確的邊界，又保留了根據回饋調整的空間。如果你對敏捷開發有興趣，保持心流狀態對提升 Sprint 內的開發效率也很有幫助。
專案範疇說明書要讓哪些人簽核？
最低要求是三方簽核：專案發起人（有預算決定權）、主要利害關係人代表（受專案影響最大的部門主管）、專案經理（負責執行的人）。如果是 IT 專案，建議加上技術負責人。簽核的目的不是走形式，而是確保每個人都「看過、理解、同意」範圍內容——這是未來發生爭議時最有力的依據。
