關於軟體需求變動的一個小案例思考

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

文章導覽

   

發表迴響

你的電子郵件位址並不會被公開。 必要欄位標記為 *