一口氣倒出來的功能

前面三塊問完「為什麼、給誰、怎麼算成功」，區塊 4 問的是要做哪些功能。

前三塊的困難是使用者講不出東西，這一塊剛好相反：一旦開始講功能，需求方PM 通常停不下來。問「想做什麼」，他會從會員兌換講到後台報表、推播通知，再加一個問卷。問題出在最後那句：

「這些都很重要，全部都要。」

「全部都要」的實際效果是沒有第一版。開發端拿到一張沒有優先級的清單，只能自己猜哪些先做，或是照著時程硬塞，兩種結果都不好。區塊 4 的任務，是先把功能列清楚，再帶著使用者做取捨。

三件事：列出來、排順序、劃邊界

區塊 4 主要做三件事（第四件「每個功能的細節」會牽到規格基線，留給 Day 16）：

• 功能清單：把使用者腦中的功能一條條列出來，並主動幫他補上漏掉的。
• 優先級：哪些是第一版非做不可的 P0，哪些可以之後再說。
• 範疇邊界：這次「不做」的事也要寫下來，免得三個月後又長出來，建議對方可以填進Backlog的項目

列清單：由鼠勾以先拆，使用者只要確認

很多需求方PM 講功能時是用「結果」在講的，例如「就是一個兌換的東西」。這句話對開發端來說沒有可實作的內容。鼠勾以的做法是先把它拆成步驟，讓使用者確認，而不是要他自己組織：

我幫你拆解一下，你看看對不對：

1. 使用者先看到有哪些東西可以兌換
2. 選好之後確認兌換
3. 兌換完可以查到自己換了什麼
   大概是這樣嗎？還是少了什麼？

拆完之後還會用 CRUD（增、查、改、刪）再檢查一輪。使用者想到「兌換」，鼠勾以會接著問「兌換完查得到紀錄嗎？換錯了能取消嗎？」。這一輪通常會補出一兩個使用者沒想到、但上線後一定會被反映的功能。

排優先級：哪個是收銀台

清單列好之後，接著排優先級。

如果功能不多，鼠勾以會直接問「這幾個都是第一版就要有嗎？」。使用者一旦回「全部都要」，它就換一個角度問：

假設第一版只能先上線一半的功能，你會留哪幾個？
如果某個功能先不做，使用者還能完成最主要的那件事嗎？

如果還是選不出來，鼠勾以會換成開店的比喻：

這樣想好了，就像開一家店：收銀台一定要有，不然不能做生意（這是 P0）；但背景音樂可以晚點再裝（這是 P1）。你的功能裡，哪個是收銀台，哪個是背景音樂？

這個比喻有效，是因為它把抽象的「優先級」換成一個誰都判斷得出來的問題。需求方PM 可能說不清楚什麼叫 P0，但他分得出哪個功能「沒有就不能開店」。分完之後，第一版的範圍大致就確定了。

非分不可的原因是：當每個功能都標 high，就等於沒有 high。優先級的作用來自落差，有高有低，團隊才知道資源要先投到哪裡。時間、人力、預算都有上限，全部標成最高等於要求同時用盡全力做每一件事，實際結果通常是每一件都只做到堪用。優先級有分布，才能把有限的量能集中到最關鍵的地方，先做出一個能上線、能解決核心問題的版本。

劃邊界：把「這次不做」也寫下來

第三件事最容易被跳過，卻是後面最會出事的地方：明確寫下「這次不做什麼」。

需求方PM 的直覺是只記「要做的」，預設沒寫的就是不做。但開發端遇到的實際狀況，多半是兩邊各自以為有共識。這次沒講清楚「報表不做」，三個月後就會出現「我以為這本來就要做」的爭議，時程也跟著被壓縮。這就是需求蔓延（scope creep）。

所以鼠勾以會主動把常被「順便」帶進來的東西攤出來問：

你提到了兌換，通常做這個的時候也會有人想要：
A. 後台管理（讓管理者設定、調整）
B. 報表統計（看使用狀況）
C. 通知提醒（Email 或推播）
D. 以上都先不要
這些是這次要做，還是之後再說？

凡是被歸到「之後再說」的，鼠勾以不會直接丟掉，而是記進一份 Out of Scope 清單，再追一句「那這個未來會做嗎？」：

A. 未來一定會做（下一版或半年內）
B. 有可能，看這次上線的反應再說
C. 目前不確定

這一步有兩個好處。對需求方PM，他知道自己想做的事沒有被忽略，只是排隊；對開發端，好處更實際：知道未來會往哪走，工程師在設計這一版的規格時，就能順手做「預留設計」。

預留設計的意思是，這次不開發某個功能，但在架構上先留好接口、留好擴展的空間，讓未來要加的時候是「接上去」而不是「打掉重練」。舉個例子，這次只做單一語言介面，但如果知道未來想做多語系，工程師就會把文案抽成可替換的設定，而不是寫死在程式裡。差別在於，未來要擴充時，前者改一個設定，後者整份重做。

所以 Out of Scope 清單同時有兩個用途：對這一版劃清範圍，以及告訴開發端未來的方向。一份同時寫清楚「不做什麼、未來想做什麼」的需求，對後面接手的人有用得多。

挑戰：全部都要，等於沒有重點

The What 也是挑戰機制很常出手的地方，主要針對「全部都要」這個答案。

• 使用者堅持「功能都是 P0」 → 鼠勾以會說：「如果每個都是最高優先級，那其實就等於沒有優先級。真的全部砍到只剩一個，你會留哪個？那個才是真正的 P0。」
• 使用者一直加新功能 → 「這個想法不錯，我先記到 Out of Scope。不過先確認一下，它跟我們區塊 1 講的那個要解決的問題，有直接關係嗎？還是它其實是另一個需求了？」

第二個挑戰特別重要，它會把功能拉回去對照 The Why。跟原始問題沒有直接關係的功能，不論本身多有價值，都應該先放進「未來再說」，否則第一版的範圍會不斷被稀釋。

小結

區塊 4 做的事，是把「功能全部都要」拆成「列清單、排優先級、劃邊界」三件事：用 CRUD 幫使用者補齊漏掉的功能，用「收銀台 vs 背景音樂」逼出真正的 P0，再用 Out of Scope 清單把「這次不做、未來想做」的東西好好接住，擋掉需求蔓延。功能清單跟優先級確認完之後，鼠勾以不會直接跳去畫流程，而是先補問一輪「系統決策」跟「規格邊界」。Day 16 講的就是這份放在區塊 4 結尾的規格基線檢查表：五個看起來很瑣碎、但每一題都會影響工時的問題。

參考資料

• MoSCoW Prioritisation — DSDM Project Framework（Agile Business Consortium 官方）。（Must/Should/Could/Won't 四級分類，「Won't have」明列以防止範圍蔓延）https://www.agilebusiness.org/dsdm-project-framework/moscow-prioritisation.html
• Boehm, B. W., & Papaccio, P. N. (1988). "Understanding and Controlling Software Costs." IEEE Transactions on Software Engineering, 14(10), 1462–1477.（越晚改越貴）https://doi.org/10.1109/32.6191

這是 iThome 鐵人賽系列文章。明天見。