有個案子的需求聽起來很單純：讓經銷商能在既有介面上查產品庫存。
一句話講得完，聽起來一週就能做完。
我們的回應不是報價，是先問對方要一份東西： 請提供你們日常在用的那份庫存 Excel 或 CSV 範本。
為什麼是表格，不是規格書
因為客戶描述需求的時候，講的是「我想要什麼功能」； 而那張表洩漏的是「我們實際上怎麼工作」。
這兩件事的落差常常大到會改變報價。
一份真實的庫存表裡，你會看到： 欄位到底叫什麼、有幾個欄位其實沒人在填、 數量是整數還是會出現「約 200」這種字串、 到貨日是日期格式還是「下週三」、 同一個產品型號在不同列有沒有寫法不一致。
這些東西不會出現在任何一份需求文件裡， 但它們決定了你要不要寫資料清洗、要不要做例外處理、 以及這個案子到底是一週還是三週。
備註欄是金礦
如果只能看一個欄位，我會看備註。
備註欄裡塞的東西，通常是這家公司的規則裡 「還沒有被系統化」的那一部分： 哪個客戶有特殊價、哪批貨要留給誰、什麼情況要先打電話確認。
這些是真正的業務邏輯，只是它們住在一個純文字欄位裡， 靠人腦在維護。
你要做的系統如果沒有處理它們，上線之後那些規則不會消失， 只會變成使用者繼續開著 Excel 手動處理， 然後你的系統就變成他每天多做的一件事，而不是少做的一件事。
拿到表之後，把不確定寫進報價
看完表，你會得到一份「還不確定的事」的清單。 這份清單不要自己吞掉，要寫進報價單。
寫法很簡單：本報價假設庫存資料以每日一次的檔案上傳更新、 欄位結構與範本一致；若需即時同步或欄位變動，另行評估。
這不是免責條款，是把風險標在雙方都看得到的地方。 真的變動了，你有依據重新討論；沒變動，這幾行字也不會傷害任何人。
我看過太多案子，交付到一半才發現欄位跟當初看的不一樣， 然後爭論那到底算不算變更需求。 爭論的原因通常不是有人耍賴，是當初根本沒有人把基準寫下來。
要那張表會遇到的阻力
不是每次都拿得到。
常見的狀況是對方覺得那份檔案很亂、不好意思給， 或者那張表在另一個部門手上，要一份範本得跨部門去要。
我通常會把話講清楚：不需要真實資料， 把客戶名稱和數字換掉都可以，我要看的是欄位結構。
阻力本身也是資訊。 如果一份日常在用的表要跨三個部門才要得到， 那這個專案上線之後的資料維護，多半也會卡在同一個地方。
順序不能反
拿到表再報價，不是報完價才要表。
先報價的風險是：你報的是那句「讓經銷商查庫存」， 而你交付的是那張表的真實樣子。 中間的差額，通常由你自己吸收。
需求訪談我現在習慣少問一句「你想要什麼」， 多問一句「你現在怎麼做」。
後面那個問題的答案，才是要開發的東西。