自從改變自己的工作模式後，現在平均的案量是每天有計時的工作時數大概是三個小時，並且同時有三位長期配合的客戶，週休三日，禮拜三強制自己排休，維持做二休一的節奏。

「每天只做三小時卻能同時接案三位客戶!?」

如果在我還沒轉型前有人跟我這樣說，我會覺得這人一定是在唬爛。以前我的極限是一個月兩個案子，然後每天工時至少八小時，常常做到晚上加班加到十、十二小時也是家常便飯，為了要讓專案趕在某個約定好的日期完成，就是只能一直拼命的做做做。

現在回過頭來看待以前的自己覺得好不可思議，每天忙得跟狗一樣卻沒什麼成就感，心情又很容易受到客戶意見的影響，尤其是做好的功能又說要改，規格一變動工時的爆增就無法避免，這篇文章就是要來跟大家分享我是如何轉型成 333 工作法。

這個專案要做多久？

常遇到客戶來信說他需要一個網站，然後接下來的問題就是多少錢以及要做多久，有時候也會在 FB 的接案社團裡面的看到業主的發案文，簡略描述了案件需求後就希望徵求報價與開發時程，然後就會看到留言區蓋起私訊牆，其中還不乏說已私訊報價與製作時間。

我每次看到心裡都會有一個大問號：「在根本還不了解客戶需求的具體工作事項前，這個價格與時間都是怎麼評估出來的？」但事實上我知道答案，因為我以前也是這樣報價的：假設客戶要一個購物網站，根據過去專案的經驗大概需要兩個月，如果時間是兩個月，我就把我的生活成本以及想要賺的部分加好後作為報價。

所以接下來為了要在兩個月完成這個案子，一定要花上所有的時間把它做完，因為沒做完我就賠錢了，案子多拖一個月，就等於多賠一個月的生活費，而且最重要的是我想努力把案子結掉，所以根本沒有心思或時間再去接洽新的案子，因為只要接了另外一個案，原本的案件能執行的時間就會被壓縮。

所以一個月同時進行兩個案子就已經是我的極限，光是要釐清客戶需求、規劃程式架構、功能開發、測試，就讓我精疲力盡，而且這樣的時間規劃完全沒考量到客戶的商業情境，因為當功能真正實作出來之後，老闆看到後會覺得好像應該再加些什麼，老闆的老闆也會有想法，所以當做好後要再加東西總是會讓我火冒三丈，心裡總是有 OS 說為何不一開始提出來？但冒完後就還是往肚裡吞，為了結案繼續默默的修改。

這樣造成的結果就是每天工時拉長，兩個月內要完成的話，每一週都會有必須要完成的進度，如果稍微延遲了，加班把進度追回來是一定要的，但如果是客戶需求變動而造成工作量增加，還是要想辦法把在時程內完成。喔，對了，等待客戶回覆確認需求的時間也是算在時程內喔~

月底一定要準時上線！

現在，如果客戶希望某項專案可以在某個日期前完成我絕對不會立刻答應，我會先估算開發小時數，然後根據最近手邊工作量來確認該功能在一個工作天之內我能分配多少時間來處理，譬如說如果總工時我評估需要 10 個小時，而我現在每天可以分配兩個小時來做它，那麼至少需要五個工作天。

所以關鍵在「工作事項」，特別是規模稍大一點的開發專案，在初期的評估根本無法預料到底會花多久時間，因為從想法到具體實作之間還存在著大量的空白需要被填補，很多細節是客戶甚至是我都沒想到的狀況，因此在專案初期就要能訂出準確的開發時程，這基本上就只是在瞎猜，猜完後讓客戶安心而已，實作後發現時程超出預期，就必須要花更多心力爭取時間與預算。

因此我通常會回覆客戶說等專案進行了幾週後，再來確認是否有可能在他們希望的時間內完成，當開始執行後就會知道需要實作的細節以及可能會花比較多時間的工作項目在哪裡，進而討論這些工作項目是否要在該階段開發，如果這些項目都要完成，以小時數換算成工作天，再來估算最後完成日才是有依據的時程規劃。

但在實務經驗上，就我接觸過的公司來說，會嚴格遵守「預定上線時間」的客戶少之又少，大部分都是開案時講得十萬火急，然後開始執行後才發現到有許多不可控因素在影響專案時程，因此控制「工作事項」比控制「時間」來得重要。具體的說：

把焦點放在「解決客戶關鍵問題」的工作事項上。

今天一定要處理好，急件！

理解客戶的期待是在於「解決問題」而非一定要把所有工作做完後，就能讓自己從被時程追殺的壓力中釋放出來，但偶爾還是會接到客戶的緊急電話說這個東西今天一定要處理好，會有這樣的狀況有兩種可能性：

