＊＊＊ 本文同步發表於 FB 社團－軟體設計鮮思維 ＊＊＊

一個發生在昨天輔導單位的一個小小的案例，應該也可以藉此讓許多開發人員反思下．．．。

某一技術高深的程式開發人員 (就簡稱 PG)對一已進行開發至一半時間的專案，突然 User 代表 (關係利益人，就簡稱 User)丟了一個針對要計算折扣代碼的邏輯的需求進來，而且看來好像挺複雜的樣子。

PG 心態上不是很愉快，都已進行至一半，現在才突然有這樣的需求，需要為此多花一至兩天的時間來撰寫它，而這會影響到既定的上線時間。

嗯，我的判斷是當然會多花一時間，但不至影響到預定的時間。心態上的不適 (為何這麼重要的需求到中後期才提出來)遠比實作的難度大很多！

我能作的是什麼？ (在這個極小型的專案我兼職擔任 PM)，幫開發人員多爭取一天的休息時間，讓他們心理好過些。

然後昨天這位 PG 花了很多時間在撰寫相關這邏輯的實作，甚至很認真的透過 SA 與 User 提相關的問題。

嘿！這時刻我給他制止了。。

我反問他，SA 已整理出來的計算折扣代碼公式你約略能理解並實作吧？ 是的，大約兩、三個小時就寫出來了。
那麼，你為何還要問 User 相關的問題呢？ 因為我不確定這邏輯是否正確，而且覺得怪怪的。

重點來了！你認為 User 會不會再變動這邏輯？
必然！！依該 User 的慣性，經常都在更動中。
那麼，你為何要現在花那麼多時間在與 SA/User 的討論？

現在難道不能告一段落，然後設計一個 method : 產出折扣碼() 來包容這個現在不確定且容易改變的邏輯不就好了？
難道沒有更重要的事情要進行嗎？

有的，更重要的是，我要他們把整個情境完全跑順暢，並且確實有 Deploy (部署)至遠端伺服器上。前者已近乎完成，但後者仍未實行，而這是我強調要求的主軸，在一開始的開發議定上已經有共識的。

這位 PG 資質相當好，柔軟度也夠，當下就知道我想表達的重點，也了解到自己也陷入盲點，不知不覺掉入了細節的紛爭中。
所以，哪個時候，那個計算折扣的邏輯要確實實作完整？ 嘿，上線前我當然會要求 User 要給出他 "認為" 正確的邏輯。

會不會還是不正確？ 這可能性很大，依照 User 不確定性的慣性來說。
但這可不能成為無法實作的藉口。再則，我會作的就是要求 User 背書，屆時邏輯若給的不正確，就會是 User 自身的責任，這可不能轉嫁給開發人員成為系統無法上線的藉口的。

不過關於責任釐清的問題，這裡面有很大的學問，不容易一言以蔽之。而這就是 PM 應具備的重要技能之一。