概念地圖・MoSCoW 優先級
作者 山姆（謝冠生）・喵喵書評創辦人
發布 最後更新
分類：生產力
這一頁不只是把一個概念解釋一遍——一張自己畫的結構圖，加上拿台灣情境從頭走一次的實例演練、這個框架什麼時候會騙你，以及它接回 P.A.I.N. 之後長什麼樣。一頁必須交付的三層 →
MoSCoW 優先級：這次，哪些非做不可
時間有限、資源有限，但要做的事總是無窮無盡。當所有需求都喊著「我很重要」，團隊就會陷入「什麼都想做、結果什麼都做不完」的泥沼。MoSCoW 是一個簡單到不行卻極有效的排序法：把所有待辦，狠心分進四個桶——一定要（Must）、應該要（Should）、可以要（Could）、這次不要（Won't）。它逼你面對一個殘酷但必要的問題：如果只能做一部分，哪些是真的非做不可？
四個桶，各裝什麼
MoSCoW 的關鍵，是每個桶都有清楚的定義，逼你做出真正的取捨。看懂每個桶的門檻，你才分得準。
| 桶 | 意思 | 判斷標準 |
|---|---|---|
| Must 一定要 | 核心必需，不做就整個失敗 | 沒有它，交付就沒意義 |
| Should 應該要 | 重要，但短期內可以先不做 | 會痛，但撐得過去 |
| Could 可以要 | 錦上添花，有餘力才做 | 沒有它，影響不大 |
| Won't 這次不要 | 明確排除，這一輪不碰 | 共識「先不做」，停止糾結 |
怎麼用 MoSCoW，才不會全塞進 Must
MoSCoW 最大的失敗，是每個人都把自己的需求塞進 Must。抓住下面三個判準，才排得出真優先級。
Must 的門檻要嚴：不做「就會失敗」才算。Must 指的是「沒有它，這次交付就毫無意義、或根本動不了」——比「很重要」還高一個門檻。一個好用的檢驗法：問「如果這項不做，我們還能上線／交付嗎？」如果答案是「還是可以，只是不夠好」，那它就該降到 Should。Must 一旦浮濫，優先級就形同虛設。自問：這項若拿掉，整個交付是「失敗」還是「只是遜一點」？
最有價值的一格，是那個「Won't」。多數人排優先級，只排前三桶，對「不做什麼」含含糊糊。但 MoSCoW 的靈魂，正是那個被明確寫下的 Won't——它讓「這次不做」成為團隊的共識，而非懸而未決的模糊地帶。寫下 Won't，你才真正停止在那些事情上內耗，把精力鎖進該做的地方。自問：我有沒有勇氣，把某些「其實也不錯」的東西，明明白白放進「這次不要」？
控制 Must 的份量，別讓它塞爆整個時程。一個健康的 MoSCoW 清單，Must 的工作量不該吃掉全部的時間與資源——通常建議控制在六成上下，留下餘裕給 Should 和意外。如果光是 Must 就已經爆表，問題多半出在範圍本身太貪心，跟排序無關，該回頭砍。自問：我的 Must 清單，是留了餘裕，還是已經把時程塞到毫無彈性？
拿它排一次：一個 App 的首發版本
套一個做產品的具體場景就懂。一個小團隊要做「記帳 App」的第一版，功能想法一大堆，用 MoSCoW 排一遍。
- Must：記一筆帳、看本月總支出——沒這兩項，它根本不算記帳 App。核心中的核心
- Should：分類統計、匯出報表——重要，但第一版沒有也能用、能收到回饋。
- Could：深色模式、自訂圖示——加分項，有餘力再說。
- Won't（這次）：多幣別、投資追蹤、AI 理財建議——明確排除，留給以後。狠心不做
這個團隊如果不排 MoSCoW，很可能一頭栽進「多幣別」「AI 建議」這些聽起來很酷的功能，六個月後做出一個複雜、遲遲上不了線的半成品。而排完 MoSCoW，他們清楚看見：第一版只要把 Must 那兩項做到好，就是一個能用、能上線、能開始收集真實用戶回饋的產品。這正是 MoSCoW 對做產品最大的價值——它幫你守住「先做出一個能用的最小版本」的紀律，對抗「什麼都想加」的本能衝動。更關鍵的是那個 Won't：把「多幣別、投資追蹤」明明白白放進「這次不要」，團隊就不會在開發途中被這些念頭反覆拉扯、偷偷把範圍撐大。優先級排序的真正難處，從來是有沒有紀律決定「這次先不做什麼」——「要做什麼」大家都搶著決定。能狠心填好 Won't 那一格的團隊，才交得出東西。以上為說明結構用的示意情境，僅供理解框架之用。
這個方法，什麼時候會騙你
MoSCoW 簡單好用，但簡單也帶來一些陷阱。三個邊界要記得。
- 它幫你「分類」，「排序」還得靠你自己。MoSCoW 把事情分成四桶，但同一個 Must 桶裡，哪一項要先做，它沒說。當 Must 桶裡有十件事、卻不能同時進行時，你還需要別的方法（如加權評分）在桶內再排先後。它是粗分類的第一關，算不上精細的排程表。
- Must 桶容易被政治與情緒灌水。因為「Must」聽起來最重要、最有份量，每個利害關係人都會想把自己的需求塞進去。少了嚴格的定義和有力的主持人把關，Must 桶很快就會膨脹到失去意義。這個方法的成敗，很大程度取決於「有沒有人敢說不」。
- 它是「這一輪」的快照，稱不上永久判決。放進 Won't 的東西，意思是「這次先不做」，以後仍可能被重新拿出來做。優先級會隨情況改變——這輪的 Could，下輪可能升級成 Must。若把 MoSCoW 的結果當成一勞永逸的定論、之後再也不檢視，反而會綁死自己。它需要每一輪重新盤過。
用痛點的眼光，再看一次 MoSCoW
MoSCoW 表面上是個「排功能優先級」的工具，但擺進《痛點》的框架，它其實在逼你回答一個更根本的問題——你的產品，到底是為了解決哪一個「非解不可」的痛而存在。那個 Must 桶，理想上不該塞滿一堆功能，而該對準「一個最痛的痛」：如果不解決它，整個產品就沒有存在的理由。太多團隊的 Must 桶之所以爆炸，根源不是排序沒做好，而是他們從一開始就沒想清楚「我到底要解誰的、哪一個痛」——因為目標模糊，每個功能看起來都像必需，於是什麼都想塞進 Must。反過來，當你對那個核心的痛有清晰的認識，MoSCoW 會變得異常好排：凡是直接解決那個痛的，是 Must；讓解法更順的，是 Should；錦上添花的，是 Could；跟那個痛無關、只是「好像也不錯」的，全部丟進 Won't。所以排不出優先級，根子常常在「痛點沒對焦」，跟紀律關係不大。先用《痛點》的尺，把那個「非解不可的痛」找到、講清楚，再回來排 MoSCoW，你會發現那個最難的 Won't 桶，突然變得很好填——因為凡是離那個核心痛太遠的，你都捨得放下了。對焦一個痛，勝過排序一百個功能。
關於 MoSCoW，常被問到的幾件事
MoSCoW 是什麼？四個字母代表什麼？
MoSCoW 是一種需求優先級排序法，把待辦事項分成四類：Must have（一定要，不做就失敗）、Should have（應該要，重要但可稍晚）、Could have（可以要，錦上添花）、Won't have this time（這次不要，明確排除）。中間的兩個 o 只是為了好唸。它常用於敏捷開發與專案管理，幫團隊在資源有限時聚焦。
Must 和 Should 怎麼區分？
關鍵在問「不做它，這次交付還算成功嗎」。Must 是「沒有它，整個交付就失敗或毫無意義」；Should 是「沒有它會很痛、很可惜，但交付仍然成立、還能運作」。一個實用的檢驗：如果拿掉某項，你「還能上線」，那它就是 Should 而非 Must。嚴守這條線，才不會讓 Must 桶灌水。
為什麼要有「Won't」這一類？
因為明確地決定「這次不做什麼」，跟決定「要做什麼」一樣重要，甚至更難。Won't 把「不做」變成團隊的白紙黑字共識，避免這些項目在開發途中反覆被提起、偷偷把範圍撐大。它幫團隊停止在那些事情上內耗，把精力鎖進該做的地方。少了 Won't，MoSCoW 就少了它最有紀律的一半。
MoSCoW 適合用在哪些地方？
凡是「需求很多、資源有限、必須取捨」的場合都適用：軟體開發的功能規劃、專案範圍界定、活動籌備、甚至個人的年度目標排序。它的優點是簡單、直覺、人人都懂，很適合快速對齊團隊共識。但要注意它只做「粗分類」，桶內的細部先後，還需要搭配其他排序方法。
MoSCoW 的紀律，本質上是「聚焦少數、狠心割捨」，這正是《少，但是更好》的拆書談的專準主義精髓。而「先做出一個能上線的最小版本、再靠回饋迭代」的思維，《精實創業》的拆書把它變成一整套創業方法。
喜歡這篇文章嗎？
每週幫你拆二本好書，把判斷力、好書金句、好問題，直送你的信箱。
不適合你可隨時退訂 · 每週兩封，陪你把書讀進生活。
送出即表示同意我們依隱私權政策使用你的 email。