會議室裡，行銷主管說成本太高需要調整，技術主管說時程不合理要延後，業務主管說客戶不會接受要重新談。每個人都有道理但散會後沒人知道下一步該做什麼。
問題還是問題，執行更是遙遙無期。
其實大部分團隊的會議困擾都指向同一個根源：缺乏系統化的決策流程。
大家以為開會就是把人聚在一起討論，但如果沒有清楚的流程設計，討論很容易失焦、意見難以收斂、決策無法落地。
然而有結構的決策，才能讓團隊真正往前走。決策流程被清楚設計，討論才有方向，方案品質也能連帶跟著變好。
為什麼團隊討論常常沒結論？四個缺口讓會議變空轉
團隊討論沒結論，通常為決策流程出現了結構性缺口。我把最常見的四種情況對應到 PACE 框架的四個階段：
缺口一：問題沒有對齊（缺 P）
表面上大家在討論同一件事，實際上每個人心裡想的問題都不一樣。行銷想的是「如何提升品牌知名度」，業務想的是「如何增加這季銷量」，財務想的是「如何控制預算不超支」。
三個小時過去了，大家都在回答不同的問題，對一件事的定義根本不同。
缺口二：討論沒有結構（缺 A）
沒有分析框架，討論就會東扯西扯。有人說A是問題，有人說B才是根本原因，有人又提出C也需要考慮。但沒人能把觀點整理成系統化的分析。
最常見的狀況是：會議記錄密密麻麻寫了兩頁，但回頭看根本看不出邏輯。哪些是現象？哪些是原因？哪些是假設？全部混在一起。
缺口三：沒有具體方案（缺 C）
很多會議只停留在發現問題和抱怨，從來沒有進入提出方案的階段。
大家都知道哪裡不對，但沒人說接下來該怎麼做。就算有人提出方案，也只有一個選項，團隊沒有機會比較與討論。
我曾聽一位主管說：我們團隊很會發現問題，但一問到解決方法就沒人說話了。這種現象背後，往往是團隊習慣了找問題，卻缺乏設計方案的能力和流程。
缺口四：結論沒有追蹤（缺 E）
就算會議最後有了結論，散會後也沒人執行。因為沒有明確的負責人、沒有清楚的時程、沒有追蹤機制。兩週後開會，發現大家都在等別人動作，專案還停在原地。
而這四個缺口對應的就是 PACE 框架的四個階段。
使用 PACE 來設計決策流程，就能確保團隊在每個環節都有清楚的目標和方法。
會前、會中、會後 用 PACE 辦一場會議
接下來會帶你走過一個完整的決策會議流程，無論會前準備到會後追蹤，每個階段都有具體的操作步驟。以下是跨部門專案遇到交付延誤，團隊需要在兩週內找出解決方案的真實案例，會使用它來做說明：
階段一：會前準備（P – Pinpoint）- 用 30 分鐘省下 3 小時
真正高效的會議都從會前準備開始。身為決策主持人，需要在會議前做好三件事。
準備 1：寫清楚我們要決定什麼
用 5W2H 把問題定義清楚。模糊的問題定義會導致模糊的討論。
案例對比：
- ❌ 模糊版：討論專案問題
- ✓ 清晰版：決定如何在 2026/2/2-2/16（2週內） 解決 2025/12/1-12/31 期間因需求變更導致的交付延誤
會議資訊：
- 時間： 2026年2月2日（週日）14:00-16:00
- 地點： [會議室/線上連結]
- 與會者： 專案經理、產品經理、技術主管、測試負責人
會議流程：
| 時間 | 階段 | 重點任務 |
| 14:00-14:30 | 分析階段(A) | 盤點現況數據、拆解延誤原因 |
| 14:30-15:00 | 方案設計(C) | 提出至少3個解決方案 |
| 15:00-15:15 | 決策執行(E) | 確定方案、分工與時程 |
| 15:15-16:00 | 緩衝與Q&A | 釐清疑問、確認下一步 |
清晰版需要明確三個關鍵要素：
What（問題定義與數據指標）
- 核心問題：需求變更導致的交付延誤
- 必須準備的數據指標：
- 現況數字：實際發生了什麼（例如：需求變更10次、延誤14天、測試人力2人）
- 目標數字：我們期望達成什麼（例如：需求變更≤2次/月、準時交付、測試人力4人）
- 落差分析：現況與目標的差距就是會議要對焦解決的問題核心
When（時間範圍）
- 問題發生期間：2025年12月1日至12月31日
- 解決時間範圍：2026年2月2日至2月16日（2週內）
- 本次會議時間：2026年2月2日 14:00-16:00
How（解決方式）
- 透過結構化的PACE會議流程找出可執行的解決方案
- 依照上述會議流程表，從分析、方案設計到決策執行，系統化地處理問題
當與會者收到這樣的會議通知時，就能清楚知道這次要討論的範圍、需要準備的資料，以及會議將如何進行。
準備 2：列出需要哪些資料
把需要的資料列清楚，讓與會者有時間準備。沒有資料支撐的討論，很容易變成憑感覺。
案例所需資料：
- 過去 3 個月需求變更紀錄
- 各階段延誤時數統計
- 現有資源配置狀況
- 客戶端溝通記錄
當大家帶著資料來開會，討論才有依據，不會陷入我覺得、我猜想的空談。
準備 3：定義決策標準
團隊需要知道：我們用什麼標準來評估方案？時程重要還是成本重要？品質優先還是速度優先？
案例的決策標準：
- 優先順序一：確保 2 週內交付（時程優先）
- 優先順序二：維持核心功能品質（品質底線）
- 優先順序三：控制額外成本（成本考量）
有了共同的評估標準，團隊在討論方案時才不會各說各話。
| 會前準備檢查表 | 具體行動 | 預期產出 |
| 問題定義 | 用 5W2H 描述清楚 | 一句話的會議目標 |
| 資料準備 | 列出需要的數據和資訊 | 資料清單（會前 3 天發給與會者） |
| 決策標準 | 定義優先順序 | 方案評估的共同基準 |
階段二：會議討論（A + C）- 前半場分析，後半場方案
一個 90 分鐘的決策會議，建議分成兩個階段：前 30 分鐘做分析（A），中間 30 分鐘設計方案（C），最後 15 分鐘做決策和規劃執行（E）。剩下的 15 分鐘當作緩衝。
前 30 分鐘：分析階段（A）
步驟 1：盤點現況（5 分鐘）
主持人先用數據說明：發生了什麼事？不要主觀判斷，只陳述事實。
案例說明：「專案原定 8 週完成，目前已經第 10 週仍未交付。過去 3 個月收到 10 次需求變更申請，測試階段發現資源只有 2 人但實際需要 4 人，跨部門審核流程平均需要 3 天。」
步驟 2：MECE 拆解可能原因（15 分鐘）
用白板或線上協作工具（如Figma），把可能原因結構化地列出來。同時用 MECE 原則：互斥、窮盡。
案例的 MECE 拆解：
交付延誤
├─ 需求變更頻繁（10 次）
│ ├─ 客戶端需求不明確
│ └─ 內部需求管理機制不足
├─ 測試資源不足（2 人 → 需要 4 人）
│ ├─ 人力配置失準
│ └─ 工作量低估
└─ 跨部門協調延遲（審核流程 3 天）
├─ 流程過於繁瑣
└─ 權責不清楚
把原因視覺化，團隊才能看到問題的全貌，而不是各自只盯著自己關心的部分。
步驟 3：找出關鍵因素（10 分鐘）
不可能同時解決所有問題。團隊需要投票或討論哪個是最該優先處理的根本原因。但投票只是第一步，更重要的是用數據驗證我們的判斷。
案例討論結果：團隊共識認為「需求變更頻繁」是主因。因為每次變更都會連帶影響測試和協調流程，如果能控制需求變更，其他問題也會減輕。
數據驗證：檢查假設是否為真且足夠重要
光有共識還不夠，我們需要用數據驗證這個原因假設：
| 驗證問題 | 關鍵數據 | 驗證結果 |
| 這個原因存在嗎？ | • 需求變更次數：10次 / 3個月 • 遠超業界標準的 2–3 次 / 月 | ✓ 確認頻率異常高 |
| 它影響範圍大嗎？ | • 每次變更都需重新測試 • 波及審核流程（+3天） • 測試人力本已不足（2人 vs 需4人） | ✓ 確認連鎖影響大 |
| 它是主要原因嗎？ | • 專案延誤 2 週 • 需求變更是唯一持續發生的變數 • 其他問題（測試人力、審核）相對固定 | ✓ 確認是主因 |
驗證結論： 數據證實「需求變更頻繁」不僅是真實存在的問題，且每次變更都會引發連鎖反應，是導致專案延誤的核心原因。
中間 30 分鐘：創造方案（C）
步驟 1：至少產出 3 個方案（15 分鐘）
確認關鍵因素後，接下來進入方案設計階段，很多團隊習慣只討論一個方案，但單一方案沒有比較基準。我建議至少要有三個可行方案，才能看出差異和取捨。
案例的三個方案：
- 方案①：導入需求凍結機制（後續變更必須走正式變更流程，評估影響後才能執行）
- 方案②：增加測試人力（從 2 人增加到 4 人，加快測試速度）
- 方案③：調整專案範圍（砍掉非核心功能，專注在必要項目上）
步驟 2：評估可行性（10 分鐘）
用 Impact（影響力）× Effort（執行難度）矩陣來評估每個方案。
| 方案 | 影響力 | 執行難度 | 評估 |
| 方案①：需求凍結機制 | 高（直接減少變更） | 低（流程調整即可） | ✓ 優先考慮 |
| 方案②：增加測試人力 | 中（提升測試速度） | 高（需招募或調派人力） | 短期內難執行 |
| 方案③：調整專案範圍 | 高（減少工作量） | 中（需與客戶溝通） | ✓ 優先考慮 |
步驟 3：討論風險與配套（5 分鐘）
每個選擇都有風險。把風險和配套措施討論清楚，執行時才不會措手不及。
案例風險評估：
- 方案① 風險：客戶可能不滿，認為失去彈性
- 配套措施：專案經理本週五前與客戶溝通，說明需求凍結是為了確保品質和時程
階段三：決策與執行（E）- 最後 15 分鐘決定行動
會議最後 15 分鐘是整場討論的關鍵。如果這個環節沒做好，前面的分析和方案都只是紙上談兵。團隊必須回答四個問題：
問題 1：我們決定做什麼？
根據評估結果，做出明確選擇。可以是單一方案，也可以是組合方案。
案例決策：採用方案① + 方案③ 組合 – 啟動需求凍結機制 – 同時調整專案範圍，砍掉 3 個非核心功能
問題 2：誰負責？何時完成？
每個行動都要有明確的負責人和完成時間。模糊的分工等於沒有分工。可以套用ARCI原則，要知道誰負責(Accountable)、誰執行(Responsible)、可以諮詢誰(Consult)、必須告知誰(Inform)。
案例分工：
| 行動項目 | A 最終負責 | R 實際執行 | C 諮詢對象 | I 告知對象 | 完成時間 |
| 需求凍結機制啟動 | 專案經理 | 專案經理 | 產品經理 客戶 | 技術主管 測試團隊 | 本週五前 |
| 專案範圍調整 | 產品經理 | 產品經理 | 專案經理 技術主管 | 客戶 開發團隊 | 下週一前 |
| 內部宣達與說明 | 技術主管 | 技術主管 | 專案經理 | 開發團隊 測試團隊 | 下週二前 |
問題 3：如何追蹤？
設定領先指標和落後指標。領先指標讓你看見過程，落後指標確認最終結果。
案例追蹤指標：
- 領先指標：需求變更申請單數量（目標從 10 次/月降到 2 次/月）
- 落後指標：專案交付時程（目標 2 週內完成）
問題 4：下次討論時間？
決策不是結束，而是開始。設定下次檢視時間，確保執行不會斷線。
案例時程：2 週後進行 AAR 覆盤，檢視預期 vs. 實際結果。
| 決策四問 | 案例答案 |
| 我們決定做什麼？ | 方案① + 方案③：需求凍結 + 調整範圍 |
| 誰負責？何時完成？ | 專案經理（週五前）、產品經理（下週一前） |
| 如何追蹤？ | 領先指標：需求變更次數 / 落後指標：交付時程 |
| 下次討論時間？ | 2 週後 AAR 覆盤 |
階段四：會後追蹤（E 的延續）- 72 小時內啟動第一個檢查點
會議結束不代表決策完成。建議在 72 小時內設定第一個 Check Point，確認執行有沒有開始。
案例 72 小時檢查：週三（會議後第三天）檢視「客戶是否同意需求凍結機制」。如果客戶還沒回應，專案經理需要立即追蹤。
2 週後 AAR 覆盤四個問題：
- 原本預期需求變更會減少到 2 次/月，實際呢？
- 專案真的在 2 週內完成了嗎？
- 過程中有什麼意外或新發現？
- 下次遇到類似問題，我們可以怎麼做得更好？
只要把經驗轉化成團隊的知識資產，下次決策就能更精準。
流程設計比開會技巧更重要
決策品質的提升，往往就從一個好的流程設計開始。
下次要召開重要決策會議時，嘗試寫清楚問題定義，提前讓團隊準備資料，會議中按照 P-A-C-E 的技巧引導討論，會後設定明確的追蹤機制。，
讓每個人都知道自己在決策流程中的定位，也知道何時該做什麼貢獻。
一旦流程成為共識，會議自然會回到它該扮演的角色：幫助團隊做出選擇，並能確實往前執行。
