demoshop

demo, trying to be the best_

這是一個血淋淋的教訓 demo 前陣子幾乎沒發文的原因就是我最早的下班時間大概都是九點半以後...而且假日也幾乎都在拼命,不是案子大到誇張,也不是我能力太弱而是人的問題,人與人的溝通真的太可怕了,之前寫程式的時候都是自己聽需求自己想解法(我程式年資還不到兩年),一切自己來從來不覺得了解需求是一件重要的事情,直到這個案子才有了比較深刻的體會。

先來個故事場景,在這個故事中我是處於實作的角色,客戶(以下簡稱甲方)和我(以下簡稱丙方)之間還有一層所謂的大包(以下簡稱乙方),而且這個案子比較類似內部系統與我之前做的大眾化網頁需求比較不同,有很多特定的習慣不能去動搖他,也不要想和客戶說大家都這樣所以你也應該這樣,畢竟它還算是個封閉的系統,因為扯到很多部分所以規劃是由乙方來做,需求也是經由乙方告知來實作,這種中間夾了一層的溝通方式真的很容易出問題,有很多部分都是重做兩三次甲方才接受,這不是在於甲方太機車,是因為乙方在傳達或轉述需求的時候很容易加上自己的觀點與想法,比如說,甲方只是想要喝一杯水但經由乙方告知可能會變成「甲方要喝礦泉水,而且是真正的礦泉還要注意生菌數」,而我這可憐的丙方就很努力的找水源、找到後一層一層的過濾雜質再仔細的包裝好後送到甲方手上時,甲方卻說為什麼花了一星期才給我一杯礦泉水我只是要門口飲水機的水阿。

吃力不討好就算了,還必須要重新去門口到水給他,一來一往的時間讓一個小小的需求成長到好幾倍最後卻又縮回最基本的需求導致專案時程嚴重落後,類似的情況一次一次的來再加上時間越來越趕我心情就越來越差,越寫越悶,最後是自己上火線,逐一與甲方確認核心需求後才讓專案進度有趕回來的趨勢,最終才能順利驗收,這次的經驗實在寶貴。

整個事件讓我學習到的是人與人的溝通,以及對於改變了我對於案子的認知,不是寫好了就算了,魔鬼真的都在細節裡,換個角度與想法往往可以把客戶的無理取鬧轉換為需求說明,只要是合乎邏輯的其實沒什麼說不的權力,這條不歸路真的是需要無比的熱誠與興趣才能支撐的...

回應討論