先記住：估時要拆交付物、依賴與未知。
需要深入時：再做 WBS 與風險紀錄。

「以為只是串個 API」

假設你估優惠券功能一天，實際花了三天。

回頭看，不是三天都在寫函式：
你等了規格、確認錯誤碼、調整狀態，最後還補了回應亂序的處理。
把這些都叫「雜事」，然後下一次還是會漏估。

WBS，也就是工作分解結構，對我比較實用的理解是：
把交付成果拆到能知道什麼叫完成，別再簡單寫只是「前端開發」。

從交付物往下拆

這裡用純示例數字：

• 需求與規則確認：2 小時，產出可驗收的流程。
• 表單與互動：3 小時，包含 Loading、錯誤與鍵盤操作。
• API 與資料轉換：3 小時，確認合法資料及異常資料。
• 狀態與競態處理：2 小時，確保舊回應不覆蓋新資料。
• 驗證與修正：3 小時，完成關鍵情境與整合檢查。

基礎工作量是 13 小時。
但是卻比「這大概兩天完成」更有用，因為團隊知道刪除某項行為會少掉什麼，也知道哪一段正在等待依賴。

風險不能只乘一個神祕數字

如果 API 已確認，可以用較窄的區間；如果錯誤格式還在改，區間就應放大。
風險係數只是表達不確定性的工具。

我自己偏好逐項標記：

• 已知工作 13 小時
• 錯誤契約變更可能追加 2～4 小時
• 實機確認可能追加 1～2 小時。

總量先表達為 16～19 小時，並說明數字建立在哪些條件上。

同一個風險不要先加緩衝又再乘係數，否則重複計算。
相反地，外部 API 下週才交付也不能只多算兩小時：那是時程依賴，會影響日曆上的完成日期。

遇到未知，先確認資訊

如果完全不知道套券是否會鎖定庫存，硬估三天或五天都沒幫助。
可以先排一個有時間上限的探索工作，例如兩小時內完成契約確認和一個最小請求。
探索結束的成果不一定是程式，可能是「確認這支操作有副作用，因此不能任意重試」。

這個資訊會改變設計與估算，但也比事後修事故花 Token 划算。

而且估時也不是承諾永遠不變。
當範圍新增多券疊加，應記錄新增工作與影響，重新估算，記得可別默默吸收。

可以交給 AI 的 Prompt

請將優惠券功能拆成可交付的 WBS，包含規格確認、UI、資料轉換、狀態、錯誤及驗證。每項寫完成條件、依賴與估算假設。請使用區間，不要宣稱精準工時；未知契約先提出限時探索。避免把同一風險同時算進緩衝和係數。以下是已確認規則：一次一張券，伺服器回傳報價，使用者可在送出後修改數量。

不過 AI 的分解結果適合當初稿；工時還要根據團隊熟悉度、既有元件與歷史紀錄校正。

今日練習與筆記

拿最近一個超時任務，把實際投入分成建置、溝通、等待和返工。
找出當初沒有列進去的兩項，下次放回 WBS。
好的估時不會讓不確定性消失，但能讓團隊知道不確定性在哪。

然後下一篇再討論更常見的狀況：API 沒出來，前端可以先做什麼？