產品功能開發排序邏輯: MoSCoW

Po-chiang "Bob" Chao · 2025 年 5 月 7 日 · 約 1 分鐘

我認為產品經理最重要的「功能」是選題，而挑選過程裡經常需要平衡各種因素，那麼就又關乎排序。由於不時會跟人聊到，我打算不定時地稍微整理一下我用（或嘗試用）過的排序邏輯，附加一些個人的 Comments。

第一篇先提最容易考慮的 MoSCoW。

MoSCoW 協助產品經理根據需求的重要性與價值進行分類，這個詞是以下四類的縮寫：Must have（必須有）、Should have（應該有）、Could have（可以有）、Won’t have（這次不會有），其中的 o 僅為發音方便而加入。

此方法由 Dai Clegg 在 1994 年時提出，是個古老（？）的排序邏輯。由於解釋容易、分類單純，所以用的人蠻多的，甚至不知道這個方法名稱也很容易自己推導出「哪個是一定要有的」這類的想法。

Must Have（必須有）：不可妥協，或者以我的話來說會稱為「不做會死」的需求。若缺少這些項目，產品將無法達成基本目標，或會被視為不完整。理論上在 MVP 裡應該都是這邊的東西，也都會優先處理。
Should Have（應該有）：如果上個是「不做會死」，那這個或許就是「沒有的話會很辛苦」，屬於重要但非立即必要的需求，通常安排在 Must Have 完成後開發。雖然略過這些功能會造成不便，但並不致命。
Could Have（可以有）：或者你也可以稱為 Nice to have，可提升產品價值但非必須的功能。一般在資源與時間允許的情況下才會開發。
Won’t Have（「這次」不會有）：因為任何原因不會放進「這次」開發範圍的功能。

由於此方法本身不處理價值觀，沒想清楚就拿起來用的話，大概還是免不了要針對「為什麼這個東西會是 Should Have 而不是 Could Have」吵一架。（Must 的部分因為我自己定義是「不做會死」，所以反而容易一點。）
經過大肆許願再分類以後，每個類別裡的東西可能還是多到得排序，這時就沒有太多準則了。

**先跟團隊及糕層對齊產品目標，再用這個目標來考量 MoSCoW。**跟各種目標一樣，我會建議先挑最重要的目標來考量，有餘裕再去考慮其他，別輕易說我要全部。糕層是「不理他你會很糟糕」的那幾層。
搭配一個 timebox 來考慮，timebox 越短你可以越有自信地把東西丟 Won’t Have。在該時段內就是從上做到下，時段結束以後整個連 Won’t have 一起考量、重新分類後再來一輪。如果其實你知道這個點子「不該」做，也有權利說不做，那就直接拿掉不要出現在這些分類裡。
每個分類裡面的排序，等要執行那個分類時再來排可能方便點，畢竟做的過程裡也可能改變不同類別下的內容。

其他這個系列的文，沒連結的就是還在寫/還在富奸：

我不時會在 LinkedIn 或 Facebook 分享些關於產品管理的看法/見聞/活動，另有讀書會跟線上諮詢，有興趣可以前往 https://www.bobchao.net

如果你覺得這篇還不錯的話，何不幫我按幾下掌聲，幫助演算法讓這篇飄遠一點，幫助其他跟你一樣的人？