2.2 需求挖掘與訪談技巧#

需求的「挖掘」而非「收集」#

需求不是像採果實一樣被「收集」起來的，而是像挖寶一樣被「挖掘（Elicit）」出來的——這正是英語中需求分析常用的詞 Requirements Elicitation。

為什麼用「挖掘」？因為真正的需求往往埋在表層之下：

• 使用者說「我要一個報表」，潛在需求可能是「我想看清楚業績下滑的原因」
• 使用者說「頁面太慢了」，潛在需求可能是「我要在客戶面前的演示不卡頓」
• 使用者沒說「倉管員戴手套不方便用滑鼠」，但這是真實痛點

好的需求分析師，不是滿足於使用者「說了什麼」，而是深入挖掘「他們真正要什麼」「為什麼要」「在什麼情境下用」。

需求挖掘的常用技術#

1. 訪談（Interview）#

一對一或一對多的直接對話，是最基本也最常用（卻也最容易被做壞）的方式。

技巧： - 先問開放式問題（「你現在是怎麼處理這件事的？」），再問封閉式問題（「你們一天大概處理幾筆？」） - 追問「為什麼」，往下挖一層：「為什麼要這個功能？」往往能發現灌輸給使用者過的既有做法，而非真正需求 - 讓使用者示範：「你實際操作給我看一下」——眼見為實，比抽象描述準確得多 - 記錄而不是當時設計：訪談時先完整傾聽與記錄，不要在當下急著給出解決方案，以免打斷思路或讓使用者順著你的建議走

2. 實地觀察（Observation）#

走進使用者的真實工作現場，觀察他們實際怎麼做事。這能發現使用者「說不出來」或「不自覺」的需求。例如觀察倉管員入庫流程，會發現他需要掃描槍、需要離線支援等，這些是坐在會議室訪談問不出來的。

3. 問卷（Questionnaire）#

當需要從大量使用者收集資訊時，問卷能規模化收集量化數據。但它缺乏訪談的深入性，適合用於「確認假設」與「收集統計」，而非「發掘未知需求」。

4. 原型（Prototyping）#

做出一個「快速又可丟棄」的雛形，讓使用者看到、摸到具體的東西，再據此回饋。這比純口頭描述精確得多，因為使用者看到原型才知道自己真正要什麼。在 AI 時代，原型製作成本大幅降低（見 2.6 節），成為需求挖掘的利器。

5. 腦力激盪與研討會（Workshop）#

召集利害關係人（stakeholders）一起討論，碰撞出單獨訪談想不到的想法。適合在專案早期、需求模糊時使用。

利害關係人：不要把「使用者」當成一個人#

需求分析最容易犯的錯誤，是只問「使用者」，而忽略其他利害關係人（Stakeholder）——所有會受到系統影響的人。

以訂位系統為例，利害關係人包括：

每個利害關係人的需求可能相互衝突——顧客想隨時改位子，老闆想限制改單以保證營收。需求分析師的工作，就是識別這些衝突、與利害關係人討論取捨，最終取得平衡。

記錄需求：從混亂到結構#

訪談和觀察會產生大量「混亂的原始資料」——筆記、錄音、白板照片、電子郵件。需求分析師的下一項工作，是把這些混亂轉化為結構化的需求描述。

傳統流程是：分析師手動把這些整理成「需求規格書」（SRS, Software Requirements Specification）。這份文件又長又重，而且很容易在開發中「過期」——程式碼改了、文件卻沒更新，兩者逐步脫節。

這正是 AI 可以大展身手的地方（詳見 2.5 節）：把訪談逐字稿、會議錄音、白板照片交給 AI，讓它提煉出結構化的使用者故事、功能清單與邊界條件。人類需求分析師的角色，從「手工轉譯的紀錄者」轉變為「引導 AI 提煉與驗證的指揮官」。

AI 時代需求挖掘的分工#

我們在 1.4 節已論證：AI 無法代替人類做「痛點發掘與訪談」。但需求挖掘的後半段——把混亂的訪談資料轉化為結構化需求——是 AI 非常擅長的。典型的分工是：

關鍵心法是：先質疑，後生成。永遠先讓 AI 清點風險、挖掘死角、確認分析師同意補償策略之後，才讓它生成正式的規格文件。不要在需求還沒釐清時，就急著讓 AI「做出東西」。

本章小結#

• 需求是被挖掘出來的，埋在表層之下
• 常用挖掘技術：訪談、實地觀察、問卷、原型、研討會
• 要考慮所有利害關係人，而非只問「使用者」
• 需求分析師的工作是識別衝突、取得平衡
• AI 時代：人類負責痛點與決策，AI 擅長結構化轉譯與死角挖掘
• 心法：先質疑，後生成

想一想#

1. 針對「線上訂位系統」，你能列出多少種利害關係人？他們的需求分別是什麼？
2. 訪談時為什麼要先問開放式問題、後問封閉式問題？
3. 用「訂位系統」訪談一位你身邊的人，記錄下他「說出來的」與「他真正要的」各是什麼。