管理・思維
ProMoSCoW 優先序
MoSCoW Method · 出處: Dai Clegg / DSDM
當需求清單太長、團隊對「什麼是必要的」沒共識時，用四等級分類強迫排序
核心概念
Dai Clegg 1994 年在 DSDM 敏捷方法論中提出：把所有需求歸入四類——Must（沒有就 fail）、Should（重要但可延後）、Could（有更好但不關鍵）、Won't（這次明確不做）。最大的價值在於 Won't——明確排除比假裝什麼都做更誠實，也讓團隊不再為已排除的需求扯後腿。經典規則：Must 最多佔總工時的 60%。
✓ 適合在這些情境使用
需求清單失控、團隊對「什麼是必要的」沒共識、客戶/老闆對所有功能都標「重要」時。MoSCoW 的價值在於強迫排序、特別是強迫定義 Won't。
✗ 不適合用的情況
單一專案、需求很少時不需要——直接排序就好。也不適合用在策略性決定，那需要的是價值判斷不是分類。
引導問題預覽
使用這個框架時，你會被問到——
- 1.列出所有候選的需求/功能/任務（先不要排序）。
- 2.Must Have：哪些是「沒有就完全失敗」的？嚴格篩選。
- 3.Should Have：重要、但延後也能撐？
- …還有 3 個問題
填答範例
展開看一個假設情境填完後長什麼樣
›
填答範例
展開看一個假設情境填完後長什麼樣
情境
產品下個 sprint 要交付。團隊收集了 28 個需求，每個都被標為「重要」。3 週內不可能全做，要做 MoSCoW 排序。
1. 列出所有候選的需求/功能/任務（先不要排序）。
28 個需求列表（功能 + 修 bug + 改進 UI + 重構）。
2. Must Have：哪些是「沒有就完全失敗」的？嚴格篩選。
Must Have（沒有就 fail）：付款流程修復（已有客戶反應）、登入問題（影響所有人）、合規所需的隱私頁（法規期限）。共 3 條。
3. Should Have：重要、但延後也能撐？
Should Have：搜尋速度優化、新會員引導頁、3 個 P1 bug。共 6 條。
4. Could Have：有更好、沒有也行？
Could Have：新版主題色、會員徽章系統、社交分享功能、5 個 P2 bug。共 9 條。
5. Won't Have（這次明確不做）：哪些被你排除？為什麼？
Won't Have（這次明確不做）：新語言版本、AI 推薦功能、儀表板大改版、所有 P3 bug、商業模式變更實驗。共 10 條。明確排除避免後期偷渡。
6. Must 是否已超過 60% 總工時？如果是，哪些可以降到 Should？
Must 是 3 條 + 工時估 40%——OK，沒超過 60%。執行：先 Must、再 Should、Could 看時間 buffer 才碰、Won't 不討論。
在 ChatGPT / Claude 裡用
把下面這段貼進對話，AI 會逐題引導你跑完這個框架。
你現在是引導使用者跑 MoSCoW 排序的專案教練（Dai Clegg）。 依序問： 1) 列出所有候選需求/功能/任務。 2) Must Have：哪些沒有就完全失敗？嚴格篩——「重要」不算，「沒有它整個 release 失敗」才算。 3) Should Have：重要但延後也能撐？ 4) Could Have：有更好沒有也行？ 5) Won't Have（這次明確不做）：哪些被排除？為什麼？這欄最重要——明確排除避免後期偷渡。 6) Must 工時是否超過 60%？如果是，哪些可降到 Should？ 特別提醒：當使用者把 80% 都標 Must——他沒在排序。逼他用「沒有它，這次成功定義會崩潰嗎？」當門檻。 互動規則： 1. 一次只問一題，等使用者回答後再進入下一題。 2. 使用者答完所有題目前，不要做總結或下結論。 3. 若答案太抽象、太籠統，請追問一次具體例子或數字後再繼續。 4. 全部答完後，輸出三段：(a) 摘要使用者的關鍵判斷；(b) 你看到的盲點或張力；(c) 一個具體下一步行動建議。 5. 不要替使用者做決定，只把判斷攤開讓他自己決定。
相關框架
相關研磨誌