需求訪談怎麼做：把老闆的點子講成工程師聽得懂的規格

老闆在會議上講了十分鐘,大意是「我們要做一個系統,讓客戶可以自己查訂單進度,順便把客服的工作量減下來」。工程師點點頭,回去寫了一份規格,兩週後拿出雛形,老闆一看眉頭就皺起來:「這不是我要的,查詢頁面太陽春了,而且客服的工作量根本沒減少」。工程師一臉委屈,因為雛形完全照著會議紀錄做的。

這種落差,幾乎不是任何一方的錯,而是中間少了一道工序:把一句話的點子,拆解成工程師真正能動工的規格。老闆講的是「目標」,工程師需要的是「行為」和「條件」,這兩者之間隔著一層,如果沒有人專門去做這層轉譯,做出來的東西必然跟想像有落差。這道轉譯工作的核心方法,就是需求訪談。

老闆講的是目標,工程師要的是場景,中間要有人翻譯

「讓客服工作量減下來」是一個目標,但工程師沒辦法直接把「目標」寫成程式。工程師需要知道的是具體場景:客戶通常在什麼時間點會想查訂單進度?是下單後多久開始焦慮?查詢的入口要放在網站、LINE,還是簡訊連結?查不到答案時,系統要顯示什麼、還是要導去真人客服?這些問題如果不先問清楚,工程師只能憑自己的猜測填空,而猜測填出來的規格,十次有八次跟老闆腦中的畫面對不上。

比較有效的做法,是找一個角色專門負責把「老闆的目標」轉成「使用者的場景」,再把場景轉成「系統該有的行為」。這個角色可以是內部的產品經理,也可以是外部顧問,但重點是這件事不能省略,不能指望工程師自己腦補,也不能指望老闆自己寫規格書。

一次訪談問不完,分階段問比較準

很多企業想在一次會議裡把需求問清楚,結果會議開了兩小時,問題卻越問越發散,最後大家帶著不同的理解散會。比較務實的做法,是把需求訪談拆成幾個階段,每個階段問不同層次的問題,而不是試圖一次到位。

第一階段先確認目標和限制,例如這個系統要解決的核心問題是什麼、預算和時間的上限在哪裡、有沒有一定要相容的舊系統。第二階段深入使用情境,找實際會用這個系統的人聊,而不是只問老闆或主管,因為第一線人員知道的細節,往往是老闆根本不知道存在的。第三階段把訪談結果整理成具體的使用案例,拿回去給老闆和第一線人員確認,「我們理解的是不是這樣」,確認過的內容才交給工程師。

下面這張表格,是我們在需求訪談時常用來分辨「問對問題」跟「問錯問題」的對照:

需求訪談的產出,要是工程師看得懂的東西,不是會議紀錄

很多企業把「需求訪談的產出」跟「會議紀錄」畫上等號,訪談完整理一份逐字稿或重點摘要,就直接丟給工程師。問題是會議紀錄記的是「大家說了什麼」,工程師需要的是「系統要做什麼」,這兩者的顆粒度差很多。

比較有用的產出形式,是把訪談內容整理成使用案例或使用者故事,格式類似「當使用者在某個情境下,做了某個動作,系統應該有某種反應」。這種寫法逼著訪談者把模糊的期待變成具體的條件,也讓工程師可以直接評估工作量和技術可行性。如果訪談產出還停留在「客戶希望查詢更方便」這種句子,代表訪談還沒問到位,需要再往下挖一層,問到「更方便」具體指的是什麼動作變少、等待時間縮短多少,或是哪個步驟被拿掉。

訪談前先想清楚誰該在場,比訪談技巧更重要

很多需求訪談失敗,不是問題問得不好,而是找錯人在場。只找老闆和主管開會,容易得到「理想化」的答案,因為他們不是每天實際操作的人。只找第一線人員,又可能拿到「習慣了現狀」的答案,說不出更好的做法可能長什麼樣子。比較平衡的組合,是讓決策者講清楚目標和限制,讓第一線人員講清楚實際操作的細節和痛點,兩邊的資訊放在一起看,才會浮現出系統真正該長的樣子。

把這件事做對,後面的開發過程會順很多。規格清楚,工程師不用邊做邊猜;猜測減少,返工跟改版的成本自然降低。反過來說,如果需求訪談這一步被省略或做得太粗糙,不管後面找的是內部團隊還是外部顧問,雛形跟期待對不上的機率都很高,而這中間浪費掉的時間,往往比訪談本身多花的那幾天要多得多。