一口氣倒出來的功能

前面三塊問完「為什麼、給誰、怎麼算成功」，區塊 4 終於進到最害怕的部分：要做哪些功能。

這一塊的標準狀況剛好相反。一旦開始講功能，需求方PM 通常停不下來。你問「想做什麼」，他從會員兌換講到後台報表、講到推播通知、講到順便做個問卷，越講眼睛越亮。問題在最後那句：

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

「全部都要」這四個字，工程師聽到內心 OS 通常是：你有沒有聽見自己在講什麼？有想好什麼時候要上線嗎？因為「全部都要」就是「沒有第一版」，什麼都要的結果，通常是什麼都上不了。

區塊 4 的任務，就是先把功能攤平列清楚，再溫柔地告訴他：你得選。

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

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

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

列清單：鼠勾以幫你拆，不要你自己想

很多需求方PM 講功能時是用「結果」在講的，例如「就是一個兌換的東西」。這句話對開發來說又是個黑盒子。鼠勾以的做法是主動拆給他看，讓他用點頭的，不要他自己組織：

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

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

拆完還會用一個工程師的老朋友做健檢：CRUD（增、查、改、刪）。使用者想到「兌換」，鼠勾以會順手問「那兌換完查得到紀錄嗎？換錯了能取消嗎？」。這幾刀下去，常常會挖出一兩個使用者根本沒想到、但上線後一定會被客訴的功能。

排優先級：哪個是收銀台

清單列好，接著就是那場硬仗：排優先級。

如果功能不多，鼠勾以直接問「這幾個都是第一版就要有嗎？」。但只要使用者說出那句「全部都要」，它就會換個角度逼選擇：

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

還是選不出來的話，鼠勾以會搬出那個最好用的比喻：

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

「收銀台 vs 背景音樂」這個比喻威力很大，因為它把抽象的「優先級」換成一個誰都判斷得出來的問題。需求方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 鐵人賽系列文章。明天見。