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