The MOSCOW method: a complete guide

什麼是 MoSCoW 法？

MoSCoW 是一種優先順序排序技術，將專案需求、功能或任務分為四個類別：必須有（Must Have）、應該有（Should Have）、可以有（Could Have）和不會有（Won't Have）。小寫字母則是為了將這個首字母縮寫組合成一個實際的單字。該方法由甲骨文公司（Oracle）的 Dai Clegg 於 1990 年代開發，最初用於軟體開發專案，此後已被廣泛應用於專案管理、產品開發和更廣泛的規劃中。

MoSCoW 解決的核心問題是範圍蔓延和不切實際的規劃。當專案清單上的每件事都顯得至關重要時，團隊往往會承諾超出其交付能力的內容、低估風險，並在現實來臨時手忙腳亂。MoSCoW 強制提出了一個不同的問題：在既有的時間、預算和資源下，使該專案取得成功的最低要求是什麼？這個被明確提出並得到所有參與者同意的問題，往往能產生比假設一切順利的樂觀清單更誠實的計劃和更好的結果。

四個類別

必須有 (Must Have)

「必須有」是不可妥協的要求，沒有它們專案就會失敗或不值得發布。測試標準非常嚴格：如果你可以移除某個東西，而專案仍然可以運行（即使是以功能受損的形式），那它就不屬於「必須有」。如果你寧願取消或放棄專案，也不願在沒有此項目的情況下交付，那麼它就屬於這裡。

在實務中，「必須有」定義了最小可行範圍。它們是其他一切賴以生存的基礎。沒有「必須有」的產品根本稱不上是產品。

應該有 (Should Have)

「應該有」是重要且符合預期的，但沒有它們專案仍可維持可行性。這些是遺漏了會令人痛苦、利害關係人會注意到並想念的項目，但如果它們未能進入最終發布版本，並不構成專案的根本失敗。在時間和資源充足的情況下，「應該有」會被完成。在面臨壓力時，它們是進入下一階段的首選候選項目。

可以有 (Could Have)

「可以有」是令人嚮往但顯然並非必需的。「應該有」和「可以有」之間的區別在於缺失時的痛苦程度。「應該有」會帶來痛苦；「可以有」則只是輕微的失望。這些是「有了更好」的功能，在其他所有事情都完成且仍有餘力時才會去做。在面臨壓力時，它們會最先被捨棄。

