需求訪談的藝術:把「我想要一個系統」變成規格

做系統開發十幾年,我們最常聽到的開場白是:「我想要一個系統。」再往下問一句「這個系統要解決什麼問題」,大概一半的業主會愣住。這不是業主的錯——你每天泡在自己的營運裡,痛點是用「感覺」存在的,不是用「規格」存在的。需求訪談的工作,就是把這些感覺翻譯成工程師能動工的東西。翻譯得好,專案順;翻譯得爛,做完才發現做錯,雙方都痛苦。

客戶說要 A,其實需要 B

舉一個我們反覆遇到的模式。業主說:「我要一個報表功能,每天自動寄 Excel 給我。」如果照做,兩週後你會得到一個沒人打開的每日郵件。多問幾句才發現,他真正的痛是「月底才知道哪家分店庫存亂掉,來不及處理」。那他需要的其實不是報表,是一個異常警示——庫存數字不對勁的當天就跳出來提醒,而不是每天寄一份要自己肉眼掃的表格。

這就是訪談的核心技巧:客戶描述的通常是「解法」,你要往回挖出「問題」。解法是業主用自己有限的技術想像拼出來的,問題才是真實存在的。挖問題最好用的一句話是:「如果這個功能今天就有了,你明天的工作會哪裡不一樣?」答不出具體差異的功能,十之八九是想像出來的需求。

訪談時我們一定會問的幾類問題

我們自己營運進銷存 SaaS,支撐實體加盟門市的每日營運,所以很清楚「現場怎麼做事」跟「老闆以為現場怎麼做事」常常是兩回事。訪談不能只訪老闆,還要訪實際操作的人。以下幾類問題是我們的固定菜單:

• 現況流程:這件事現在怎麼做?用什麼工具?一天做幾次?誰做?——不是問「你想要什麼」,是問「你現在怎麼活的」。
• 例外情境:什麼時候會出錯?出錯了怎麼補救?——例外處理往往佔開發工作量的一半,卻最常被漏掉。
• 量級:一天幾筆單?幾個人同時用?資料要留幾年?——量級決定架構,十筆和十萬筆是兩種系統。
• 驗收想像:上線三個月後,怎麼判斷這筆錢花得值得?——逼雙方在動工前對齊「成功長什麼樣子」。

需求訪談的目的不是記下客戶說的每一句話,而是找出客戶沒說出口、但少了它系統就沒人用的那件事。

把訪談變成規格的三個動作

訪談完不能只留一份會議記錄。我們的做法是三個動作:第一,畫流程圖——把「訂單從進來到出貨」這種主流程畫出來,拿回去給業主看,錯的地方他一眼就能指出來,比看文字快十倍。第二,列欄位——每個畫面要顯示什麼、輸入什麼,一個一個列。這一步最枯燥,但「商品要不要有效期欄位」這種小事,現在花五分鐘確認,比上線後改資料庫便宜太多。第三,標優先級——把功能分成「沒有就不能上線」跟「之後再說」,這直接影響報價與時程,也是後續砍出第一版範圍的基礎。

還有一個誠實的建議:訪談階段就要敢說「這個不建議做」。我們勸退過不少功能——不是做不出來,是做了沒人用,或有更便宜的解法(例如一張設計好的 Excel 範本就能解決的事,不必寫程式)。願意在訪談階段跟你辯論需求的團隊,通常比只會點頭的團隊可靠。

業主可以怎麼準備

如果你正打算找團隊談系統,訪談前做三件事會讓過程有效率得多:把現在的做事流程用手機拍下來或截圖(Excel 表、LINE 對話、紙本單據都好);找出最常出錯、最花時間的兩三個環節;想清楚預算的量級。不用寫規格書——那是我們的工作——但把「現況」帶齊,一次訪談能抵三次。

需求訪談做得紮實,後面的規格書、報價、時程才有根。如果你手上正有一個「想要一個系統」的念頭,還不確定該從哪裡開始梳理,歡迎跟我們聊聊,第一次對話不收費,我們會先幫你把問題問對。