前幾週跟一位朋友吃飯聊到如何說服客戶改用時薪計價這個話題，覺得當下的回答太籠統了，決定還是好好寫一篇文章來把這件事解釋的更完整一些，我當時的回答是：

「不用說服，只要讓願意接受時薪計價的客戶主動找上門就好。」

事後回想我現在有一半的客戶都是從專案計價的方式轉換成時薪制的，我花了非常多的心力把這樣的合作模式寫成文章，並且跟他們解釋以往的專案計價所產生的問題以及採用時薪的種種好處，回過頭來看自己也是非常用力的在推銷、說服，但也許是因為這樣的模式已經深植在自己的意識中，在跟客戶解釋時好像只是在表達太陽會從東邊升起西邊落下一樣的自然，因此從不曾覺得自己有花力氣在「說服」。

如果你有看過我「敏捷式接案」的系列文章，或是遇到瓶頸想要改變接案模式，我會建議你透過以下幾個步驟來著手：

一、養成紀錄工作時數的習慣

我第一次嘗試用時薪接案時，我完全不知道該如何估算每個工作項目會花少時間，畢竟以前的工作模式總是所謂的「多工」，也就是 A 專案做沒個十分鐘，就跑去處理 B 專案客戶的來信，然後三不五時又跟 C 客戶在 LINE 上面閒聊打屁，過了半小時後再回去處理 A 專案，這樣很難得知一個工作真正花費了多少時間。

所以首先在工作時要斷絕所有的外界聯繫以專注在手邊的任務，這樣計時的準度才會高，也才能知道自己在面對不同類型的工作內容時大概會花多久時間，同時也要意識到做這件事情需要經歷哪些步驟，邊做邊紀錄會慢慢發現自己的工作習慣。

有了紀錄之後就能回顧自己在處理哪些任務時會需要花費較多的時間，或是發現到既有的習慣可能會造成不必要的時間浪費，像我以前常常因為一個 Bug 解不開就在那邊糾結好幾個鐘頭，即使到了下班時間還是不下班，硬是要把這個問題解掉才甘願，如果還是解不掉就會很生氣最後搞得自己心情非常差。

但從時間紀錄來看這樣的糾結完全沒必要，因為通常都是睡一覺醒來或是去散個步放空就能看到新的解決辦法，所以我強制規定自己如果一個 Bug 超過一個小時還解不掉就先放下它，也因為有時間紀錄讓我知道一個小時的研究就能讓我的大腦有足夠的資訊來自動找尋解決辦法，只要一超過這個時間我只會採用不理性的瘋狂試錯法來除錯，在沒想清楚的狀況下全都是浪費時間。

這樣訓練久了就能在評估客戶需求的當下拆解待辦清單並估算出每個待辦事項會花費多久時間，然後不斷修正自己的工作習慣來提升效率，因此養成紀錄工作時數的習慣是時薪計價法的第一步驟。

二、讓敏捷開發精神植入你的意識

我從來沒有與採用「敏捷開發」的團隊共事過，這四個字對我來說只是書本上的專有名詞，最常聽到的就是朋友在抱怨這四個字根本就是比較好聽的「責任制」，而且印象中覺得都是有規模的開發團隊在採用，不曾意識到這件事可以應用在個人接案上。

我是從自身的經驗來思考這件事，因為每個案子一定都會遇到這些問題：需求變動、驗收過不了關、認知落差，這些問題不管事前規劃的再詳細總是一再發生，然後某天轉了一個念頭：既然再怎麼規劃都還是有問題那乾脆就別規劃了，想到哪做到哪、接受需求一定就是會變，事後才驚覺原來這就是自己以前書上唸過的敏捷開發精神。

當然正統的敏捷開發不會像我這邊隨便，它是有很多規則與方法在裡面的，於是我開始重新閱讀相關書籍才發現到世界上有很多根本不是軟體開發的團隊也在使用它，驚訝之餘也重新認識了它，並從中擷取我需要的部分結合時薪計價模式，最後命名為「敏捷式接案」。

推薦兩本敏捷開發的入門書：

​SCRUM：用一半的時間做兩倍的事​

​敏捷大師精選​

如果哪天你聽到朋友在抱怨公司的專案管理有多鳥、外包廠商有多差勁、其他部門的需求有多機車時，你會開始想跟他介紹敏捷開發的話，就代表敏捷精神已經進入你的意識了XD

三、透明化自己的工作習慣

有了工作紀錄跟心得後努力的把他分享出來，除了可以讓同行交流學習外，也能讓潛在客戶知道你的工作模式進而主動與你聯繫，我想到了這個階段才是真的「不用說服，只要讓願意接受時薪計價的客戶主動找上門就好」。

而且跟寫技術文一樣，在整理的當下會有不同的思考方式與觀察角度，像我常常就是在寫整理文時發現到還可以改進的地方，同時還會接到讀者的回饋來逼自己思考還沒遇過的問題，最重要的是透明化帶來信任，時薪制需要非常高度的信任才能運作下去，畢竟客戶還是不可能百分之百理解你這一小時的時數花費到底做了哪些事，只能透過持續的溝通來同步資訊，而寫文章就是就一種溝通的方式。

四、站在客戶的角度思考解決方案

我問過自己一個問題：如果一個專案客戶花 10 萬塊就能把開發需求吃到飽了，為何還會想採用時薪制吃多少算多少？

首先是降低短期的大筆開銷，取而代之的是每月平均分攤開發成本，傳統專案通常都會需要付清訂金後才會開案，然後再付期中款與尾款，再大一點的專案還會再分更多期，但錢付下去之後就很難回頭了，如果外包團隊溝通不良、技術不足，中間要付出的溝通成本非常可觀。

採用敏捷式接案隨時都可以結束合作，如果發現苗頭不對能夠決定是否繼續下去，也不用為了取回已支付的費用而爭執不休。

其次是程式碼品質，我自己寫過太多那種為了要結案的程式碼，那些程式碼只是表面可以運作但維護成本很高，再加上許多潛在的風險埋藏其中，只要網站沒爆炸就永遠不會被發現，採用時薪制讓接案方有充足的動力去寫出品質好的程式碼…

以上問題是我在說服客戶採用時薪計價的範例，關鍵是站在客戶的角度思考，尤其是當客戶從他的角度提出需求時，我不用擔心有更好的作法但卻怕弄到自己而不敢提出，雙方都能專注在解決問題而非顧慮政治因素，這是我認為敏捷式接案所帶來的最大價值。

當然，客戶百百種，我還是常遇到覺得我時薪太高以及總開發時數過久的客戶，針對反應時薪太貴的客戶，我的說法是採用敏捷式接案不用擔心一次性的大筆支出，透過專案管理工具以及每週的回顧，對客戶來說可以隨時掌控花費，更具體的方法是請客戶設定每週或每月的時數限制，在這限制下把客戶最在意的功能優先處理好，剩下的等客戶有更多預算再來處理。

針對反應總開發時數過久的客戶，我的說法是這些時數都只是預估，具體的時間還是要實際執行後才能知道，然後我會請客戶將他們可以協助的部分先準備好，像是需求整理以及製作文件，減少往返溝通時間就能降低總開發時數，同時一樣強調時數花費的透明，讓客戶認知到隨時喊停都是沒問題的。

如果經過以上的溝通客戶還是希望採用專案的計價模式我就會放生了，雖然我也曾經被客戶的預算誘惑過，但不遵守自己定好的原則只會再次陷入痛苦的循環，為了維護這得來不易的生活說不是絕對必要的。

你下一個案子會想要嘗試敏捷式接案嗎？會的話實際執行上有遇到問題都可以問我，我們下週見！