為什麼需求訪談很難
用戶說的和用戶要的之間有三層落差：
- 說不清楚：用戶有模糊的痛點，但沒辦法描述成具體需求
- 說錯了：用戶描述的是「解法」而不是「問題」——「我要一個 Excel 匯出」，背後是「我要拿這些數據做報表」
- 說不完整：有些需求用戶視為理所當然，沒有主動說出來（「當然要支援手機」）
需求訪談不是「把用戶說的話記下來」，而是挖到背後的真實問題。
Want vs Need
Want（想要）：用戶主動說出來的，通常是解法。 Need（需要）：驅動這個 want 的真實問題，也是需求的核心。
| 用戶說的（Want） | 背後的 Need |
|---|---|
| 「要有 Excel 匯出」 | 需要把數據帶出系統做分析 |
| 「介面要像 Notion」 | 需要靈活的文字格式，而不是死板的表格 |
| 「要有通知功能」 | 不想一直打開系統看有沒有新資料 |
| 「要快」 | 某個流程等待時間太長，影響工作效率 |
挖 need 的方法：持續問「為什麼」，直到找到可以量化或可以設計的問題。
訪談流程
開場：設定範圍和目的，讓用戶知道你不是來評估他們的，是來理解他們工作流程的。
現狀探索：
- 「你現在這件事是怎麼做的？」（了解 AS-IS）
- 「哪一步最花時間？」
- 「什麼情況下會出錯？」
痛點深挖：
- 「這個問題造成的後果是什麼？」（量化影響）
- 「這個問題多久發生一次？」
- 「你現在是怎麼繞過這個問題的？」（workaround 往往能揭露核心痛點）
需求確認：
- 「如果我們解決了這個問題，你會怎麼知道它解決了？」（→ 驗收條件）
- 「有沒有這個需求是必須的，沒有的話系統就沒用？」（→ 區分 P0 vs nice-to-have）
把訪談結果轉成需求
User Story 格式（Agile 常用）：
作為 [角色]，
我想要 [功能]，
以便 [業務目的]。
加上 Acceptance Criteria（驗收條件）才算完整：
Feature: 訂單狀態通知
User Story: 作為物流人員，我想要在訂單狀態改變時收到即時通知，以便不用一直刷新系統。
Acceptance Criteria:
- 訂單從「待出貨」→「已出貨」時，1 分鐘內收到 LINE 通知
- 通知包含：訂單編號、更新狀態、更新時間
- 可以在設定頁關閉通知
- 如果通知失敗，系統要記錄並在隔天 batch retry
常見陷阱
陷阱 1：只訪談最大聲的人——大聲說話的未必是主要用戶，也未必代表多數人的需求。
陷阱 2：把 edge case 當主線——「萬一有人要同時批次上傳 10 萬筆呢？」在 MVP 階段，先做主線流程，edge case 留在 backlog。
陷阱 3：把需求確定性說得太高——需求會變，不要把訪談的結論當成最終規格，用迭代替代大設計。
陷阱 4：沒有記錄「為什麼這樣決定」——幾個月後沒有人記得當初這個需求為什麼存在，需求文件要記決策背景，不只記決策。