最近看一本書,書名就是這篇文章的標題『飛機上的27A』,剛好工作上發生一些事情,頗有一些感觸。
這是一本小書,也是一本小說,我是看電子書,但看完之後我又買了紙本書(送給身邊的朋友)。書中一位成功的企業家對於選擇合作對象的想法,讓我重新省思一些幾乎快被我忘記了的原則。
書中主角是一個成功的年輕人,算是在當今這個營營汲汲的資本主義社會中的佼佼者,然而有一天,他在飛機上碰到了這位很不一樣的企業家,在企圖爭取這個企業家成為他的客戶的過程中,他所學習到的一些故事。
看完這本書後,讓我回頭思考的問題是,這個世界不知道從什麼時候開始,充斥著各種商業與管理技巧,各種tips類型的準則,讓我們目不暇給,眼花撩亂。時間管理? 談判法? 如何成交? 銷售的心法? 甚至連生活都有小技巧...然而被這些tips轟炸的同時,我們都忘記了很多最基本的原則。
其中之一,就是『誠信』。
為什麼對這個特別有感觸?
書中的企業家選擇合作的廠商,首先看重的不是獲利能力、不是資本額、不是折扣的高低、或是交易的利益。而是這家公司的誠信、道德操守、以及員工、經理人的人格特質,和公司文化。
我發現上面這一行最後幾個字,幾乎是我們現在在報章媒體上已經很少看到甚至很少被用的文字了。
最近一兩年,我們的開發團隊整個改為agile與scrum,然而碰到最大的挑戰,並非制度與工具、也不是人員或方法。坦白說,最大的問題是外部的客戶、採購與銷售。
Scrum在意團隊,也在意客戶,agile從軟體開發最原始的角度出發,我們希望建構一個客戶能用、好用的軟件。說真的,這可能是每一個軟體開發人員最原始的初衷,沒有人希望自己寫的code只能看不能用(或是不能看也不能用)。
然而,從這個角度出發,實際上會碰到最嚴重的問題,其實往往是『信任』。
依照Scrum,最合理的合約與付款方式是time material,也就是合約金額不固定。原因很簡單,因為我們隨時接受需求變更,如果隨時接受需求變更,那總工時當然也會跟著變更,沒有道理總工時調整了,合約金額卻不變吧? 這種合作模式,time material當然是最理想的付款選擇。
然而,這在台灣幾乎被視為不可能。
客戶總是希望固定付款金額,固定工時(遲了還要罰錢),但需求內容則在成案後還是會變更(好一點的客戶會註記變更幅度不超過15%之類的),麻煩的是,許多案子在成案前也無法把規格或scope確定(或許從客戶的角度來說是確定了,他有提供三張A4描述了SOW啊?但對我來說靠這三張A4要精確地算出專案成本,根用猜的差不多吧? 更何況還要落在合約上?)。但如果選擇先談好規格再簽約,則往往案子不成,SA成本卻又已經付出了。
當然,我們知道客戶的老闆想知道完成這案子大概要花多少錢,這我們能夠理解,但合約上能不能不要寫死那個金額還加上罰則呢?不行 >_< (很多客戶會質疑,你們又不是on site做案子,我怎麼知道你會不會浮報工時?我心裡想:難道我們on site就沒法浮報工時嗎? 你就能肯定我們寫的code一定和你的案子有關?)
因此軟體廠商為了自保,只好在時程預估上保留很大的buffer,膨脹工時或是人天數,以避免案子賠錢。久而久之,買方採購就習慣拿到報價先砍個2-3成,接著的拉鋸就是看買賣雙方的談判技巧了。
這樣的報價模式,廠商留有buffer,買方採購也可以交差,剩下就聽天由命了。如此一來,痛苦常常發生在專案開發團隊(一直碰到需求變更而無法結案)與軟體終端用戶(最終拿到可以驗收卻無法用的軟體)身上。
從整個交易過程和行為模式上來看,你很容易發現,這種deal其實是一個假雙贏的零和遊戲。本質上買賣雙方幾乎沒有進行第二次交易的打算,似乎都想幹完這一票走人的感覺。
有時候買方會說,Eric你放心,我們後面還有很多這樣的案子。有經驗的Eric心裡會想:你少唬爛我,我這筆先賺到再說,大不了不拿尾款(當然,表面上肯定不會這樣說)。
這種交易裡面少了什麼? 對,就是我想說的:『誠信』。
在累積了幾年的接案經驗之後,我大概得出一個結論:只要客戶企圖用最低的價格讓你做這個案子,那表示該客戶後面肯定幾乎沒有其他案子會給你。
久而久之,我開始把報價越拉越高,主動放棄需要用價格來競爭的案子,因為我不想要(我需要、但不想要)這樣的客戶。我希望跟客戶的合作建立在誠信上面,我希望培養的是長時間的默契與往來,我希望真的透過我們團隊的技術與經驗(這才是真正值錢的部分,我的客戶你必須認同),協助客戶解決難題。
因為這樣,我們必須放棄很多的案子,因為客戶和我的理念與公司文化不合。
坦白說,這很辛苦。我甚至也不知道值不值得。
但回頭想想,難到不該這樣嗎?
看看身邊,最近台灣很多食安的問題,不也是因為誠信? 賣你黑心商品的上游廠商,心裡想的也是賺一票走人的邏輯、考慮的不是永續經營,而中間廠商只願意用最低的成本採購原料,用最有競爭力的價格賣給消費者,這彷彿已經是商業既定的唯一真理。(但競爭力怎麼來的呢?壓榨了誰呢? 犧牲了什麼呢? 卻沒人在意了)
記得有天我感慨的在臉書上寫到:『在這個時代,大多數人都遺忘了一件事情,就是商業行為一開始是建立在信任和誠信上的。如果大家還有印象,就會發現以前(近百年前)的廠商,對信用這兩個字很在意的,人無信不立,說到的就一定要做到,撒謊和欺騙是一件很嚴重的事情。但這個時代變了...所以其實重點是在,重新建立一個和消費者之間的信任的過程...
(想一想其實很好玩,30多年前我記得沒有超商的時候,巷口的雜貨店老闆我是認識的,他住在那,從小我就看著他長大,老闆的兒子是我同學,我100%信任他賣給我的東西不會有問題,但時代變了,7-11可以讓我買到遠在海外不知名的地點生產的加工食品,但我卻再也沒辦法信任這些賣我東西的廠商...)』
科技是進步了,但我們在商業行為中慢慢失去了最原始的信任。
台灣在中小型的軟體專案當中,報價空間是非常大的,差價大多來自專案團隊的經驗、以及許許多多看不見的東西(專案管理技巧、需求分析能力、控管能力、對品質的要求、問題追蹤能力...etc)如果客戶像是選擇香豬油一樣用最低的價格來選擇一個軟體開發廠商,所能得到的軟體能吃嗎? 喔,當然可以,就像香豬油一樣,只不過就是有點不衛生罷了...
訂閱:
張貼留言 (Atom)
熱門文章
-
前面 我們討論到了很多跟Line Bot有關的機制,但有朋友提了一個問題,如果我單單只是要透過程式碼發訊息給用戶,一定要申請並建立一個Line Bot嗎? 其實不用。 一直以來,有一個比較不被重視的機制,叫做LINE Notify,其實它已經誕生很久, IFTTT 的Line...
-
其實我們在好幾年前,就已經談過DI(Dependency Injection)這個主題。當時這類議題被視為進階的開發概念,但如果你最近開始使用 .net core,大概已經發現DI如今已變成.net core中的基本要求。 事實上,從事教育訓練這麼多年的觀察下來,不難發現其實還是...
-
LINE Bot這一系列,從2016年五月開始,寫著寫著也快30篇了,差不多剛好一個月一篇,如果資訊雜誌還在的話,應該可以是一個專欄。 很久沒有整理索引了,2019年初,再次將這一系列相關連結整理如後: 使用C#開發LineBot (1) - 用c#建立一個LineBot...
-
Windows 8, 一幅蓄勢待發的姿態。 在最近一兩個月,微軟全省跑透透,辦了多場介紹Windows 8的研討會,也陸續的在網路上大方的提供了Windows 8先前的Developer Preview以及最近的Consumer Preview版本讓大家免費下載。 過去段...
-
這一篇很特別,我們要來談談 asp.net (.net core) 的身分驗證類型與基本原理(架構)。 最近這幾年,你可以從網站上找到任何你想找的資訊,特別是程式碼片段,但我總是眼睜睜的看著學員或客戶,從莫名的網路上抄來一份代碼,試著崁入自己的程式,無奈就是怎麼塞都塞不進去,...
-
當許多用戶開始使用 LINE Notify 之後,就會發現它真是一個方便好用的機制。 他的推播速度不亞於使用Messaging API的Push Command,甚至我覺得在群發上有更高的彈性與控制自由度。我們只需要得到用戶的Token,就可以輕易的透過HTTP POST發訊息給...
-
最近的 Line Notify 、 Line Login ,以及前一陣子的 Microsoft Graph API ,全都使用到了OAuth作為用戶身分驗證以及資源存取的基礎。但很多讀者會卡在OAuth的運作流程上,根本的原因是不理解OAuth到底是幹嘛的?其存在的目的為何?以及...
-
我得說,打從2000年以來,我從來沒有那麼期待某一個PowerPoint的新功能。也幾乎沒有為了某個新功能而安裝新版的Office,但…Morph讓我破例了… 最早看到這個功能是在底下這支影片: https://www.youtube.com/watch?v=FeUolRLac...
-
你沒聽錯,事實上asp.net WebForms也能走SPA(Single Page Application)的開發架構,並且跟在前端的Bootstrap與Vue.js框架搭配得很好。 技術的使用存乎一心 記得曾經對學員說過,不管你用哪一種開發方式,只要對開發技術有足夠的熟...
-
最近由於在AI課程中有愈來愈需要支援(不是系統,是我)其他語言的趨勢,因此VS Code在毫無疑義的狀況下,成為.net環境以外的開發工具。 所以,相關的筆記,也稍微整理一下,以備不時之需。這一篇,就是。 其實要用VS Code開發Node.js超簡單,從一台空的PC開始。 從 ...

沒有留言:
張貼留言