結論先講
工時估算不是算命，是風險管理。你不需要估得準（也不可能），你需要的是：(1) 讓團隊對工作量有共識 (2) 讓利害關係人知道不確定性有多大 (3) 用歷史數據不斷校準。別再跟 PM 說「大概兩天」然後做了兩週——這篇教你怎麼估得合理、溝通得體面。
為什麼我們永遠低估
1. 樂觀偏誤（Optimism Bias）
人類天生樂觀。當你聽到「做一個登入功能」，你腦中想的是最順利的路徑：寫個表單、打個 API、存個 token，完成。
你沒想到的：
- OAuth 整合要先申請 API key，等審核要三天
- 密碼規則要跟資安確認
- 忘記密碼流程、email 驗證
- Session 管理、token refresh
- 前端表單驗證、錯誤訊息
- 跨裝置測試
- Code review 來回修改
2. 忽略「看不見的時間」
工程師估的通常是「純寫 code」的時間。但實際上：
| 活動 | 佔比 |
|---|---|
| 理解需求、問問題 | 10-15% |
| 寫 code | 30-40% |
| 寫測試 | 15-20% |
| Debug | 10-15% |
| Code Review（自己改 + review 別人） | 10-15% |
| 開會、溝通、等待 | 10-15% |
你以為你一天有 8 小時寫 code，實際上能專注寫 code 的時間大概 4-5 小時。
3. Unknown Unknowns
你不知道你不知道的東西。第三方 API 文件寫的跟實際行為不一樣、某個套件升級後有 breaking change、staging 環境的設定跟 production 不同——這些都是你在估算時不可能知道的。
Story Points vs 時數
這是永恆的辯論。先講結論：兩個都有用，看場景。
| Story Points | 時數 | |
|---|---|---|
| 衡量什麼 | 相對複雜度 | 絕對時間 |
| 適合場景 | Sprint planning、跨 sprint 比較 | 客戶報價、deadline 承諾 |
| 優點 | 不受個人能力影響、避免「你說兩天就兩天」的壓力 | 直觀、利害關係人聽得懂 |
| 缺點 | 新團隊很難校準、外行人聽不懂 | 容易變成 deadline 壓力、忽略複雜度差異 |
Story Points 怎麼用
用 Fibonacci 數列：1, 2, 3, 5, 8, 13, 21
- 1 SP：改一個按鈕文字、加一個環境變數
- 2 SP：加一個簡單的 CRUD endpoint
- 3 SP：有一些邏輯的功能，像是表單驗證
- 5 SP：跨前後端的完整功能
- 8 SP：需要串接外部服務或做複雜計算
- 13 SP：需要架構設計或技術探索
- 21 SP：太大了，該拆
重點是「相對比較」。如果上次那個串接金流是 8 SP，這次的串接物流跟它差不多複雜，那也是 8 SP。
Planning Poker 實戰
Planning Poker 不只是投票，是逼團隊把隱性知識說出來。
流程
- PM 念 User Story 和 Acceptance Criteria
- 團隊問問題（限時 5 分鐘）
- 每個人同時出牌（Fibonacci 數字）
- 如果差異在 2 以內（例如 3 和 5），取大的
- 如果差異大（例如 2 和 13），讓最高和最低的人解釋
- 再投一次
- 最多投三次，還沒共識就取中位數
為什麼差異本身有價值
最有價值的時刻是出現巨大差異的時候。
小明出 3：「不就是加一個欄位嗎？」 小華出 13：「你知道這要改 schema 然後跑 migration 吧？還要更新三個 API 的 response。」
這個對話本身比最後的數字更重要——它暴露了理解差異和潛在風險。
T-shirt Sizing：粗估的好朋友
在專案早期，你連需求都不清楚，算 SP 太精確了。這時候用 T-shirt sizing：
| Size | 說明 | 大約時間 |
|---|---|---|
| XS | 改設定、改文字 | < 半天 |
| S | 簡單功能、小修改 | 1-2 天 |
| M | 標準功能開發 | 3-5 天 |
| L | 跨系統整合 | 1-2 週 |
| XL | 新模組或架構變更 | 2-4 週 |
| XXL | 需要先拆才能估 | 不要估，先拆 |
T-shirt sizing 適合用在：
- Roadmap 規劃
- 新專案的初步評估
- 跟業務部門溝通粗估
Cone of Uncertainty
專案越早期，估算的誤差越大。這叫做 Cone of Uncertainty（不確定性錐）：
| 專案階段 | 估算誤差 |
|---|---|
| 初始概念 | 0.25x - 4x |
| 需求確認後 | 0.5x - 2x |
| 設計完成後 | 0.67x - 1.5x |
| 開發進行中 | 0.8x - 1.25x |
意思是：在專案初期你估 1 個月，實際可能是 1 週到 4 個月。不是你估得爛，是這個階段本來就不可能估準。
怎麼跟 PM 溝通
別說「要一個月」，說：
「根據目前的資訊，我的估算是 3-6 週。等需求確認後，我可以把範圍縮小到正負兩天。」
給一個範圍，而不是一個數字。這才是專業。
Buffer 策略
經驗法則
- 你有做過類似的：加 20% buffer
- 你沒做過但技術熟悉：加 30-50% buffer
- 全新技術或外部依賴：加 50-100% buffer
怎麼加 Buffer 不會被砍
不要說「我加了 buffer」。把 buffer 變成具體的項目：
| 原始估算 | Buffer 項目化 |
|---|---|
| 「功能開發 5 天，我加 2 天 buffer」 | 「功能開發 5 天 + 整合測試 1 天 + Code Review 修改 1 天」 |
把 buffer 拆成看得見的工作，PM 就砍不掉了。
用歷史 Velocity 校準
Velocity 是團隊每個 sprint 完成的 SP 數。追蹤三個 sprint 以上就有參考價值。
範例
| Sprint | 承諾 SP | 完成 SP |
|---|---|---|
| Sprint 1 | 30 | 22 |
| Sprint 2 | 28 | 25 |
| Sprint 3 | 25 | 24 |
| Sprint 4 | 25 | 26 |
平均 velocity：24 SP / sprint
下一個 sprint 就承諾 24 SP 左右，不要好高騖遠。
注意事項
- Velocity 是「描述」不是「目標」——不要把它當 KPI 來逼
- 不同團隊的 SP 不能互相比較
- 成員異動、技術棧變更都會影響 velocity
什麼時候該說「我估不了」
有些情況下，誠實說「我現在無法估算」比亂估一個數字好得多：
- 需求不明確：「你說的『推薦系統』是指什麼？規則型的還是 ML 的？」
- 技術未知：「我沒用過這個第三方服務，需要先做 spike（技術調研）」
- 依賴未確認：「這需要等設計稿，沒有設計稿我不知道前端工時」
Spike 的概念
Spike 是一個時間限定的技術調研。例如：
「我花兩天做一個 spike，驗證金流 SDK 能不能支援我們的需求。spike 結束後我再估整個功能的工時。」
這比亂猜「大概兩週」然後做到一半發現 SDK 不支援要好太多了。
估算溝通模板
當 PM 問「這個要多久」，用這個模板回答：
功能：[簡述] 估算範圍：[樂觀] - [悲觀]（最可能 [中間值]） 前提假設：
- [假設 1]
- [假設 2] 風險：
- [風險 1]：如果發生，可能增加 [時間] 需要確認：
- [問題 1]
- [問題 2]
範例
功能：信用卡付款 估算範圍：3-7 天（最可能 5 天） 前提假設：
- 使用綠界 SDK，不做自建金流
- 設計稿在本週五前提供 風險：
- 綠界測試環境不穩定，可能增加 1-2 天 需要確認：
- 要不要支援分期付款？
- 退款流程是否包含在這個版本？
FAQ
Q1：Story Points 到底要不要對應到時間？
理論上不要，因為 SP 衡量的是複雜度，不是時間。但實務上，大多數團隊心裡都有一個隱性的對應（例如 1 SP ≈ 半天）。這沒問題，只要別把它公開變成承諾。SP 的價值在於「相對比較」和「追蹤 velocity」，不是精確到小時。
Q2：PM 一直砍我的估算怎麼辦？
先問為什麼砍。如果是因為 deadline 壓力，那要討論的是 scope（砍功能），不是壓縮工時。如果是因為覺得你估太高，把估算拆開來看——哪個部分他覺得太高？用具體的項目來討論，而不是爭論一個總數。
Q3：估算會越來越準嗎？
對同類型的工作會。如果你的團隊一直在做 CRUD 功能，估算會越來越準。但如果每個 sprint 都在做全新的東西，估算就永遠不會太準——這時候更重要的是管理不確定性，而不是追求精確。
Q4：遠端團隊怎麼做 Planning Poker？
用線上工具：Scrumpoker.online、PlanITpoker 或 Linear 內建的估算功能都行。重點不是工具，是「同時出牌」這個機制——避免錨定效應（第一個出價的人影響其他人）。
Q5：接案的時候怎麼報價？
接案報價跟內部估算不一樣。接案要加更多 buffer（50-100%），因為需求變更的風險更高。建議用時數估算乘以時薪，再加上「溝通成本」（通常是開發時間的 20-30%）。永遠不要報一個 fixed price 給不確定的需求——改用分階段報價。