最常見的第一句話

從今天進入鼠勾以的重點：七大問答區塊。在開始第一塊之前，先把整張地圖攤開。

七塊的順序是有意設計的：先確認「為什麼做、給誰用、怎麼算成功」這三個方向問題，再往下談「做什麼、怎麼做、要什麼資料、有哪些例外」這四個執行問題。今天從第一塊「The Why」開始，也就是專案背景。

需求方PM 進來填需求，第一句話有超高機率是這句：

「我和老闆談完後，覺得想要做自動化。」

這句話資訊量他以為他講完了，其實接近於零。只告訴你「誰交代的」，沒告訴你「要解決什麼問題」。但很多需求單就是這樣送出去的，工程師收到後一臉問號：到底是為了拉回購率？降低客服抱怨？還是純粹老闆看到競品有？答案不同，做法天差地遠。

所以區塊 1 的任務只有一個：把「主管要做」翻譯成「我們要解決的問題」。

為什麼 The Why 排第一

在問「要做什麼功能」之前，得先問「為什麼要做」。順序不能反。

如果跳過 Why 直接問功能，你會得到一張功能清單，但沒有人知道這些功能是為了什麼存在。等到開發到一半，有人問「這個功能到底要幹嘛」，全場沉默。Why 是後面所有區塊的地基，地基歪了，上面蓋什麼都歪。

這也是 Day 1 講的那個病根的解方。需求方跟開發之所以變成「一邊發包、一邊接單」，很多時候沒先把 Why 講清楚：開發端不知道自己在為什麼而做，需求方也說不出到底想解決什麼。

把 Why 釐清，本質上就是讓兩邊回到同一條船上，對著同一個問題一起使力，如果認定彼此為一個團隊的話

四個面向

區塊 1 拆成四個面向，一個一個確認：

• 要解決的問題：現在大家遇到什麼困擾、什麼「要是能改善就好了」的事。
• 目前的做法：碰到這個問題現在怎麼處理，有沒有暫時的 workaround（像是用 Excel 土法煉鋼）。
• 為什麼是現在：這個需求為什麼這個時間點冒出來，有沒有時間壓力或契機。
• 預期好處：做完之後希望看到什麼改變，最好能講到一個可以衡量的方向。

這四個問題答完，「主管要做」就被拆成一個有頭有尾的故事：因為有 A 問題、現在的 B 做法不夠好、剛好 C 時機到了、所以想做出來換取 D 好處。

同一題，三種人三種問法

需求方PM 不是一種人。同一個問題，鼠勾以會根據對方的狀態切換問法：

• 有想法但說不清楚（讓流程方便一點）：幫他覆述成一句清楚的問題陳述，再問「你的意思是不是這樣？」
• 完全沒想法（沉默，或「主管叫我做的」）：給情境選項，降低思考門檻。畫面上會長這樣：

我列幾種常見的狀況，你看哪個比較像：
A. 流程太繁瑣，大家不想用
B. 想做的事沒有對應功能
C. 資訊不清楚，常常搞錯

• 有明確想法（能具體講出問題跟期望）：不浪費時間在基礎題，直接記錄，追問影響範圍。

一次一題、附情境選項。差別在於區塊 1 是整段對話的第一印象，問法要特別親切，先讓人放鬆下來。

挑戰機制第一次登場

Day 4 說過鼠勾以要會 push back。區塊 1 就是它第一次出手的地方，因為「主管要做」這種答案最需要被挑戰。

幾個典型場景：

• 使用者只說「主管要做」、講不出實際問題 → 鼠勾以會說：「主管要求是動機，但還不是問題本身。這個需求想解決的具體狀況是什麼？有沒有數據或客訴可以佐證？」
• 使用者說「競品有做我們也要做」 → 「競品有做不代表我們需要。我們的使用者有反映需要嗎？還是我們其實在解決不一樣的問題？」
• 預期好處只給「體驗會變好」 → 「『體驗變好』有點模糊。具體來說，使用者現在哪一步最痛？做完之後那一步會怎麼改善？」

挑戰的語氣是溫和的：先肯定，再帶出問題，後面接一個具體提問。如果使用者被問了還是堅持原答案，鼠勾以就尊重他、記一筆 \[風險備註] 到待確認清單，不再追。畢竟它的角色是幫忙釐清，不是把人逼到牆角。

不確定，就記待確認

不是每一格都要當場填滿。如果使用者對某個面向真的答不出來（例如「預期好處」想不到具體數字），鼠勾以不會硬逼，會說「沒關係，這題我先記下來，之後問相關的人就好」，把它放進待確認清單。

留白也是一種誠實的完成。一份標明「這幾項還沒確認」的需求，比一份每格都硬填、但全是猜測的需求，對後面的 SA 有用得多。

小結

區塊 1 做的事，是把需求方PM 那句「主管要我做」，拆成「問題、現況、時機、好處」四塊，並在第一時間用溫和的挑戰擋掉「競品有做」「體驗變好」這類空話。地基打穩了，後面才有得蓋。

明天我們進到區塊 2「The Who」：當使用者說「給所有客戶用」的時候，怎麼把這個含糊的「所有人」，拆成一個工程師做得出來的具體對象。

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