第一種是公司有重要的商業決策需要執行，而這決策因為外在環境的變動所以來得非常臨時且突然，接到這種需求下我會把目前手上正在進行的工作事項提醒客戶，說明本週預計執行的項目是否要延後，同時評估新功能需要的工作時數，先把具體的待辦清單列出來，就可以讓客戶清楚的了解開發這功能的步驟與項目。

因此客戶就會開始思考如果今天就要完成的話可以先做哪些他真正需要的，或是根據工作時數來推遲下決策的時間，譬如從一天變三天，也可以評估是否需要尋找其他外包廠商進行協助。

第二種可能性是公司內部在忙其他專案，很多功能已經開發完成但還沒驗收，然後某天老闆想到這個專案，就開始追 PM 專案進度，而 PM 可能當下也在忙別的專案，被老闆追殺後再來追殺外包廠商，這種情況下就會出現所謂的「緊急會議」。

每次參與這種會議壓力都很大，因為 PM 會在會議前把累積的待測試項目一口氣測完，然後一口氣把所有問題丟出來，看起來接案者好像沒做事一樣，通常這樣的下場就是壓時間，並要求在期限內全部修改完畢。

遇到這種情況我會擇期再約，一來當天手上都有既定的工作要完成，二來在會議前的這段時間，透過專案管理工具來提醒 PM 該驗收的項目，並請他們提出修改需求，讓專案可以重新動起來，動起來後召開的會議就比較能聚焦在解決問題上。

333 工作法的前提

這半年來我嘗試了很多，發現到不是所有類型的案子都適合自己的工作方法，像是一頁式需要快速完成切版或是大型專案要配合其他人員時程的案子我就無法承接，相反的，既有網站的功能修改、新創平台或是剛起步的網站開發比較適合我，而且看到因為我的協助而讓客戶的業績蒸蒸日上可以讓我從中得到成就感。

我的工作時間安排如下

1. 固定時段收信，把待處理事項安排時間處理。工作時不開任何通訊軟體、社群網站，聯繫管道只有電子郵件、專案管理工具與電話聯繫。
2. 切割工作時段，配合作息。開電腦時間為 09:00~19:00，一天兩班制，早上為 11:30~13:00，下午為 17:30~19:00，計時的工作時段就是專注解決待辦事項，其他零碎時間就能寫部落格、研究新技術、收發電子郵件以及上健身房運動。
3. 晚上下班後檢視本週的剩餘天數的工作安排，並把今日新收到與未完成的項目做分配，看是要安排在本週處理還是下週。
4. 細分工作項目，盡力讓每件事都能被追蹤，尤其是是在同一討論串提及的需求，要隨時整理成待辦事項，否則東西一多很容易漏掉。
5. 新增的每一項工作都要評估預計花費小時數，這關係到客戶的預算以及該功能有沒有辦法在預期內做出來的判斷標準，估越多才能越了解自己，越了解自己才能幫助客戶越準確的評估。

雖然工作方法很明確，但有時候還是會破了戒，像是晚上加班、一天工作十小時，所以我幫自己訂了以下的原則：

1. 不要接十萬火急的案子，這是加班的元兇，解法是試想接了這樣的案子會失去些什麼
2. 不要為了討好客戶隨口答應時間，這是我的老毛病，解法是仔細評估時間再回覆
3. 不要開當天才通知的會議，會被殺個措手不及，解方是一律回絕當天會議，另約時間
4. 需求確認後立刻寫進專案管理工具，不要等到累積很多再來整理
5. 卡了超過一小時的 Bug 就不要再繼續處理了，放下它，先改做其他事或是睡一覺，大腦會自動 Debug，屢試不爽

要維持這樣的工作型態，要有不害怕失去客戶的勇氣，這勇氣有些人可能是天生的，但也可以後天訓練得來的，像我就是後者，有時候下班後會不小心喵到需要修改的急件通知，或是明明是放假日，但有些功能還沒收尾，心裡都還是會很想開電腦去把它改完。

歸根就底，我很害怕因為客戶不滿意我的工作效率而不再與我合作，後來我告訴自己，如果客戶真的這麼在意專案進度，那麼他們應該是直接聘請工程師才能有效掌控時程，客戶選擇外包主要的目的還是在於解決問題，那麼只要在預計時間內解決，那些無法立即處理的急件就是公司本身的問題而非在我身上了。

最後就算真的因此失去客戶了，我反而能把時間花在創造其他收入來源的工作上，在下一篇文章中，我會介紹工程師接案的收入管理，該如何決定自己的價值，取決於你如何看待自己。

本文同步發表於：https://oberonlai.blog/tw/wordpress-freelance-practice-3/