從傳統的接案甲乙方關係我們發現，因為利益的衝突，甲方也不可能得到乙方 100% 的專業協助，因為乙方要的是結案，沒有在報價單裡面的項目乙方沒有義務提供，但甲方花了錢就是希望為了獲得這些專業建議，所以造成彼此雙輸的局面。
所以我對於結案的認知，並非是收到尾款或是過了約定結案時間後就算結案，而是乙方可以滿足甲方的商業目標而提供持續性的專業建議，當甲方決定暫停該專案或是結束與乙方的合作關係時，這才是所謂的「結案」，當甲乙方的關係不再是短期的專案性質，而是持續性的互惠合作，這樣的接案方式我稱之為「敏捷式接案」。
敏捷式接案的核心精神是捨棄傳統的報價單、合約書，改用時薪估價、Email 約定合作細節，並透明化開發過程，像是分享時間記錄、開放版本控管權限、每週固定回報進度等等，再根據實際花費時數來計算費用，以月結的方式來減少發案方的一次性大額開銷以及維持接案方的固定現金流。
很多案件剛開始時甲乙雙方都不熟悉，談的時候很愉快，結果實際做起跟彼此的想像落差很大，在敏捷式接案中發生這樣的狀況也沒關係，就直接終止合作，隨時都能「結案」，不需要為了硬撐合約書上的條文而折磨彼此，更不用吵已經做的進度佔專案總金額的多少比例來退費。
在這樣的合作模式下，報價就再也不是固定的金額，而是在專案初期針對已經知道的部分進行開發時數預估，同時也能把需求訪談的時間估算進去，然後把總小時數乘以單位時薪，就能讓客戶大概知道要準備多少預算來執行這件事，重點是要讓客戶明白這個金額不是案件的總金額，一切都只是預估，是會有變動的。
如果客戶已經很明確的知道他要做的功能，那我就會把要做這個功能的每一個流程拆解成小單位來進行估時，譬如說以評估串接金流時數為例：
(一) 前置作業 - 2 小時
(二) WooCommerce 設定介面開發 - 4 小時
(三) 信用卡金流串接 - 12 小時
(四) 測試&資料移轉 - 3 小時
這份列表的重點是我把溝通成本的時數也一併評估進去，像是客戶提供功能開發所需資料的時間、需求確認的時間、測試的時間等等，這些以往都沒辦法放進報價單裡面的項目，如果是用估算的話就能很讓客戶具體的看到做這件事情所有的預估成本，這樣比只列出空洞的大項目更能讓客戶把焦點放在要執行的具體細節上而非只是在意專案總價。
每個項目的估時我是參照 Scrum 的故事點所設計的，雖然 Scrum 強調的是以相對的時間單位來預估開發複雜度，但我從經驗得知用絕對單位才能讓客戶感受到實際的花費，我的時間預估有四種單位：
評估 1 小時的項目：通常是我十分鐘就可以解決的事，也就是完全不複雜、可以快速搞定的功能，但也不是沒有評估錯誤的時候，萬一估錯的話我就還有 50 分鐘的時間可以來把問題釐清，並且檢討自己為何會錯估的原因。
評估 2 小時的項目：做過類似的功能、可以在腦海中想像開發這個功能需要哪些步驟，雖然可能會有點複雜，但腦袋很清楚該如何實作出來，或是需要跟客戶一起合作討論的項目，這讓會議時間也能收費。
評估 3 小時的項目：需要打很多字的功能，像是上面例子中的要處理傳送給金流商的一堆欄位，以及拿到回傳資料後的處理，或是需要處理前端 UI 的部分，我都會估三個小時。
評估 4 小時的項目：自己從沒做過項目、腦海中無法想像會有哪些步驟、需要花時間先進行研究的功能，隨著經驗與能力的提升，需要 4 小時的項目會越來越少，大部分都能拆解成多個 2 小時的項目。
我的評估項目不會有超過 4 個小時以上的，如果超過 4 個小時，就代表這個項目太大了
，還沒有被拆解成能被執行的最小單元，把每項功能拆解足夠細的任務後，就能把所有項目的小時數進行加總乘以時薪，就可以估算出開發這個平台至少要準備多少預算，萬一超出客戶預算太多，就直接從清單中去刪減，留下真正需要的功能，或是請客戶排出優先順序，把資源用在真正重要的事情上。
隨著開發的經驗越來越多，寫一份評估表可以越來越快，可以省下整理報價單的寶貴時間，也能採取更彈性的作法，像是客戶希望設定每月預算，就能以不超過這個時數為前提，優先開發客戶在意的功能。
待預算經過客戶確認後，就能開工了。對，不用訂金、報價單、合約書，彼此合作的約定只需要透過 Email 保存即可，這時候只要在收信軟體開一個專案的資料夾，然後把關於這個案件的信件全都往裡面丟即可。
這樣的方式聽起來好像很夢幻但又覺得抖抖的，心裡會懷疑真的有客戶會接受這樣的合作模式嗎？沒有先拿到訂金、審過報價單、合約書，之後發生任何糾紛該如何是好？下一篇文章我會整理出這種接案模式面臨的挑戰，以及實際運作之後遇過的問題。
本文同步發表於：https://oberonlai.blog/tw/wordpress-freelance-quotation-2/
iThome鐵人賽
看影片追技術