​

不知道你有沒有遇過一種案子，客戶提出的需求不會太難，你心裡有個底知道哪些外掛可以搞定，而且還會擔心客戶萬一知道這些外掛的話可能就不需要你了，因此談成後會覺得這案子應該是個 Easy Money，每當我覺得有這種案子時最後的結果總是無法如期結案，並且跟客戶鬧得不愉快。

有一次我與一間新創的兩位創辦人一起約在星巴克談案子，第一印象很好，兩位創辦人非常客氣而且很認真，他們拿出一張 A1 大小的海報紙上面填滿了便利貼，全部都是關於這個新創網站的開發需求，我看完後直接跟他們說他們要的功能有很多的付費佈景主題可以實現，於是會後我就幫他們挑了幾個適合的讓他們選。

他們看到也很開心，所以在報價時我報的項目就是協助安裝佈景主題與設定，不含任何的客製化開發，結果設定完後才是災難的開始，當他們實際看到網站後，新的想法如雨後春筍般冒出來，如果是靠佈景主題就能解決的還算小事，不能的就要用很多迂迴的方式來達成。

我自己心裡當然知道這些作法不好，但我的報價單就只包含設定的項目，我該裝死還是認賠幫他們客製化開發？最沒有預料到的是他們的資料量爆大，然後他們還希望我協助上資料，最後為了可以結案，還是花了不少時間來處理這些額外的工作，重點是他們還覺得我不專業而鬧得不愉快，只因為我打槍了很多他們提出的額外需求。

結不了案的原因

我遇過各式各樣無法準時結案的原因，像是客戶資料很晚才給、做完的東西沒有人驗收、負責人出差、窗口請長假、專案的方向變動等等，尤其是甲乙雙方對於結案標準的認知有所不同是最常見的因素，這會導致甲方要求乙方還需要完成哪些項目才能結案，也就是像我上面遇到的狀況。

雖然理論上可以針對額外的工作項目來另外報價，但事情往往不是這麼單純，不單純的點在於如果是以功能為導向的報價方式在報價單不可能涵蓋所有的細節，這些細節都是在開案後與客戶一起討論出來的，假設今天報價單寫的是建置線上課程販售平台，那麼頂多就只會列出大項目。

所以當案件目的是建置線上課程販售平台，很多衍伸性的需求就會接踵而至，而這些衍生需求會增加額外工作時，乙方會覺這必須要另外報價處理，但甲方會覺得這個需求是屬於建置平台的一部分，理應也要包含在既有的報價裡面，這時候理性一點的話還能討論出一個共識，情緒起來的話就是雙方鬧得很僵誰也不讓誰。

因此預期外的工作項目是我認為無法順利結案的元兇，理論上只要把焦點放在如何控制預期外的工作項目就能順利結案，在控制它之前先理解這些工作是從何而來的。

預期外的工作項目

所謂的「預期」指的就是報價單裡面有寫的項目，整個案件的金額就是由這些「預期」的工作所累積加總的，因此預期外的項目就是當然是能少就少，但我以前常常會小看案件的規模，以為只要裝一個佈景主題或外掛就可以搞定，卻忽略各種檯面上看不到的隱藏要素。

這邊列出三種可能會產生預期外工作的原因：

1. 輕忽專案規模

如果是客戶自行上架商品資料，用 WordPress 建置 10 個商品跟 10 萬個商品的購物網站感覺差異不大，都是一樣的後台管理與前台購物流程，但實際上當網站資料量一大各種問題就會冒出來，先不講系統資源的問題，光是客戶希望可以用程式自動批次修改商品資料就會是很大的麻煩。

或是使用者達到一定的規模也會是需要注意的部分，不管是前台的顧客還是後台的管理人員，每多一位使用者就會增加一個流程，每個流程之間的關係與連動會提升整個專案的複雜性，有時候光是要除錯就會花上不少的時間，當然，這些時間客戶會認定是在報價項目之中。

2. 功能的認知差異

你認為的購物車跟客戶認為的購物車是同一種購物車嗎？像我們這種 WooCommerce 閉著眼睛都會用的老屁股，客戶認知的購物車搞不好是某個 web1.0 時代的系統或是規模超大的購物商城，在這樣的認知落差下報價單只寫一個 WooCommerce 建置鐵定會爆出一狗票的預期外工作。

3. 忽略執行細節的複雜性

客戶的 A 需求用 a 外掛搞定，另外針對 B 需求裝了 b 外掛，結果萬萬沒有想到 ab 外掛會產生衝突，導致其中一項需求沒辦法運作，或是你安裝 c 外掛來解決 C 需求，但是只能解決 70% 的問題，剩下 30% 必須要用一些獵奇的方法來處理，可能是要多裝 d 外掛或是換成 e 外掛，這些全都是預期外的工作。

我自己則是常忽略前端開發的複雜性，除了在各裝置下要能正確顯示外，在介面的互動部分更是有很多的細節常常會漏掉，像是資料載入狀態、提示畫面、當資料長度不一時所造成的畫面跑版，前端要處理的工比後端多上很多，也因此我常常會低估這項工作。

降低預期外的工作

知道產生的原因之後，接下來就想辦法 Debug 吧～這邊舉出三個可以順利結案的關鍵：

1.確認客戶需求的規模

了解客戶的資料量、使用人數、公司組織，都是可以先讓自己心裡有個底，在報價階段就能預先得知可能會衍生的問題，並把這些隱藏成本納入報價單的計算之中，更明確的做法就是量化報價項目，像是常見的依照頁數來計價就是這樣的做法，把量的成本具體化。

2.實際體驗客戶的認知

放下你以為的功能，實際觀察客戶所認知的是什麼，跟著他們一起走過一次功能的操作流程，並在適當時機提出問題，像是 A 功能會需要嗎？B 頁面是否應該也要有？並在會後梳理這些流程作為報價項目的參考依據，藉此減少彼此的認知落差。

3.盡可能的多學執行細節

如果你有夥伴可以幫你處理執行細節很棒，但如果你能知道這些執行的邏輯將會更能做出精準的報價，像是沒事就多玩玩外掛，知道哪些配哪些可以解決什麼問題，培養後台操作的敏銳度，使用從沒用過的工具也能十分鐘就上手。

其次是多理解程式開發的相關知識，像是程式語言的類型、資料庫的編排方式、資料的讀寫，雖然你可能完全不用寫程式，但這會幫助你提早發現一些不合理的需求，尤其是違反程式邏輯的作法，避免造成後續無法結案的災難。

結論

我在之前有寫過我現在不用報價單而改用估價單，因為我已經放棄掌控預期外的工作甚至放下結案的執念，人不可能預知未來，頂多只能預測可能會發生的事。但要接案接的順利一定要找出適合自己的方法，有些人天生就是結案高手，從來沒有晚一天收到尾款，而我只能依自己的個性找出適合自己的方法，相信你一定也可以！

你有關於結案的心得想跟我分享嗎？回信跟我聊聊吧～我們下週見！