最近因為執行1個急案，是有關一所幼兒園的報名系統，一開始以為是非常簡單的系統，所以沒有寫user story就請同仁開始作了，結果就產生了一些災難，包括使用者在開發過程中，需求產生變化、開發時程超過預期、系統上線時也發生了一些沒考慮的錯誤等等，包含身份証的檢查不夠全面，資料交易時沒有鎖位資料庫，造成重覆報名等等。

這個案子事後檢討後，有幾個結論可以作為日後專案開發的經驗

1.使用者需求訪談應該落實(user story)，然後產出概略的圖表或wireframe，續跟使用者更進一步的討論，整個需求的確認是要前述的2~3個循環，之後的產出包含功能、流程、資料欄位等，接續coding才能更順利，而花費的時間暫時可以先匡列為全專案的50%。

2.由於需求的討論要密集討論，所以專案成立後需和客戶強調，要求空出訪談次數與時間，訪問的內容可以有既定的scripts，user story不一定由使用者來寫，主要是紀錄使用者情境與遇到的問題等等。

3.對於急案，要不要作使用者需求訪談，可以視時間而定。由於確定接急案時，接案的PM應該對案件有一定熟悉度，為節省開發時間，可以由PM直接完成訪談後的產出，包含功能、資料庫等產出、然後安排工作給相關同仁開始作業。