最近我做了一件有點瘋狂的事——把用了好幾年的任務管理系統砍掉重練。
不是因為原本的系統壞了，而是因為 AI 的崛起讓「時間」這個估算維度變得越來越不可靠。以前一個功能估 8 小時，現在可能 2 小時就搞定。以前一天能處理 3 個任務，現在可能處理 10 個。這種變化讓我開始思考：我們到底在估什麼？
傳統估算的崩壞
身為技術主管，我習慣用「這個要花多久」來安排工作。一個 API 2 小時，一個表單 4 小時，一個報表 6 小時。這套邏輯在過去很好用，因為 coding 時間是最大的瓶頸。
但現在不一樣了。
當我可以用 AI 輔助工具在 30 分鐘內生成一個完整的 CRUD 模組，「時間」這個維度就開始失真。更詭異的是，有些看起來很簡單的任務（「改個按鈕文字」），反而比複雜的開發任務更耗時——因為要釐清需求、確認設計、通知相關人員。
我發現自己越來越常遇到這種情況：
- 估 4 小時的功能，1 小時做完
- 估 1 小時的改動，搞了半天還沒收尾
這不是估算能力的問題，是估算維度錯了。
複雜度才是真正的成本
在反覆踩坑後，我決定換一個思考框架：不問「要花多久」，問「有多難」。
這個轉變聽起來微妙，但實際操作起來差很多。
「多久」是一個關於執行的問題——坐下來打字需要多少時間。
「多難」是一個關於認知的問題——這件事需要多少腦力、涉及多少不確定性、有多少外部依賴。
舉個例子：
任務 A：新增一個資料匯出功能
- 時間估算：4 小時
- 複雜度：低（明確的輸入輸出，套現有模式）
任務 B：調查某個偶發的效能問題
- 時間估算：2 小時（？）
- 複雜度：高（不確定原因，需要深入分析，可能牽連多個系統）
用時間估，任務 A 看起來比較重。但實際上任務 B 的認知負擔大得多，而且時間完全不可預測——可能 30 分鐘找到原因，也可能查了兩天還是一頭霧水。
我的新估算方式
現在我的任務估算改用類似敏捷開發的 Story Points，但做了一些個人化調整：
1-2 點：低複雜度
- 明確的需求
- 熟悉的技術
- 幾乎沒有外部依賴
- AI 可以直接生成大部分代碼
3-5 點：中複雜度
- 需要一些設計決策
- 可能涉及 2-3 個系統
- 需要釐清部分需求
- AI 能幫忙但需要調整
8-13 點：高複雜度
- 不確定性高
- 跨多個領域
- 需要與他人協調
- 可能有技術探索成分
21 點：研究型任務
- 完全不知道會遇到什麼
- 需要學習新技術
- 結果難以預測
這個分法的好處是：它承認了「不確定性」這個維度。
AI 時代的認知瓶頸
為什麼我要特別強調「認知負擔」？因為在 AI 時代，這才是真正的瓶頸。
以前的開發流程是：思考 20%，編碼 80%。
現在變成：思考 60%，編碼 20%，審核 AI 輸出 20%。
coding 時間被大幅壓縮了，但思考時間沒有。需求分析、架構設計、邊界條件、錯誤處理——這些還是需要人腦來處理。更甚者，因為 AI 可以快速產出大量代碼，我們反而需要花更多時間來審核、測試、整合。
這就是為什麼用「時間」估算會失準。一個高複雜度的任務，可能真正的 coding 只花 1 小時，但前後的思考、溝通、驗證加起來要半天。如果只估 coding 時間，會嚴重低估任務的真實成本。
團隊 vs 個人的雙軌制
這邊要特別說明：我只對自己的任務管理做這個調整。團隊協作上，我們還是維持時間導向的估算。
原因很務實：團隊需要可預測的交付時間。客戶問「這個什麼時候可以上線」，我不能回答「大概 8 個 story points」。
所以我的做法是雙軌並行：
- 個人任務：複雜度導向，幫助我安排每日工作優先序
- 團隊任務：時間導向，維持對外承諾的可預測性
這兩套系統服務不同目的。個人任務管理是為了優化我的認知資源分配；團隊任務估算是為了維持專案的可預測性。
實際操作心得
跑了幾天這套新系統，有一些觀察：
好的地方：
- 更容易判斷「今天能做幾件事」。以前是加時間，現在是加複雜度——8 點以內大概是合理的一天工作量。
- 對高複雜度任務的心理預期更準確。標了 13 點的任務，我就知道這需要一大塊專注時間，不會傻傻塞在會議空檔。
- 減少了「這應該很快」的錯估。很多看起來簡單的任務，複雜度一評估就知道沒那麼單純。
還在適應的地方：
- 有時候很難區分「3 點」和「5 點」。這需要累積經驗值。
- 回顧機制還沒建立。應該要追蹤預估 vs 實際的差異，持續校準。
給同樣在思考這問題的人
如果你也感覺傳統的時間估算越來越不準，可以試試這個思路：
先觀察：記錄一週，看看哪些任務的「預估時間」和「實際時間」差最多。通常是複雜度被低估的那些。
從個人開始：不需要改變團隊流程。先在自己的 todo list 試驗，看看複雜度思維是否有幫助。
擁抱不確定性：承認「我不知道這要多久」是一種進步。用複雜度來標記這種不確定性，比硬擠一個時間數字更誠實。
持續校準：任何估算系統都需要回饋迴圈。定期回顧，調整你的點數基準。
結語
AI 正在重塑軟體開發的每一個環節。當 coding 不再是瓶頸，我們需要重新思考：真正消耗的資源是什麼？
對我來說，答案是認知負擔和不確定性。而複雜度導向的估算，正是試圖捕捉這個維度。
這不是什麼革命性的發現——敏捷社群早就在討論 Story Points 的意義。但 AI 時代讓這個討論變得更迫切。當 AI 可以一秒鐘寫出一百行程式碼，「程式碼行數」或「coding 時間」已經無法代表任何東西了。
如果這篇能讓你開始思考自己的估算方式，那我的這番折騰就沒白費了。