做系統之前，先看見自己的混亂

大多數業主在找人做專案之前，心裡都已經有一個畫面了。可能是看到同業做了一套管理系統覺得不錯，或是在某個平台上體驗到某個功能覺得「我也要這個」。帶著這個畫面，你坐下來跟開發方聊第一次需求。

然後你會發現，這場對話跟你想像的完全不一樣。

你以為在討論功能，其實在盤點現狀

業主通常想聊的是「我要什麼功能」，但一個有經驗的團隊會先問你另一件事：你現在的狀況是什麼？

• 你的客戶資料現在存在哪裡？Excel？紙本？還是業務的手機裡？
• 你的訂單流程是什麼？誰接單、誰確認、誰出貨？
• 你的內部溝通用什麼？Line 群組？Email？口頭交代？
• 你現在的網站誰在維護？有後台嗎？還是每次都找人改？

這些問題聽起來跟「做一套新系統」沒什麼關係，但它們決定了這個專案真正的複雜度。很多時候，業主想要的功能技術上不難，難的是你的資料和流程還沒有準備好去承接它。

那些「理所當然」的事情

需求訪談裡最有價值的部分，往往是挖出那些業主覺得「不用特別說」的事情。

比如你說「我要一個會員系統」，但你沒提到你的 VIP 客戶有特殊折扣規則、不同門市的會員等級計算方式不一樣。再往下問，你會發現這些規則其實沒有被寫成任何文件，都是「資深同事才知道」的潛規則。更常見的是，流程本身就很混亂——同一件事在不同部門有不同做法，或者某個步驟「照理說」要簽核，但實際上大家都跳過了。

還有一種更難處理的狀況：歷史包袱。公司經營久了，總會累積一堆特例。某個大客戶有專屬的報價方式、某條產品線的出貨規則跟其他的不一樣、某個部門因為三年前的某次事件所以流程特別繁瑣。這些特例當初都有它的原因，但疊加起來就變成一團只有內部人才能理解的潛規則。要把它們系統化，光是梳理就是一件大工程。

這些你每天在處理所以覺得理所當然，但對開發來說，每一個「理所當然」都是一個要額外處理的邏輯。一場好的需求訪談，就是把這些藏在日常裡的東西一個一個翻出來。不是要為難你，而是現在不挖出來，做到一半才發現的代價會更大。

為什麼一次聊不完？

很多業主會覺得「不就是一套系統嗎，一次會議應該就能講清楚了吧？」實際上很少能一次到位。

第一次聊完，你回去會開始注意到以前沒注意的事。你可能會發現某個流程其實沒有你以為的那麼標準化，或是某份資料的格式比你記憶中的更混亂。這些新的發現會帶出新的問題，而這些問題需要再一次對話來釐清。

這不是效率差，反而是好的徵兆——代表你開始用更系統性的眼光重新看自己的企業。很多業主說，光是需求訪談這個過程，就讓他們重新理解了自己的公司。

協作不是交辦

傳統的做法是「你告訴我要什麼，我做給你」。但真正有效的協作是一起思考——你帶著對業務的理解，對方帶著對技術的判斷，在對話中慢慢找到一個兩邊都說得通的方案。

這意味著你不能只是「發包」然後等結果。你需要參與，但不是參與技術決策，而是參與問題的定義。因為只有你知道哪些問題是真正重要的，哪些其實可以先不管。

好的合作關係不是一方聽命於另一方，而是雙方都願意在過程中調整自己的認知。業主調整對技術的期待，開發方調整對業務的理解。這種互相校準的過程，才是需求訪談真正在做的事。