需求訪談是專案啟動階段最關鍵的技能——問對問題，才能挖出利害關係人真正的需求。這篇指南涵蓋訪談前準備、五種提問技巧、傾聽引導方法，以及訪談後的需求分析框架，幫你從第一場訪談就建立正確的需求收集流程。
為什麼 80% 的需求訪談得不到真實答案？
一個我們團隊親身經歷的場景：PM 花了兩週訪談八位利害關係人，整理出一份看似完整的需求文件，開發團隊埋頭做了三個月。上線當天，客戶看了五分鐘就說：「這不是我要的。」
問題不在開發，而在訪談。利害關係人說出口的需求，幾乎從來不等於他們真正的需求。
這種落差來自三個常見的失敗模式：
訪談者主導答案。 你問「你覺得加一個儀表板好不好？」對方當然說好——因為你已經暗示了答案。這不是訪談，是確認偏誤的自我實現。
問題太抽象。 「你對目前的流程有什麼看法？」這種問題讓受訪者陷入思考，最後給出一個經過美化的「官方答案」，而不是真實的日常痛點。
只問「想要什麼」，不問「現在怎麼做」。 受訪者描述的理想狀態往往脫離現實。真正有價值的資訊藏在他們每天重複的行為裡——那些笨拙的變通做法、手動複製貼上的步驟、用 Excel 土法煉鋼的流程。
失敗訪談：「你希望系統有什麼功能？」→ 得到一份許願清單 有效訪談：「上週你處理這件事的時候，從哪一步開始覺得卡住？」→ 得到真實的行為痛點
這篇文章會帶你走過完整的需求訪談流程：準備 → 提問 → 傾聽 → 分析。每個階段都有可直接套用的框架和話術，讓你的下一場訪談就能挖出更真實的需求。
需求訪談前的準備：三件事決定訪談品質
訪談品質大部分在你開口之前就決定了。準備不足的訪談，你可能問了很多問題，卻離真正的需求越來越遠。
確認訪談目的與假設清單
第一步不是寫問題，而是搞清楚：這場訪談要回答什麼？
需求訪談（Requirement Gathering Interview）分成兩種類型，準備方式完全不同：
- 探索型訪談： 你還不確定問題是什麼。目標是廣泛了解受訪者的工作流程、痛點和情境。問題設計偏開放，讓受訪者帶你走。
- 驗證型訪談： 你已經有初步假設（例如「使用者最大的痛點是審批流程太慢」），目標是確認假設是否成立。問題設計更聚焦，主動挑戰自己的假設。
不管哪種類型，訪談前都要建立一份假設清單（Assumption Log）：把你「以為」的需求先寫下來，訪談時刻意去驗證或推翻它。
我們團隊在一個電商平台專案中，PM 訪談前列出了五個假設：「用戶最在意結帳速度」「行動端體驗是主要痛點」「客服回應時間影響回購率」等。訪談八位用戶後，有三個假設被推翻——用戶最在意的其實是「找不到之前買過的商品」，這個需求完全不在原始假設裡。如果沒有假設清單，PM 可能會帶著確認偏誤，只聽到自己想聽的答案。
選對受訪者：誰的聲音最關鍵？
不是所有利害關係人的聲音都同等重要。你需要一張利害關係人地圖，區分三種角色：
- 決策者： 有權拍板的人。他們的需求決定專案方向，但往往離實際操作最遠。
- 使用者： 每天使用系統的人。他們的痛點最真實，但可能不會主動表達。
- 受影響者： 不直接使用，但會被改變影響的人（例如：新系統上線後，財務部門的報表格式會改變）。
最常見的錯誤是只訪談「最配合的人」。那些願意花時間跟你聊的人，通常是對現狀最滿意的人。沉默的使用者往往藏著最真實的痛點。
訪談人數方面，根據 Nielsen Norman Group 的研究，探索階段訪談 5 到 8 人通常可以達到資訊飽和點——也就是說，再多訪談一個人，得到的新資訊已經很少。但這個數字的前提是你選對了受訪者的多樣性，而不是訪談八個同部門的人。
設計訪談大綱（附格式範本）
訪談大綱不是問卷。問卷是逐題照唸，大綱是引導方向——你要根據受訪者的回答即時調整追問方向。
一份標準的訪談大綱包含四個區塊：
| 區塊 | 題數 | 目的 | 範例問題 |
|---|---|---|---|
| 暖場問題 | 2 題 | 建立信任、了解背景 | 「可以先聊聊你在團隊裡負責什麼？」 |
| 核心行為問題 | 4–6 題 | 了解現有流程與痛點 | 「上一次你處理 [任務] 的時候，從哪一步開始？」 |
| 深挖問題 | 彈性 | 追問細節、挖掘情緒 | 「你剛才提到這個步驟很麻煩，可以多說一點嗎？」 |
| 收尾 | 1–2 題 | 確認遺漏、開放補充 | 「有沒有什麼我沒問到，但你覺得很重要的事？」 |
暖場問題的重點是讓受訪者進入「敘事模式」，而不是「回答模式」。一旦他們開始講故事，後面的核心問題就容易挖到真實行為。
以下是一份完整的訪談大綱範本，你可以直接複製後根據專案情境修改：
【需求訪談大綱範本】
訪談資訊
- 受訪者姓名／職稱：
- 訪談日期：
- 訪談目的（探索型／驗證型）：
- 訪談前假設清單：
一、暖場問題（5 分鐘）
1.「可以先聊聊你在團隊裡主要負責什麼工作？一天的工作大概是怎麼安排的？」 2.「你在這個職位多久了？在這之前有用過類似的系統或流程嗎？」
💡 暖場目的：讓受訪者進入敘事模式，同時了解他的角色背景和經驗值，幫助你判斷後續回答的脈絡。
二、核心行為問題（15–20 分鐘）
3.「上一次你處理 [具體任務] 的時候，可以從頭到尾帶我走一遍嗎？從哪一步開始的？」 4.「在這個過程中，有沒有哪一步讓你覺得特別花時間或特別麻煩？」 5.「那個麻煩的步驟，你現在是怎麼處理的？有沒有用什麼替代方法或工具？」 6.「這件事你大概多久要做一次？每次大概花多少時間？」
💡 核心問題目的：錨定最近一次的具體經驗，從行為中挖掘痛點和變通做法。注意記錄受訪者提到的具體數字（頻率、時間）。
三、深挖問題（5–10 分鐘，根據回答彈性追問）
7.「你剛才提到 [受訪者說的痛點]，可以多說一點嗎？那次具體發生了什麼事？」 8.「這個問題發生的時候，你的第一個反應是什麼？你會找誰幫忙？」 9.「如果這個工具／流程明天消失了，你會怎麼完成這件事？」
💡 深挖目的：追問情緒線索和行為細節。注意語氣變化——當受訪者說「每次都要重做，真的很煩」和「還好啦，習慣了」，痛點強度完全不同。
四、收尾問題（5 分鐘）
10.「如果你可以改變現在工作流程中的一件事，你會改什麼？」 11.「有沒有什麼我沒問到，但你覺得很重要、想補充的？」
💡 收尾目的：第 10 題用限定「一件事」來逼出最高優先級的需求。第 11 題是安全網——受訪者常常在這題說出最關鍵的資訊，因為前面的對話已經幫他們暖好了思路。
在設計訪談大綱時，你也可以考慮這場訪談是否真的適合用訪談形式。如果你需要大量量化數據（例如「多少比例的用戶遇到這個問題」），問卷設計可能更有效率。訪談的強項是深度，不是廣度。
不誤導對方的提問技巧：五種問題設計法
提問是需求訪談的核心技術。問錯問題，你得到的不是需求，是受訪者的想像力。以下五種提問法，每一種都針對一個常見的訪談偏誤。
用「最近一次經驗」錨定具體行為
錯誤問法：「你通常怎麼處理請假申請？」 正確問法：「上一次你請假，從打開系統到完成申請，你做了哪些步驟？」
為什麼要錨定「最近一次」？因為人類描述「通常」的行為時，會自動美化和簡化。但回憶具體事件時，細節會自然浮現——包括那些他們覺得「不值得提」的小麻煩。
我們在一個 HR 系統專案中測試過這個差異。問「你希望請假流程怎麼改善？」，得到的答案是「希望更快」。改問「上週你請假，從哪一步開始覺得麻煩？」，得到的答案是「我要先在 Excel 查自己的假別餘額，再到系統填表，然後截圖傳給主管確認，因為系統通知常常漏掉」。第二個答案直接指向三個具體的改善方向。
問行為，不問意見
錯誤問法：「你覺得這個報表功能好不好用？」 正確問法：「你上次用這個報表功能完成了什麼任務？中間有沒有卡住的地方？」
問意見會觸發「社交期望效應」——受訪者傾向給出他們認為你想聽的答案，或者給出一個聽起來很合理但跟實際行為不符的回答。
行為問題的萬用句型：「上次你在做 [任務] 的時候，你是怎麼 [步驟] 的？」
這個句型強迫受訪者回到具體情境，而不是在抽象層面發表看法。你要的是他們做了什麼，不是他們覺得什麼。
挖掘「卡點」與「變通做法」
需求訪談中最有價值的資訊，往往藏在受訪者的變通做法裡。當有人說「我現在用 Excel 手動整理」或「我會先截圖再用 Line 傳給同事」，這些笨拙的替代方案就是未被滿足的需求。
追問句型：
- 「那個步驟你現在怎麼處理？」
- 「有沒有什麼你覺得很麻煩但一直沒人解決的？」
- 「如果這個工具明天消失了，你會怎麼完成這件事？」
我們曾協助一家 SaaS 公司做需求收集，訪談中發現用戶會用「截圖 + Line 傳訊息」來補足系統缺少的協作功能。這個變通做法揭露了一個核心需求：用戶需要在任務上直接留言和標註，而不是跳出系統去溝通。這個洞察後來成為產品路線圖上優先級最高的功能。
在我們團隊，PM 會用 monday.com 的看板來追蹤每場訪談中發現的「變通做法」——每個變通做法就是一張卡片，標記痛點強度和出現頻率，方便後續做需求優先排序。
用情緒線索判斷痛點強度
不是所有痛點都值得解決。你需要判斷哪些是「有點不方便」，哪些是「每次都很崩潰」。
注意受訪者的語氣變化、停頓、用詞強度。當他們說「還好啦」和「每次都要花半小時重做，真的很煩」，這兩個痛點的優先級完全不同。
追問情緒的句型：
- 「你說這個讓你很困擾，可以多說一點嗎？」
- 「這個問題大概多久會發生一次？」
- 「發生的時候，你的第一個反應是什麼？」
痛點強度直接決定功能的優先順序——這是需求分析階段最關鍵的輸入。如果你正在學習如何排定優先順序，艾森豪矩陣的「重要 vs 緊急」框架也適用於需求排序。
量化時間與金錢成本
讓需求從「感覺」變成「數字」，是讓需求在決策會議上有說服力的關鍵。
- 「這個問題每週大概花你多少時間？」
- 「因為這個流程，你們部門一個月大概要加班幾次？」
- 「如果這個問題解決了，你估計每天可以省下多少時間？」
數字化的需求在撰寫企劃書或 BRD（Business Requirements Document）時特別有用。「用戶覺得報表功能不好用」和「業務團隊每週花 6 小時手動整理報表數據」——後者在老闆面前的說服力完全不同。
以下是五種提問法的錯誤問法與正確問法對照：
| 提問法 | ❌ 錯誤問法 | ✅ 正確問法 |
|---|---|---|
| 錨定最近經驗 | 你通常怎麼處理這件事？ | 上一次你處理這件事，從哪一步開始？ |
| 問行為不問意見 | 你覺得這個功能好不好用？ | 你上次用這個功能完成了什麼？卡在哪裡？ |
| 挖掘變通做法 | 你需要什麼新功能？ | 這個步驟你現在怎麼處理？有沒有用什麼替代方法？ |
| 追問情緒線索 | 這個流程有問題嗎？ | 你說這讓你很困擾，可以多說一點嗎？ |
| 量化成本 | 這個問題嚴重嗎？ | 這個問題每週大概花你多少時間？ |
訪談進行中：傾聽與引導的實戰技巧
問題設計好了，但訪談現場的臨場反應同樣重要。很多 PM 準備了完美的大綱，卻在執行時犯了致命錯誤。
主持人的三個角色：引導者、記錄者、觀察者
理想情況下，訪談應該兩人搭檔：一人主持對話，一人專心記錄。主持人需要全神貫注在受訪者身上，如果同時低頭打字，會破壞對話的流暢度和信任感。
但現實中，很多 PM 是單兵作戰。單人訪談的應對策略：
- 錄音授權： 訪談開始前，用明確的話術取得同意：「為了確保我不會遺漏你說的重點，我想錄音做為我個人的筆記參考，錄音不會分享給其他人。你方便嗎？」這句話同時處理了錄音授權和資料保護的顧慮。
- 關鍵字速記法： 不要試圖記下完整句子。只記關鍵字和情緒標記（例如：「報表 → Excel 手動 → 6hr/週 → 😤」），訪談後再根據錄音補完。
- 觀察非語言訊號： 注意受訪者的猶豫、重複確認、話說一半又收回。這些訊號往往比語言內容更有價值。
在團隊協作的場景中，我們會用 monday.com 的會議記錄模板來統一訪談記錄格式，讓不同 PM 做的訪談記錄可以互相比對和彙整。
沉默是黃金：不要急著填空
訪談者最常犯的錯誤：受訪者停頓三秒，你就急著補充「是不是因為 XXX？」或提供選項「你覺得是 A 還是 B？」
這個動作看似在幫助對話，實際上是在替受訪者思考——而且往往把他們帶往你預設的方向。
沉默 3 到 5 秒的技術： 當受訪者停頓時，保持眼神接觸（或視訊中保持安靜），讓他們自己填補空白。人類天生不喜歡沉默，受訪者會在這幾秒內組織出更深層的想法——往往是他們原本不打算說的真實感受。
一位 UX 研究員曾分享：在一場產品訪談中，受訪者停頓了四秒後說出「其實我根本不用這個功能，我都叫同事幫我操作」。這個資訊比任何直接提問都更有價值，因為它揭露了一個完全不同的使用模式。
培養這種傾聽能力需要刻意練習。剛開始會覺得沉默很尷尬，但幾場訪談後你會發現，沉默是最強大的追問工具。
三大常見陷阱與即時應對
陷阱一：受訪者開始設計解法。
當受訪者說「我覺得應該做一個按鈕，點下去就自動生成報表」，他已經跳過了需求層，直接進入解法層。
應對話術：「這個想法很有意思。在有這個按鈕之前，你現在怎麼生成報表？」把對話拉回行為層，因為解法可以有很多種，但痛點只有一個。
陷阱二：訪談變成抱怨大會。
受訪者開始發散抱怨：「系統很爛」「老闆都不聽」「IT 部門都不配合」。這些情緒是真實的，但對需求收集沒有直接幫助。
應對話術：「我理解這讓你很frustrating。你提到系統很爛——最近一次讓你覺得特別不好用的是什麼時候？那次發生了什麼事？」用具體情境把抱怨轉化為可分析的行為資料。
陷阱三：受訪者給出「政治正確」答案。
特別是內部訪談，受訪者可能因為擔心被追究，給出安全但不真實的回答。
應對話術：「你說這個流程運作得還不錯。有沒有哪次你覺得它其實不太順？即使是很小的事也沒關係。」用反例測試，降低受訪者的心理防線。
| 陷阱 | 受訪者行為 | 應對話術 |
|---|---|---|
| 設計解法 | 「應該做一個按鈕…」 | 「在有這個按鈕之前，你現在怎麼做？」 |
| 抱怨大會 | 「系統很爛、老闆不聽…」 | 「最近一次讓你覺得不好用是什麼時候？」 |
| 政治正確 | 「流程還不錯啦」 | 「有沒有哪次你覺得它其實不太順？」 |
訪談後的需求分析：從原始資料到可執行洞察
訪談結束不代表需求收集完成。原始訪談資料就像一堆未經分類的拼圖碎片——你需要在 24 小時內整理，找出模式，才能轉化為可執行的需求。
訪談記錄的整理框架
為什麼要在 24 小時內整理？根據記憶衰退曲線（Ebbinghaus Forgetting Curve），訪談後一天內，你對非語言訊號、語氣變化、停頓位置的記憶會大幅衰退。那些「他說到這裡明顯猶豫了」的觀察，隔天就想不起來了。
整理的三層結構：
- 逐字稿或重點摘要： 如果有錄音，用轉錄工具產出逐字稿。沒有錄音的話，根據關鍵字速記還原重點。
- 洞察標記： 在摘要中標記三種資訊——行為事實（受訪者做了什麼）、痛點（哪裡卡住）、情緒強度（多困擾）。
- 假設驗證： 回到訪談前的假設清單，逐一標記「已驗證」「已推翻」「需要更多資料」。
工具方面，我們團隊用 Notion 建立訪談資料庫，每場訪談是一個頁面，用標籤分類痛點主題，方便後續交叉比對。如果你的團隊需要更完整的筆記軟體來管理訪談記錄，Notion 的免費版就足以應付大多數需求。
親和圖法（Affinity Mapping）：找出需求模式
當你完成了 5 場以上的訪談，手上會有大量零散的洞察。親和圖法是把這些碎片整理成有意義模式的最有效方法。
操作步驟：
- 拆解洞察： 把每個訪談中的獨立洞察寫在便利貼上（實體或數位皆可）。一張便利貼只寫一個洞察，例如「業務每週花 3 小時手動整理客戶報表」。
- 靜默分群： 團隊成員各自把便利貼移動到他們認為相關的群組，過程中不討論。這避免了聲音最大的人主導分類。
- 命名主題： 分群完成後，為每個群組命名。例如「報表自動化需求」「跨部門溝通斷點」「權限管理痛點」。
- 排序優先級： 根據每個主題下的便利貼數量和痛點強度，決定需求優先順序。
我們團隊實際操作時，會用 Miro 的白板功能 或 FigJam（Figma 的免費白板工具）來做遠端親和圖。一個 5 人訪談的專案，通常會產出 30 到 50 張便利貼，最終歸納出 3 到 5 個核心需求主題。如果你想了解更多視覺化整理方法，流程圖也是整理需求流程的好工具。
區分需求層次：表面需求 vs 真實需求 vs 潛在需求
訪談資料分析最關鍵的一步，是區分三個層次的需求。用 Jobs-to-be-Done（JTBD）框架來解讀：
| 需求層次 | 來源 | 範例 | 分析方法 |
|---|---|---|---|
| 表面需求 | 受訪者直接說的 | 「我需要一個更快的報表功能」 | 直接記錄，但不照單全收 |
| 真實需求 | 行為顯示的 | 每週花 6 小時手動整理數據 | 從行為問題和變通做法中推導 |
| 潛在需求 | 情境暗示的 | 希望在主管問之前就能提供數據 | 從情緒線索和工作情境中推測 |
表面需求是受訪者的「解法」，真實需求是他們的「問題」，潛在需求是他們的「動機」。好的需求分析要穿透到真實需求和潛在需求層，才能設計出真正解決問題的方案。
這個三層分析的結果，就是你寫入需求文件（BRD）的核心內容。如果你還不熟悉如何將訪談洞察轉化為正式的需求文件，可以參考我們的 BRD 撰寫指南。
識別「假需求」也是這個階段的重要工作。當受訪者說「我需要 XX 功能」，但你觀察到他們從來不使用類似的現有功能時，這很可能是假需求——受訪者在訪談情境中「想像」自己會用，但實際行為不支持這個假設。交叉比對多場訪談的行為數據，可以有效過濾掉假需求。
向上報告訪談發現
訪談分析完成後，你需要向主管或客戶報告發現。很多 PM 在這一步犯的錯誤是：把所有訪談細節都倒出來，讓聽眾淹沒在資訊裡。
有效的報告結構：
- 核心發現（3 到 5 個）： 每個發現用一句話描述，附上支持數據（「8 位受訪者中有 6 位提到報表整理耗時」）。
- 優先排序建議： 根據痛點強度和影響範圍，建議哪些需求應該先處理。
- 下一步行動： 明確說明接下來要做什麼（例如：「建議針對報表需求做原型測試」）。
用商業模式的思維來包裝需求——不只說「用戶需要什麼」，更要說「解決這個需求對業務的價值是什麼」。
不同情境的需求訪談策略
需求訪談的基本技巧是通用的，但不同情境需要調整策略。以下是三種最常見的訪談場景。
內部利害關係人訪談
適用場景：ERP 導入前的需求收集、內部工具改版、流程改善專案。
最大挑戰是「政治考量」。受訪者是你的同事，他們可能擔心說錯話被追究，或者不想得罪其他部門。
策略：
- 匿名彙整： 訪談前明確告知「我會把所有人的回饋匿名整理，報告中不會出現個人姓名」。
- 聚焦行為而非評價： 不問「你覺得 IT 部門配合度怎麼樣？」，改問「上次你提需求到系統上線，中間經歷了哪些步驟？」
- 避免在訪談中承諾解法： 受訪者可能會追問「那你們打算怎麼改？」，標準回答是「我們會綜合所有人的回饋再做決定，目前先專心了解現況」。
如果你正在推動數位轉型專案，內部訪談的品質直接決定轉型方向是否正確。
外部客戶訪談
適用場景：新產品 Discovery 階段、客戶旅程優化、服務設計。
最大挑戰是時間有限。客戶願意給你的時間通常只有 30 分鐘，而且容易給出「我要更多功能」的發散需求。
策略：
- 限時 30 分鐘結構化訪談： 嚴格控制時間分配——5 分鐘暖場、20 分鐘核心問題、5 分鐘收尾。
- 事先寄送情境說明： 訪談前一天寄一封簡短的 email，說明訪談主題和大概會問的方向，讓客戶有心理準備。
- 聚焦最近的具體經驗： 客戶時間有限，不要問開放式大問題，直接錨定「上一次你使用我們的產品時…」。
遠端訪談的注意事項
後疫情時代，大量的需求訪談透過視訊進行。遠端訪談有幾個特有的挑戰：
非語言訊號減少。 你看不到受訪者的肢體語言，只能從語氣、停頓、用詞來判斷情緒。這讓追問情緒線索變得更困難。
網路中斷應對。 事先準備備案：「如果視訊斷線，我會在兩分鐘內重新發送連結。如果持續無法連線，我們改用電話繼續。」
增加互動感。 遠端訪談容易變成單向問答。使用螢幕共享讓受訪者展示他們的實際操作流程，或用共享白板（如 Miro）讓受訪者直接在上面標記痛點，可以大幅提升互動品質。
開場前務必確認錄音同意——遠端訪談的錄音更敏感，因為受訪者可能擔心錄影被分享。明確說明錄音用途和保存方式。
需求訪談工具與範本資源
工具不會讓你的訪談變好，但好的工具可以減少行政負擔，讓你把精力放在真正重要的事——傾聽和分析。
記錄與轉錄工具
| 工具 | 費用 | 適用場景 | 繁中支援 |
|---|---|---|---|
| Notion | 免費版可用 | 訪談資料庫、洞察整理 | ✅ 完整支援 |
| Otter.ai | 免費版 300 分鐘/月，付費約 NT$300/月 | 英文訪談自動轉錄 | ❌ 僅英文 |
| Fireflies.ai | 免費版有限制，付費約 NT$500/月 | 多語言會議轉錄 | ⚠️ 部分支援 |
分析與協作工具
| 工具 | 費用 | 適用場景 | 繁中支援 |
|---|---|---|---|
| Miro | 免費版可用 | 親和圖、遠端白板協作 | ✅ 介面支援 |
| FigJam | 免費（Figma 帳號即可使用） | 親和圖、輕量白板協作 | ✅ 介面支援 |
| monday.com | 免費版 2 人，付費約 NT$288/人/月起 | 需求追蹤看板、訪談排程 | ✅ 完整支援 |
| ClickUp | 免費版可用 | 需求文件管理、任務追蹤 | ⚠️ 部分支援 |
你是哪種團隊？工具選擇指南
- 5 人以下、剛開始做需求訪談 → 先用 Notion 免費版建立訪談資料庫，搭配 Miro 或 FigJam 免費版做親和圖
- 5 到 15 人跨部門協作 → monday.com 是我們的首選——用看板追蹤每場訪談的狀態、洞察和後續行動，免費方案不需要信用卡
- 技術團隊跑 Scrum → ClickUp 的文件功能適合把訪談洞察直接連結到 Sprint Backlog
- 15 人以上的大型專案 → monday.com 企業方案，可以設定自動化規則，例如「訪談記錄完成後自動通知分析負責人」
（推薦試試 monday.com 的免費方案，我們團隊實際用它管理訪談排程和需求追蹤，從訪談安排到洞察整理都在同一個平台完成。）
如果你想進一步提升產品管理的專業能力，Coursera 的數位產品管理課程涵蓋了從需求收集到產品策略的完整框架，適合想系統性學習的 PM。
結論
需求訪談不是聊天，是一門需要刻意練習的技術。
回顧本文的核心重點：
- 準備決定品質： 訪談前建立假設清單、選對受訪者、設計結構化大綱，大部分的訪談品質在開口前就決定了
- 問行為，不問意見： 用「最近一次經驗」錨定具體行為，避免得到理想化的許願清單
- 挖掘變通做法： 受訪者的土法煉鋼就是未被滿足的需求，追問「你現在怎麼處理」比「你想要什麼」更有價值
- 沉默是最強的追問工具： 停頓 3 到 5 秒，讓受訪者自己填補空白，往往得到最真實的答案
- 24 小時內整理，用親和圖找模式： 區分表面需求、真實需求、潛在需求三個層次，才能寫出有說服力的需求文件
你的下一步行動： 挑選你最近的一個專案，用本文的訪談大綱範本準備一場 30 分鐘的需求訪談。先從兩個暖場問題和三個核心行為問題開始，不需要一次做到完美。
想把訪談流程系統化管理？在 monday.com 用看板建立你的訪談追蹤系統——從排程、記錄到洞察分析，10 分鐘就能建好第一個需求管理看板。
需求訪談常見問題 FAQ
需求訪談和使用者訪談有什麼不同？
需求訪談（Requirement Gathering Interview）的目標是收集專案或產品的功能需求與業務需求，受訪者通常包含決策者、使用者和受影響者。使用者訪談（User Interview）更聚焦在終端使用者的行為、動機和體驗。兩者的提問技巧相似，但需求訪談的範圍更廣，需要同時考慮業務目標和技術限制。英文中，需求訪談常稱為 Stakeholder Interview 或 Discovery Interview。
需求訪談大綱格式怎麼寫？
標準的訪談大綱分四個區塊：暖場問題（2 題，建立信任）、核心行為問題（4 到 6 題，了解現有流程與痛點）、深挖問題（彈性，根據回答即時追問）、收尾問題（1 到 2 題，確認遺漏）。重點是大綱只是引導方向，不是逐題照唸的問卷。每個核心問題都應該聚焦在「受訪者做了什麼」，而不是「受訪者覺得什麼」。
一次需求訪談要訪談幾個人才夠？
根據 Nielsen Norman Group 的研究，探索階段訪談 5 到 8 人通常可以達到資訊飽和點。但前提是受訪者的角色要有多樣性——如果 8 個人都是同部門同職位，飽和點不會到。判斷飽和的實務指標：當你在第 N 場訪談中，已經聽不到新的痛點或行為模式，就代表接近飽和了。
受訪者不願意說真話怎麼辦？
最常見的原因是受訪者擔心被追究或得罪人。三個應對策略：第一，訪談前明確承諾匿名彙整；第二，聚焦行為問題而非評價問題（問「你怎麼做」而不是「你覺得誰做得不好」）；第三，用反例測試（「有沒有哪次你覺得這個流程其實還好？」），降低心理防線。建立信任需要時間，暖場問題不要省略。
Requirement gathering 和需求訪談是同一件事嗎？
不完全相同。Requirement gathering（需求收集）是一個更大的概念，包含訪談、問卷調查、觀察法、工作坊、原型測試等多種方法。需求訪談是 requirement gathering 中最常用也最深入的方法之一，特別適合探索階段需要了解「為什麼」和「怎麼做」的情境。如果你需要大量量化數據，問卷可能更適合；如果你需要理解行為脈絡，訪談是首選。
