最後幾天來回顧一下在過去開發資料產品時常見的坑與應對方式，不管是專案還是產品，首先當然要面對的難題就是需求訪談。
資料產品在需求訪談階段通常比一般 App 或網站更難談需求，原因在於大多數的資料產品沒有畫面。
(https://www.sogi.com.tw/articles/%E5%9C%8B%E9%98%B2%E5%B8%83%E6%94%9D%E5%BD%B1%E6%A9%9FApp_%E9%8C%84%E4%B8%8B%E6%A8%A1%E7%B3%8A%E7%9C%9F%E7%9B%B8/6216957)
通常在談網站或 App 的需求的時候，可以透過實際或 Mock 的畫面跟使用者溝通，也有很多的工具可以在進入開發階段之前做好整個應用的流程。只要功能符合使用者需求，就可以根據目前的畫面開發（需求變更是另外一個議題）。
不像寫程式，說一通常就是一，不管是哪一層資料產品，在第一個迭代完成前，也就是在還沒有收到使用者資料前，都無法完全預期結果。
蒐集資料的過程其實就是像市場調查或民意調查，在前期只能透過設計盡量讓調查的結果「貼近事實」，並不能「保證」調查結果跟預期一樣，市場真正的結果一定是在實際執行調查後才能呈現出來。好的資料蒐集以及處理方式其實更像是「程序正義」，只能保證資料本身有效但不能夠保證資料盡如人意。
不像寫應用，按鈕能不能按，商業邏輯對不對試一下就知道。一直到第四層的資料產品（輔助決策），就算上線後，也很難知道到底有沒有幫助。就像之前在顧問公司做的行銷顧問報告，我們會根據過去的銷售狀況以及市場因素給予客戶一些改善建議。拿「運用多元的口味吸引年輕消費者」，這樣的策略來說好了，實務執行上時有更複雜的因素需要考量，像是研發新產品的成本、行銷新產品的成本、甚至需要考量到機會成本，同樣的投入會不會換個代言人更有效?
成熟的資料產品（像是推薦系統）上線後通常需要 A/B 或 A/A 測試來驗證效果，但也很多場合是很難做到這些比較測試，這也造成了在需求上會很難釐清需求。
「投資有賺有賠，過去績效不代表未來績效，投資前請詳閱公開說明書」，我們永遠只能根據過去的資料來進行判斷，雖然在一些領域在「目前」有很好的效果，但隨著環境變化，需要持續的收資料、持續的訓練、持續的調整才有辦法，雖然不求有個「一勞永逸」的解決方案，但是資料產品註定了需要一直持續投入。
這點前面也講了很多次，資料產品需要一層一層疊上來，需求單位或需求者沒有辦法知道其他資料產品的內容時，往往會需要一邊釐清需求、一邊釐清資料來源，就會造成這個在需求訪談過程需要與不同單位或資料擁有者來來回回的對話與釐清，讓這個過程變得更加麻煩。
不用煩惱，上面五個坑一個坑都跑不掉。把這些坑列出來只是給各位讀者一個心理建設，實務執行時也很難避開這些問題。
iThome鐵人賽
看影片追技術