一天四小時工作術

專案成果是否能滿足客戶的期望，關鍵不是在客戶希望的時間內完成所有的任務，而是在這段期間內能否解決客戶最在意的問題，只要客戶最痛的問題處理好了，剩下的工作縱使沒有在預期時間內完成也沒關係，只要安排好後續的執行時間並且傳達給客戶知道，這樣就能擺脫每天被死線追殺的苦逼人生了…

自從改變自己的工作模式後已經過了半年的時間，這六個月的案量還算穩定 (感謝各位信任我的朋友)，現在手頭上的狀態是每天有計時的工作時數大概是四個小時左右，並且同時有四個案子在同步執行中。

「一天只做四個小時卻能同時接案四個案子!?」

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

現在回過頭來看待以前的自己覺得好不可思議，每天忙得跟狗一樣卻沒什麼成就感，心情又很容易受到客戶意見的影響，尤其是做好的功能又說要改，規格一變動工時的爆增就無法避免。因此想把自己這半年來的轉變記錄下來，同時也提醒自己絕對別再走回頭路。

每日的風景

這個專案要多久？

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

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

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

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

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

月底一定要準時上線！

現在，如果客戶希望某項功能可以在某個日期前完成，我絕對不敢答應日期，取而代之的是我會用工作事項來評估加總工作小時，然後根據最近的時間安排來確認該功能在一個工作天之中我能花多久時間來處理，譬如說如果總工時我評估需要 10 個小時，而我現在每天可以分配兩個小時來做它，那麼至少需要五個工作天。

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

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

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

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

今天要處理好喔，再麻煩了!

理解客戶的期待是在於「解決問題」而非準時交出為了趕上線而寫得亂七八糟的程式碼後，就能從被時程追殺的壓力中釋放出來，至於會接到客戶的緊急電話說這個東西今天一定要處理好，有兩種可能性：

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

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

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

每次參與這種會議壓力都很大，因為 PM 會在會議前把累積的待測試項目一口氣測完，然後測試有問題就會被挑戰，或是成品跟他們的認知有所落差，最後結論就是壓時間，要在期限內全部修改完畢。

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

四小時工作法的前提

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

我的工作方法如下：

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

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

不要接十萬火急的案子，這是加班的元兇，解法是試想接了這樣的案子會失去些什麼
不要為了討好客戶隨口答應時間，這是我的老毛病，解法是仔細評估時間再回覆
不要開當天才通知的會議，會被殺個措手不及，解方是一律回絕當天會議，另約時間
需求確認後立刻寫進專案管理工具，不要等到累積很多再來整理

我的專案管理工具

當每個任務都要拆分成很細的時候，就免不了會有非常多瑣碎的項目，再加上同時有多個案件在進行的話，很容易就會漏掉或是沒有跟進到，長久累積下來就會造成溝通的落差，所以好的遠端非同步協作專案管理工具就非常重要。

我選擇使用 Ora，當初會找到它是因為我需要一套可以用行事曆來管理待辦事項的工具，後來接觸更多看板管理方法後，才發現 Ora 能滿足我的需求，於是就一直用下去了。

當有新專案時我的流程是這樣：

在 Ora 新增 Project 並套用根據自己工作流程所設計的範本

邀請客戶加入該專案

預設範本我設定六個 Board

衝刺工作項目：我會把案件開始前評估的工作項目加到這邊，如果之後有新增任何需求也都會直接寫在這個 Board，在加入 Task 的同時也會把預估時數加進去，在執行時就能確保時數用量。

預備 – 分析及文件製作：這裡面的項目會從衝刺工作項目拉進來，分配接下來準備要做的工作，Board 名稱有 (2)，代表的是 WIP（ Work In Progress ），意思是這個 Board 最多只能放兩個 Task，再多的話就要排隊或是插隊了。

開發 – 進行中：確認要做的工作後，我就會把 Task 拉到這邊，並且開始計時，同樣的後面也有 (2)，也就是如果進行中的工作超過兩項，剩下的就要排隊了。

開發 – 完成：當 Task 完成後我會停止計時，由於大部分時候我都在本機開發，所以在還沒部署到測試機上的項目我會先放在這邊，等到累積到一定數量或是完整的功能都完成時才會進行部署。

測試(1)：這邊放已經部署到測試機的完成項目，也是需要請客戶驗收的項目，確認沒問題後就可以打勾，即代表該項目製作完成，如果有問題可以透過下方的留言區進行討論，並確認花費時數，如果有需要修改的地方，那麼這個 Task 就會回到預備的 Board，如果留言中有提到新的需求，再把它獨立成新的 Task。