不會有 (Won't Have)

「不會有」可以說是最重要卻最容易被忽視的類別。明確列出本專案或本版本中不會包含的內容有幾個作用：它透過從一開始建立共同的預期來防止範圍蔓延；它明確指出缺少這些項目是深思熟慮的決定，而非疏忽；它給了利害關係人一個放置合理但不適合本專案的想法和請求的地方，而不是讓它們作為隱性預期懸而未決。

「不會有」並不意味著「永遠沒有」，它意味著「這次沒有」。第一版本中的「不會有」可能是第二版本中的「必須有」。

60/20/20 法則

MoSCoW 伴隨著一項資源分配指南，旨在為專案建立彈性。分配給「必須有」的資源（時間、預算、精力）不超過總資源的 60%。分配給「應該有」和「可以有」的資源各不超過 20%。

其邏輯與風險有關。專案很少能完全按照計劃進行。估算會出錯，會出現意想不到的問題，依賴關係會產生偏差。如果 100% 的資源都承諾給了「必須有」，任何偏差都會變成危機。如果「必須有」僅消耗 60%，您就擁有 40% 的緩衝空間來應對意外。在最壞的情況下，您只需完成「必須有」，仍能交付一個功能完整、可發布的產品。在更好的情況下，您完成了「必須有」，並用剩餘的時間繼續進行「應該有」和「可以有」。

這意味著「必須有」清單需要保持精簡。如果誠實的答案是僅「必須有」就佔用了 80% 的可用資源，那麼要麼是您的「必須有」清單過於宏大（某些項目應該重新分類），要麼是您的資源估算過低，需要在專案開始前進行調整。

如何進行 MoSCoW 會議

聚集正確的人。 MoSCoW 透過使專案中的所有利害關係人（執行工作的人、委託工作的人，以及在相關情況下使用它的人）達成一致來發揮作用。該方法的價值來自於強迫達成共同協議，這需要在場的人都是正確的人選。

列出所有內容。 在分類之前，建立一個完整的需求、功能、任務或交付物清單。不要試圖邊列邊分類。先收集所有內容。這與 GTD 的在釐清前先收集原則類似：在做決定之前，把所有的東西都拿出來。

確立限制條件。 就可用的總資源達成一致：時間、預算、團隊能力。如果沒有具體的限制，分類練習就會變得抽象。有了限制，對話很快就會變得務實。

協同分類。 一起梳理清單。對於每個項目，問題是：在我們的限制條件下，這屬於哪裡？預期會有分歧，這正是重點所在。達成協議的摩擦正在發揮有用的作用：它使假設浮出水面，揭示隱藏的依賴關係，並產生對專案實際內容的共同理解。

驗證「必須有」的預算。 分類完成後，檢查您的「必須有」是否符合可用資源的 60%。如果不符合，請將項目移至「應該有」。不斷調整，直到類別變得切合實際。

明確記錄「不會有」。 不要只是讓這些消失。將它們記錄在顯眼的地方，以便日後有人詢問時（他們一定會問），能有一個清晰、一致的答案。

個人專案的 MoSCoW

該方法是為團隊設計的，但它也能很好地遷移到個人專案和規劃中。其價值是相似的：強迫自己誠實地面對專案實際需要什麼，與你理想中希望它擁有什麼。

如果您正在規劃一個副業、一個研究工作流程，甚至是一次房屋裝修，執行 MoSCoW 流程會強迫您遵守同樣有用的紀律。什麼會使這取得成功？不加入什麼我會後悔但還能接受？什麼其實只是一個好想法，而我應該停止假裝它是必要的？這次我明確不做什麼？

結合 Ivy Lee 方法使用，MoSCoW 為您提供了一種有原則的方式來選擇每日清單上的內容：依序為您進行中專案的「必須有」和「應該有」。

MoSCoW 何時運作良好

具有真實資源限制的固定範圍專案。 當存在真正的限制（截止日期、預算、團隊規模）迫使做出權衡時，該方法就會大放異彩。沒有真正的限制，類別就會保持模糊。

具有多個利害關係人的專案。 當不同的人對專案應該包含什麼有不同的想法時，MoSCoW 特別有價值。結構化的分類過程能在這些差異於專案中期演變成問題之前，及早將其暴露出來。

軟體與產品開發。 該方法的起源在此得到了體現。定義產品在特定發布版本中包含和不包含什麼，正是 MoSCoW 的設計初衷。

何時運作效果較差

持續進行或開放式的日常工作。 MoSCoW 是一個專案工具，而不是日常任務管理工具。對於沒有確定範圍或終點的工作，這些類別無法清晰地對應到您實際管理的內容上。

當限制條件不清楚時。 60/20/20 法則需要大致了解任何給定項目將花費多少時間或精力。如果估算高度不確定，分類可能會顯得任意。在這些情況下，在分類前進行粗略的估算會有所幫助。

當利害關係人無法承諾「不會有」清單時。 如果每個人原則上都同意，但「不會有」清單卻不斷被重新打開，MoSCoW 就暴露了一個一致性問題，該問題需要在專案順利進行前予以解決。

MoSCoW 與其他系統

GTD：GTD 收集並組織您必須做的所有事情。MoSCoW 則提供了一個優先順序視角，用於決定在給定的階段或衝刺中完成什麼。這兩者在不同的層面上運作：GTD 管理積壓工作，MoSCoW 塑造專案範圍。

PARA：在 PARA 組織的工作空間內，MoSCoW 幫助您確定什麼進入進行中的「專案」（Projects），而什麼被暫存到「資源」（Resources）中以便日後使用。「必須有」和「應該有」成為進行中的專案工作；「可以有」和「不會有」則成為積壓工作或未來的考量。

Ivy Lee 方法：Ivy Lee 方法中的每日六項任務應該來自進行中專案的「必須有」和「應該有」。MoSCoW 在專案層面決定什麼重要；Ivy Lee 則決定今天什麼獲得關注。

時間阻斷 (Time blocking)：先為「必須有」阻斷時間，然後是「應該有」。這確保了專案的關鍵工作獲得受保護的日曆時間，而不是被低優先順序的項目所擠壓。

看板 (Kanban board)：MoSCoW 通常與看板自然結合。這四個類別可用於標記卡片，或者在規劃期間可以為每個類別設置獨立的看板列。

常見問題

誰應該參與 MoSCoW 會議？

專案中的所有利害關係人：交付團隊、專案發起人或客戶，以及任何關鍵使用者或領域專家。MoSCoW 的價值來自於共同的協議，而不是某一個人對優先順序的看法。會議中如果缺少了關鍵利害關係人，往往會導致排出的優先順序在他們稍後介入時被修改。

如果利害關係人對某件事是否為「必須有」意見不一怎麼辦？

很好。這種分歧值得現在就暴露出來，而不是在工作開始之後。在這種時刻，引導者的工作就是回到測試標準：缺少這個項目會導致您取消專案或認為專案失敗嗎？如果不同利害關係人的答案不同，那麼您就遇到了範圍一致性問題，無論您使用哪種優先順序排序框架，都需要解決這個問題。

項目應該細化到什麼程度？

細化到足以付諸行動。「建立報告模組」對於「必須有/應該有」的區分來說可能過於寬泛。「使用者可以將數據導出為 CSV」則更有用。合適的細緻度取決於專案，但測試標準是您是否可以估算所述項目所需的精力。

項目可以在類別之間移動嗎？

可以。MoSCoW 不是一次性的練習。隨著專案的進展和資訊的變化，項目可以重新分類。一個在限制條件下技術上無法實現的「應該有」可能會變成「不會有」。一個事實證明微不足道的「可以有」可能會被提升為「應該有」。這些類別是規劃工具，而不是合約。

MoSCoW 與艾森豪矩陣 (Eisenhower Matrix) 相同嗎？

它們相關但不同。艾森豪矩陣按緊急性和重要性對任務進行分類，產生四個象限。MoSCoW 則根據專案需求對專案成功的必要性進行分類，產生四個類別。MoSCoW 是專為專案範圍管理設計的；而艾森豪矩陣主要是一個個人任務優先順序排序工具。

我可以將 MoSCoW 用於個人任務，而不僅僅是專案嗎？

可以，但需要做一些調整。對於複雜的個人專案（組織一場大型活動、建造某樣東西、規劃重大轉變），MoSCoW 提供了一個有用的結構來決定什麼是必不可少的，什麼是令人嚮往的。對於日常任務管理，它的開銷超出了大多數人的需要。Ivy Lee 方法或 GTD 的下一步行動往往更適合日常任務的優先順序排序。

MoSCoW 方法由甲骨文公司 (Oracle) 的 Dai Clegg 於 1990 年代開發，已被廣泛應用於軟體開發、專案管理和敏捷框架中。