專案執行的過程中，最歡樂的是訪談，最有趣的階段是開發，測試就是一步一腳印的耕耘，上線彷彿踩地雷，最有可能翻臉的，必屬整合測試階段了。
想當年的海誓山盟，如今都變成狗屁一堆，初期確認時很容易說服，最後徒留一句癡心錯付。
其實一開始，我很害怕這種狀況發生。
總覺得好像是自己的錯，導致需求方沒有理解狀況，或是沒有思考周全，導致系統無法包含客戶的需求，吾師瀟灑小姐說，系統只能支援百分之八十重複性的作業，一個系統不可能沒有人工處理的部分，所以不要想把系統做到「完美」。
做的專案越多，我越能理解，也越來越能釋懷，甚至把前老闆R的雞湯口頭禪掛在嘴邊，「不要拿特例發生的事，去影響通例的系統邏輯」去說服我的user。
為了避免成為user口中的渣男，也為了能替工程師們減少尋找到處散落的邏輯，針對現在團隊的工作模式，我跟的每個專案，都會出一份簡報，會從本次目標、範圍、架構開始，再慢慢推進細節。
人類的專注力有限，適合畫圖描述的邏輯，我會在簡報中附上圖片或表格，有必要時也會提供故事情節的案例，幫助專案成員理解「我要表達什麼」，盡可能降低精心養大的專案淪為狗屁的機率。
當然要講講故事了，先前做過的一個需求，user希望他們設定的優惠要限定單一門市使用，我建議他向第一線使用的單位確認一下，如果針對單一門市這件事常常發生，那當然沒關係，但如果沒有，建議還是未來當作特例另行處理。
因為他想要設定的層級太多種，皆是複選
1.全部門市
2台北市
3.大同區
3.中山區
4.中山門市
勾選3.鄉鎮市區，就該鄉鎮市區的門市皆可使用
勾選2.縣市別，就該縣市別底下所有門市都能使用
若勾4.單一個門市，則只有該門市可用
且需要可以複合選取，例如台北市以縣市別勾選，但新北市只針對中和區。
為了避免系統造成無意義的效能耗費，我們只好針對有被勾選的門市進行儲存，判斷是否可使用優惠時，直接以「門市」作為判斷單位，我提醒過，若有優惠先設定，後開新門市，有可能客戶取得優惠後，將無法使用優惠，建議還是再三思。
user最後還是希望這個專案「完美」，應該要能依照各種狀況彈性應變，在需求方不讓步的狀況下，最後的結果，我還是變成渣男了。
後來門市反應，優惠不能在新門市使用很是困擾，我再次跟user建議，增加一個開關欄位，需要針對單一門市的優惠再額外設定就好，其他一律預設不限制，因為我查詢了上線後時間使用的優惠，100%皆不針對門市設定限制。
user告訴我，他規劃文件裡的「全部門市」選項，就是這個作用，我方才恍然大悟，原來你的全部不是我的全部。
這次的經驗很珍貴，也讓我自省，下次再遇到類似的需求，我可以怎麼做。
可惜的是，後來它還是無法依他所願，當個「完美的系統」，還是有其他單位的優惠設定需求，超過了原始設定的涵蓋範圍，最後在我建議下，走了「特例」。
