iT邦幫忙

2021 iThome 鐵人賽

DAY 6
1
Modern Web

機智接案生活 - WooCommerce 金流串接實戰系列 第 6

Day6 - 程式設計報價 (ㄧ)- 報價單的 Bug

老實說,在自己還沒轉型以前,我最討厭的部分就是接洽新專案這個環節,從詢問來信開始,初步了解需求,然後碰面洽談提案 ( 當時線上會議還不流行 ),整理會議記錄、網站規格、報價單、合約書,寄給客戶之後開始針對報價單的內容逐一刪減,被砍價是理所當然,而議價是我覺得最難受的過程,彷彿在說我這個人不值這個價,雖然理智上知道這是商業談判的一環,但心理上很容易就會跟自己過不去。

接下來就是合約書,要提交給客戶的法務審查,審完後提出修改,當然修改條件我也要看過,於是中間又是一連串的來回,最後,真正開案大概是第一次會面之後的三個月了,而這三個月所花費的時間還沒有產生任何一毛的收入。

以往我的報價方式是用我每月的生活成本來計算,一般來說如果是要架設企業官網的話,我會從企劃、設計到程式開發等工作項目估算開發時間,假設我一個月的目標是要賺 10 萬塊,而過去的經驗這類案子我估計兩個月可以做完,那我總價就會報 20 萬元,如果沒在兩個月內做完,我就開始賠本了。

然後報價單裡面列了一些很空洞的項目,像是 WordPress 安裝、資料庫建置、環境配置、前後端程式開發、API 串接等等,不能寫得太具體是因為根本就還不知道實際開發會遇到哪些問題,只能就過去的經驗把基本的開發流程列入,而列這些基本的項目也是擔心報價單被拆解,被拆解就無法報到我期望的金額,所以報價單都是列一些基本不能砍的項目,再加上客戶特別在意的功能所組成的。

接下來我會想盡辦法用各種文件以及約定結案日期來讓專案可以在兩個月內完成,像是每週固定會議、追客戶資料、整理修改需求單、驗收確認表,同時還要處理設計、開發,但做這麼多行政作業的結果,真的能在設下的時間點內結掉的專案少之又少。

所以每當下一次專案開始的時候,又會給自己增加更多規定來確保案件能如期執行,然後樂觀地期待著這次應該沒問題了吧!當重複失敗了 N 次以後,才開始認真重新檢視自己的工作流程,歸納出以下三點原因為何這樣的報價方式存在著 Bug:

自己個性的使然

我喜愛寫程式,我願意學習各種程式開發的知識,更希望透過自己學到的東西,去幫助需要的人,同時也能讓自己有飯吃,然後透過我的專業技能去解決他們的問題並讓自己獲得成就感,這是我給自己工作成功的定義。

然而隨著時間經過,就會不知道被第幾版的修改需求單給澆熄了熱情,每天在做的事情就是跟客戶爭執說這些功能並非在當初的報價範圍裡面所以沒辦法做,但更多時候就是睜一眼閉一眼做給客戶,因為爭論要做不做的時間已經夠我把這功能做完了,但背後更大的原因其實是我「害怕衝突」。

這樣最後的結果就是一直被凹,有苦自己吞,不停的告訴自己沒關係,這些新加的東西我應該很快就能處理完,多做就是多學,這些客戶會感謝我、會介紹更多客戶給我,弄不完就加班處理,這次拼一下、撐過去就是我的了、男人就是要能忍耐,然後把自己變成只是為了要能結案收尾款的工作機器,客戶要加的需求合不合理我早就不想管了。

因此在當初約定的報價製作項目下,實際要執行的項目是多了好幾倍,每多開發一個功能就要多一道修改驗收的流程,還會影響到既有的已經開發完成的功能,這樣完全不可能在原本預計的時間內完成。

客戶對於外包專案的認知

要能把報價單裡面所有的項目準時做完除了要靠自己的努力外,剩下九成九的關鍵都是要看客戶對於這個專案的認知,對於客戶來說,通常需要發包就代表他們公司內部沒有專人可以處理這件事,所以花了錢無非就是希望可以減少人事並得到預期的結果。

但很多公司往往忽略了外包的溝通成本,畢竟「預期的結果」公司內部不同職位的人會有不同的看法,更不用說還要傳達給公司外部的接案者,光是一個按鈕的位置可能就可以討論好幾個禮拜,而這些討論在還沒具體執行前都是一團謎,等公司內部討論出一個結論後,可能跟原本報價單裡面的項目完全不一樣。

再加上負責專案的窗口往往都有自己原本的工作要做,所以等待網站需要的資料、文案、素材也會花上很長一段時間,其他像是等待確認製作方向、驗收製作項目等等,這些全都不是我可以掌控的因素,這些溝通成本都無法反應在報價單上面。

因此即使照著過去的同類型專案的經驗來估算案件金額,每一間公司的狀況都不一樣,遇到「特別不一樣」的公司就會後悔當初自己報太低,雖然可以追加製作預算,但中間需要「再溝通」的時間,我寧願趕快結掉去接洽新的案子,對組織龐大的公司來說追加預算不是一件容易的事。

其他外力因素

其他像是身體不適、小孩出生、家人生病、窗口離職、職務轉換、老闆出差、颱風、全球疫情等等的各種外力因素,都可能造成公司決策的改變。

總結以上三點因素,我得到了一個結論:「專案永遠不可能在一開始預計的結案日期結案,因為需求每天都在變」。真實世界裡有太多的變數在影響著一個專案的進行,如果報價單出去後就再也不能變動了,這對甲乙雙方都是一種雙輸的局面。

依照傳統合約的定義方式,只要乙方把報價單裡面的項目全部製作完成,並且收回尾款就算是結案,但所謂的「製作完成」只是乙方單方面的認知,對於甲方來說,乙方的產出到底能否符合商業與管理上的需求,這樣的認知是非常主觀的。

最常聽到的就是當甲方看到成品時發現某個他認知「理所當然會有」的功能結果沒有,就會很驚訝的問說:「這功能不是基本的嗎」?然後乙方就會納悶,開始解釋這功能當初沒有寫進報價單所以沒有開發,於是雙方就會進入僵持,直到某方退讓或是協調出雙方都能接受的作法。

雙方的目標不一致是讓結案如此困難的原因,甲方要能透過這個專案的產出來達成商業目標,而乙方是要嚴守當初報價的內容,避免無止境的修改需求或新功能讓自己或公司陷入營運的困境,但商場上每天都是瞬息萬變,昨天討論的內容可能今天就會被推翻,更不用說是在兩個月前討論的規格,怎麼可能在兩個月後完全一模一樣,所以乙方就會非常辛苦,為了要結案可能要做某些退讓,同時也要堅守底線不然案子會賠到脫褲子。

上述這些狀況都是我以前每天的風景,但知道原因之後,問題就解決一半了,下一篇文章我會介紹讓我接案職涯 180 度大轉變的方法,讓我現在可以每天有兩個小時創作時間與週休三日靠得就是它:「敏捷式接案」。

本文同步發表於:https://oberonlai.blog/tw/wordpress-freelance-quotation-1/


上一篇
Day5 - 找出適合自己的案子
下一篇
Day7 - 程式設計報價 (二) - 重新定義甲乙關係
系列文
機智接案生活 - WooCommerce 金流串接實戰30

尚未有邦友留言

立即登入留言