『命苦』也可能是自找的...

Rick是專案團隊中脾氣非常好的一位工程師,和大多數的工程師一樣,Rick對於寫程式是相當有熱誠的,在開發領域算是有一定的年資,程式碼的品質堪稱一流,在專案中也時常擔任與客戶端進行技術問題或系統功能溝通的重要角色。

最近一陣子,我們發現Rick常常被突呼其來的電話打斷,隨著電話交談的時間長度,表情上的無奈越顯得明顯而清晰。同時,我們也發現Rick的程式碼開發品質與速度和過去相比明顯的降低了不少。

關心之下(非正式場合的閒聊),發現Rick其實並沒有任何個人的問題,他只是專注地完成交付公司給他的任務,也就是專案開發的客製化功能設計,但由於客戶端的PM和User,在長期和Rick建立了良好的溝通默契與個人關係之後,開始跳過PM將一些小問題(真的是無傷大雅的小問題)直接請Rick進行系統的極細部調整。

也確實,這並沒有花非常多的時間,每一個調整動作都與系統整體的方向不衝突也不相違背,也就是說,這些問題即便依照正常程序經過PM來處理,這些修改依舊不會被PM擋掉,最終還是會發生,Rick也還是會著手修改。而User與Rick都希望能夠快速地解決這些小問題,省去一些行政上的繁文縟節,因此常常跳過雙方PM,進行了規格上的零星修正、UI的小調整或是Bugs的Fix。

發現這件事情之後,我請PM認真地把Rick找來,Rick很委屈的跟我說,他一開始認為這樣能夠提高效率,並且提升對客戶的服務品質,也確實如此,Rick總是擁有客戶端相當好的評價,甚至某些PM無法溝通的技術問題,由Rick出面協助溝通協調,客戶端總是比較能夠理解(或信任)。時間一長,這樣的溝通模式形成慣例,客戶也在專案中偶而私下請託Rick進行一些工作,但久而久之,Rick的時間開始被無法拒絕的瑣事所佔據,雖然後來推掉了不少,但開了先例,也不好意思每一個問題都直接拒絕,就演變出今天的結果。

這樣的情況,在專案工作中其實常常發生,不只發生在開發人員,偶而甚至發生在PM身上,儘管制度上我們都設計成必須要記錄每一個修正或程式修改動作,但實務上總是有一定比例的工作在檯面下持續進行著,不僅是甲乙方分明的專案,在企業內的MIS/IT也常常發生這樣的情況,越過主管的工作指派總是持續在發生著。

程式設計師也很容易依照個人關係,來決定事情的優先順序,PM也容易依照與客戶的交情,來決定規格修改的退讓或調整幅度,長時間下來,讓客戶覺得系統微幅調整的成本其實並非那麼高,甚至專案公司無法堅守最初的專案規格,微幅調整逐漸累積成了架構上的大範圍異動,最終導致專案的時程延誤,成本暴增。

這往往源於一開始的善意,客戶的殺手鐧常常是這樣的一句話:『我知道原本規格是這樣寫的,但這樣的設計,我們實際上根本沒辦法用啊!!!』或是:『我在上個milestone驗收的時候都很幫忙,你這邊稍微調整一下,應該不過分吧』(其實這句話聽起來有威脅的意味),更多的情形是,雙方在簽約與SA、SD階段,根本沒打算認真把規格搞清楚,很多模糊的空間是刻意保留出來的,為了讓簽約和成交趕快確定

兩邊PM都在打自己的如意算盤,白紙黑字將來各自表述,規格文字的撰寫模糊到不能再模糊,廠商PM這別心裡想的是,反正將來我生出來的功能只要能符合規格書就好,買方PM這邊想的是反正將來我要你符合我寫出來的規格再簽驗收就行。可是,落在紙上同樣的一段話,只有功能的抽象描述卻沒有具體清晰的量化數字或驗收條件說明(Acceptance criteria),最終只落得專案在雙方都不滿意的狀況下收場。

規格書上的模糊空間,專案團隊成員與客戶端的私人交情,這看起來八竿子打不著的兩件事情,導致了專案最後的失敗(或瑕疵)收尾,行之有年之後,也造成了客戶總覺得:『廠商應該早已把修改或異動成本算在專案裡了,報價都是高報的啦...』

這也難怪,台灣的軟體專案總是那麼辛苦,客戶的需求總是那麼難釐清,專案的驗收總是那麼的困難,工程師的異動總是那麼頻繁...

我想跟Rick,也跟其餘Developer說,其實你應該更認真的看待你手上所撰寫的每一行程式碼,記得,你能夠寫出這一行程式,是累積了少說三五年開發經驗之後的結果,每『一行』程式碼都是你的價值所在,每一段程式碼的修改都是你的產值,請不要也毋須輕易的做人情送給客戶。
Starbucks的barista培訓只需要幾個月,他動手花短短75秒做出一杯拿鐵咖啡大概值85元(最近幾年又漲價了),而你累積了三五年功力,花了一個下午,喝了三杯Starbucks咖啡才修改完成的功能卻是免費???

