以時數評估的方式來報價，最大的好處是可以大幅減少專案從接洽到真正啟動之間的時間，這段時間越長，對於接案者現金流的風險越大，因為在等待簽約的過程中，你不知道是否該繼續談新案子，萬一談了，有可能會超出自己的工作負荷量，如果沒去談，原本正在談的案子萬一沒成交這個月就要喝西北風了。

有接案者為了維持現金流，只要有新案子就一律都去談，為的就是能夠先拿到案子的訂金來撐過這個月的開銷，然而手上累積一堆案子做不完，只好再外包或是開始請人，於是每個月的開銷又變得更高，只好再去接更多案子，這樣很容易讓開發品質下降。

透過時數評估方法，依照過去的經驗平均可以在一週之內決定是否要啟動專案，因為當任務被有效拆解後，對決策者來說資訊透明能更快的下決策，因此如何快速的有效拆解客戶需求以作出評估是很關鍵的一環。

拆解的方法首先是區分開發性質，WordPress 外掛開發的工作不外乎前台資料的 Query、後台設定頁面、取得或傳送資料給外部服務，以及資料的寫入，只要掌握這幾種性質就能知道該如何列出工作項目，像是以開發金流為例，需要把訂單資料傳送給金流商，再將金流商回傳的資料寫入資料庫，最後在結帳頁顯示對應的交易結果。不同的付款方式都會有類似的流程，所以就能根據付款方式詳列出需要開發的步驟。

其次，拆解的項目中應該也要包含確認完成標準與測試除錯的時間。

確認完成標準指的是對客戶來說這個工作怎樣算是完成，重點在於站在客戶的立場，而非自認為把程式寫完就算完成。通常我會用使用者故事 ( User Story ) 來描述客戶的需求，描述的基本公式為：身為 ( 某種使用者 )，我可以 ( 進行某種操作 )，以達到 ( 某種目標 )，再以開發金流外掛為例：

• 身為顧客，我可以在結帳時選擇 A 金流商的信用卡付款來完成結帳
• 身為顧客，我可以在刷卡完成後看到交易結果，以確保有正確的完成付款
• 身為管理者，我可以在顧客刷卡時收到電子郵件通知，以確保交易過程正常
• 身為管理者，我可以在後台訂單管理看到顧客的刷卡方式，以作為後續管理之用

當列出這些故事以後，客戶可以完整的看到他的需求的各種面向，尤其是不同使用者之間的操作行為是為了要達成什麼目標，進而思考還有沒有什麼情境是沒有被考慮到。像是顧客身份有可能會區分為已註冊或未註冊顧客、VIP 與 VVIP 顧客，或是購買不同類型的商品會對應到不同的金流結帳方式，這些可能都是客戶沒有想到的地方。

因此在確認完成標準的這個環節，我就會開始計時作為專案正式啟動的第一步驟，不管專案大或小，一定要請客戶確認完成標準，因為當討論下去之後，可能會發現原本評估的 A 項目不需執行，反而還多增加了 B 跟 C，這都會影響實際開發的時數。

例外一個必要的工作項目就是測試與除錯的時間，我會把這個時間拿來寫單元測試，或是把一些外掛的核心功能用自動化腳本定期執行，藉此來確保外掛能正常運作，但要跟客戶溝通清楚這邊的測試與除錯只限於開發中的狀況，等到開發完成上線後發生的臭蟲，會需要另外花時間處理。

因為使用者總是可以用我們從沒想過的方式來進行操作，或是使用的裝置以及環境問題導致了某種例外狀況，這些問題都是我們要一起與客戶學習並經歷的過程，尤其是在 WordPress 這種龐大又錯綜複雜的環境下，可能只要更新某一支外掛就能造成例外錯誤。

當我們花了很多時間評估時數、確認完成標準，跟客戶反覆溝通實際要執行的項目，但永遠要記住，真實世界充滿了無數的變數。

我遇過實際開工後，執行了三分之一時，發現到這個功能的邏輯並非我想像的這麼單純，通常 WordPress 只要找對關鍵字就能得到很多現成的答案，再來東拼西湊就能完成，但找不到解決方案就要自己設計，所以會多很多步驟。

如果距離該項目的剩餘可用時數不到一小時，而我預計可能需要再兩個小時，那麼就要趕緊回報客戶目前手邊遇到的困難，並且解釋需要這兩小時來做哪些項目，讓客戶理解狀況以進行評估，如果客戶不能接受，那就要思考出變通的方法或是先擱置這個項目，等之後有預算再來進行。

另一種情況是客戶所在的商業環境產生變化，可能昨天討論的使用者故事需要新增或修改，這時候就需要再回到確認完成驗收標準的階段，整理出使用者故事後再次拆解任務。總之，任務拆解是動態的，不是拆完後就固定在那邊了，重點是要能夠讓客戶理解做這件事需要的步驟與時間即可，隨時調整是敏捷式接案的常態。

把任務拆解完成之後，接下來進入實作階段，下一篇我會介紹最重要的計時工具以及看板方法。

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