MoSCoW 方法 MoSCoW Method
把需求分為 Must/Should/Could/Won't 四級，30 分鐘內讓團隊對優先級達成共識。
什麼時候該用它？
當你需要在一群人之間快速達成「哪些需求先做、哪些延後、哪些不做」的共識時。MoSCoW 比 RICE 簡單、比 Impact-Effort 更有結構感。
- 版本規劃：決定下一個 release 要包含哪些功能
- Stakeholder 對齊：業務、設計、工程對需求優先級各有想法
- MVP 定義：從一堆想做的功能中篩出「最小可行」的那一組
- 專案啟動：開案時跟客戶確認「哪些是絕對要有的、哪些可以彈性」
- 時間壓力下的決策：Deadline 逼近，必須快速決定砍什麼
框架結構
四個等級
Must have（必須有）
沒有這些功能，產品不能上線。如果少了任何一個 Must，使用者無法完成核心任務。
判斷標準：「如果沒有這個，產品能不能用？」答案是「不能」→ Must。
建議佔比：不超過總需求的 60%。如果超過了，你可能把太多東西標成 Must。
Should have（應該有）
重要但不致命。沒有的話產品可以運作，但使用者體驗會明顯下降。
判斷標準：「使用者會不會因為沒有這個而不開心？」答案是「會」→ Should。
Could have（可以有）
錦上添花。有了更好，沒有也不會怎樣。
判斷標準：「使用者會注意到少了這個嗎？」答案是「大概不會」→ Could。
Won’t have（這次不做）
明確標記為「這一輪不做」，但不代表永遠不做。這是最重要的等級 — 它讓團隊知道哪些事情已經被考慮過但故意暫時排除。
跟 Kano 模型的關係
| MoSCoW | 對應 Kano |
|---|---|
| Must have | 必備屬性 |
| Should have | 期望屬性 |
| Could have | 魅力屬性 |
| Won’t have | 無差異 / 反向 |
來源與歷史
- 1994：Oracle 顧問 Dai Clegg 在 DSDM（Dynamic Systems Development Method）框架中首次提出
- 2000s：隨著敏捷開發流行，MoSCoW 從瀑布式專案管理進入 Scrum 生態
- 2010s：成為產品管理課程的基礎工具，特別在 Pragmatic Institute 和 Product School 的教材中
- 至今：Jira、Linear、Notion 等工具都支援 MoSCoW 標籤
真實案例：SaaS 平台 v2.0 版本規劃
一家做中小企業記帳 SaaS 的團隊要規劃 v2.0，收集到 28 個需求。經過 MoSCoW 分類：
Must have（8 個，29%）：
- 多幣別支援（3 個大客戶等著要）
- 報表匯出 PDF
- 二階段驗證（資安要求）
Should have（7 個，25%）：
- 自動對帳功能
- 銀行帳戶串接
- 行動版 App
Could have（6 個，21%）：
- 暗色模式
- 自訂報表範本
- 團隊協作功能
Won’t have（7 個，25%）：
- AI 自動分類交易（技術風險太高）
- 庫存管理模組（超出核心範圍）
- 多語系（台灣市場暫時不需要）
結果：團隊在 8 週內交付了 Must + 5 個 Should，v2.0 上線後大客戶續約率從 78% 提升到 92%。被放在 Won’t 的 AI 分類功能排到 v3.0，等到有更多數據再做。
使用步驟
Step 1：列出所有需求
把所有需求、功能請求、bug 修復列成清單。不要在這步做判斷。
Step 2：定義「Must」的標準
在分類之前，團隊先對齊：什麼條件構成 Must？建議標準：「如果少了這個，產品能不能上線/客戶會不會解約/法規有沒有問題？」
Step 3：先標 Must，再標 Won’t
先從兩端開始比較容易。Must 是「沒有不行」，Won’t 是「確定不做」。中間的再分 Should 和 Could。
Step 4：檢查 Must 比例
如果 Must 超過 60%，回頭重新審視。問自己：「這個真的是 Must 嗎？如果延後一個月交付，世界會毀滅嗎？」
Step 5：跟 Stakeholder 確認
把分類結果拿去跟老闆/客戶確認。重點是 Won’t 清單 — 讓他們知道「這些我們知道但故意不做」，而不是「我們忘了」。
這樣做 vs 避免這些
這樣做
- Won’t 也要寫下來 — 「明確不做」比「忘記了」好得多
- Must 不超過 60% — 如果全部都是 Must，等於沒有排序
- 每個等級都要有項目 — 如果 Won’t 是空的，代表你不夠有勇氣
- 跟團隊一起分類 — 獨自決定會失去 buy-in
避免這些
- 不要把 Should 和 Must 搞混 — 「老闆很想要」不等於 Must，「沒有使用者無法完成任務」才是
- 不要讓 Could 變成「以後再說」的垃圾場 — 定期清理，該刪就刪
- 不要在沒有上下文的情況下分類 — 必須先知道 deadline、資源、目標用戶
- 不要把 MoSCoW 用在技術架構決策 — 它是需求排序工具，不是架構設計工具
MoSCoW 在電商團隊最好用的場景是「大促活動前的功能凍結」。
台灣電商每年有幾個大促：38 女王節、618、雙 11、雙 12、年貨大街。每次大促前 1-2 個月，PM 都會面對一堆「老闆說大促前要上的功能」。MoSCoW 可以幫你把這些需求快速分級：
- Must：金流穩定性、庫存同步正確性、結帳流程不能有 bug — 這些出問題就是營收損失
- Should：限時搶購倒數計時器、滿額贈活動模組 — 有了更好，但不是活不下去
- Could：大促主視覺動畫、社群分享集章活動
- Won’t：新的推薦演算法（大促前不要動核心邏輯）
另一個實用場景：跟外部廠商（物流、金流）討論整合範圍時，MoSCoW 是最好的溝通語言。說「這個串接是 Must，那個是 Could」比說「這個比較重要」清楚太多。
最後一個提醒：台灣電商的 Must 清單裡，「LINE 通知」幾乎一定在裡面。出貨通知、到貨通知、退款通知 — 少了任何一個，客服就會被電話灌爆。