Developers, 拜託, 你的一行程式碼的價值(價格),其實遠遠超過你的想像。


請記得小丑的格言:



----------------------------------
後記:

在台灣,有太多的程式設計師、專案團隊以超級賤價的報價去硬生生地接了專案餬口,最終只是導致專案品質下降,同時也讓客戶覺得不就是寫寫程式或做個App嘛,要花那麼多錢嗎? 畫一幅畫是個專業,寫程式也是專業;畫一幅畫是一門藝術,寫程式也是一門藝術。藝術常常可以無價,但不能免費。

留言

Alex Lee表示…
想起BillChung説的:
"你知道我要花多久時間.才能讓這件事變簡單"
Unknown寫道…
心臟又被射了一箭。
JT_taipei表示…
軟體業者 低價搶單 早就是常態了.... 當然一些軟硬體廠商業務常固定聚會 互通有無 聯合綁標或對付客戶也是常事

單子搶不到 其他就不用多說了 畢竟日子總是要過

台灣電子業 低價搶單當然大家都知道 老闆拿著BOM 成本表 去跟阿兜阿談生意,半路常常殺出個"老郭"來... 老郭的模式 是犧牲系統組裝利潤 然後從 "零組件"賺回來.... 其他系統組裝代工廠商 或 零組件廠商 一些沒法這樣玩的 日子就難過.....

台灣軟體廠商 低價搶單 能從哪賺回來 ? 如果沒辦法 那是不是該退出一片紅海的區域 另尋一片天空 ?
匿名表示…
台灣人還是用製造業心態再搞軟體啊
陳傳興寫道…
這讓我想到一位MVP的Plurk留言:http://www.plurk.com/p/fb5ho7

我們要提升自我的「格」,從Programmer提升為Developer。

如題目一樣,也可以改成「現在的地位是自找的…」
Jacky寫道…
如同"台上10分鐘,台下10年功",國內更需提升"開發者"價值感.
Ted寫道…
可以讓我PO到FB嗎??
David寫道…
@Ted,

sure, 也可以使用底下FB轉貼
http://www.facebook.com/#!/pages/David%E7%9A%84NET-Walker%E5%B0%88%E9%A0%81/115848851788030
匿名表示…
身為同業,不得不稱讚您說得好。

同時也在努力思考:如何像 Starbucks 那般,平衡 barista 與咖啡品牌的價值。私以為,Starbucks 減低咖啡店吧台手的個人色彩,但同時能維持一定程度的形象,使得咖啡單價能一直不必降下來,也必定是經過一番錯語嘗試。

不過軟體工程畢竟不同於賣買咖啡,客戶是先買單了才發現(或是根本沒發現)自已缺乏覺悟,而不是先決定好了再心甘情願付錢。 :)
Jackal寫道…
請問我想轉寄給我同事看可以嗎?
我將會附上出處
Yafat寫道…
「台灣的軟體業也想走這樣的路,步上一樣的後塵嗎?」
啊?這算是未來式嗎?應該是現在進行式吧~~低價搶得到的還能糊口,搶不到的就收起來,賣雞排去了~~供(包含阿三、大陸和東歐的廉價PG)過於求(肯拿錢出來找人客製軟體的老闆都已經算菩薩了,真想在凱道上立個牌坊給他們)的結果就是這樣,不是嗎?
再者,在台灣,寫.NET和Java的還算好,像我寫PHP的,寫得再好客戶(含政府標案)也不會採納,還有一堆不會寫PHP只會道聽途說批評放箭的專家在恐嚇客戶。最後只能用接近免費的價格跪求業主給我們一次機會....注意喔...是給你機會,如果叫你改東西你想有意見,滾吧!
David寫道…
@Jackal,
Sure, No problem.
David寫道…
@Yafat,
是的, 所以關鍵在,如何讓客戶很開心地付錢,覺得自己花錢買到的產品與專案物超所值,並且不要落入功能/價格的紅海當中。或許,從軟體業以銷售軟體維生的角度看,這件事情比其他任何的技術問題都來的重要也值得花心思研究...
netquas寫道…
我好想按讚!震聾發聵!
PaulShell表示…
PM, Please, Developer 的一行程式碼的價值(價格, 還有汗水和淚水...)其實遠遠超過你的想像。
David寫道…
Hi netquas,
沒問題, 有按讚的需求,可造訪 http://www.facebook.com/pages/David%E7%9A%84NET-Walker%E5%B0%88%E9%A0%81/115848851788030

:)
Pajace寫道…
真的事講得太好太棒了~~(起立鼓掌...啪啪啪啪)
Bravo!Bravo(聲嘶力竭大喊中....)

這個網誌中的熱門文章

使用 Airtable 在小型需求上取代傳統資料庫

精彩(且驚人)的Semantic Kernel入門範例

使用Semantic Kernel 建立自然語言請假系統

在 LINE Bot 開發中使用Semantic Kernel建立自然語言請假系統

專業的價值...