「要有會員、通知、報表和管理後台」聽起來已經列出不少需求，開發團隊卻還是很難估。通知什麼時候寄、寄給誰？報表的數字從哪裡來？不同部門能看同一份資料嗎？這些沒有說清楚，功能名稱列得再完整，也可能做出與實際工作不合的系統。
先找一件最近真的處理過的事
假設公司想把申請作業搬到線上，可以拿一件剛辦完的申請來看：申請人怎麼送資料、承辦人去哪裡查、資料不齊時如何通知，最後又由誰確認結果。把目前用的表單、試算表和訊息攤開，通常比從首頁要放什麼按鈕談起更有幫助。
也可以問處理的人：哪一步最常要回頭找資料？哪個地方一忙就容易漏？答案不一定是「再加一個欄位」。有時真正需要的是讓承辦人看得出案件目前在哪個階段，或讓下一位處理的人知道輪到自己了。
不是每件事都會照正常流程走
申請資料可能填錯、文件可能要補，主管不在時也可能需要代理人。這些不是上線後才偶爾發生的小問題；它們會影響誰能修改資料、案件要退回到哪一步，以及系統要通知誰。
不用把所有罕見情況一次寫完。先找最近幾次需要人工另外處理的紀錄，看看目前是誰決定、怎麼留下原因。開發時至少知道哪些情況要由系統處理，哪些仍需要人員判斷。
第一版，先讓一件工作做得完
第一版不必把每個部門、每張報表都放進來。可以先選一個部門的日常作業，讓員工能從頭到尾完成。若做到一半還得回舊系統補資料，也要確認這是原本就安排好的做法，還是規劃時漏掉了。
排功能順序時，先問少了這項能不能完成工作，再看現在有沒有替代做法。這比讓每個部門各挑三個最想要的功能，更容易決定第一版的範圍。
找開發團隊前，要準備到什麼程度？
帶一件實際處理過的事、目前用的表單或畫面，以及最想改善的地方，就能開始討論。涉及個資或客戶資料時，可以先遮掉敏感內容。哪些功能該做、畫面怎麼安排，留到工作方式談清楚後再決定。
如果已經有想法，也可以帶上預算和希望上線的時間。開發團隊才好說明哪些內容能先完成，哪些需要再釐清；不需要先替每個畫面畫好設計稿。