🎯 什麼情境該想到我
當你被問「這個功能要做多久？」，卻不知道怎麼給一個誠實又不害到自己的答案時。
⚙️ 怎麼用
- 估算是機率分佈，不是承諾：先講清楚「估算 ≠ 保證」，把不確定性攤開講。
- 三點估算（PERT）：給樂觀(O)、最可能(M)、悲觀(P) 三個值，期望值 ≈ (O + 4M + P) / 6，並算出範圍。
- 拆小再估：大任務拆成小塊分別估，加總比整體拍腦袋準。
- 用範圍/信心度溝通：「大約 5–8 天，八成把握」比單一數字誠實。
- 承諾與估算分開：估算是你的最佳判斷；承諾是你願意負責兌現的（見 工具-專業地說不與承諾）。
★ PERT 的數學：期望值與標準差
三點估算不只算期望值，還算不確定性的大小：
例：一個任務樂觀 2 天、最可能 3 天、悲觀 10 天。
- 天
- 天
注意期望值（4 天）比最可能值（3 天）大——因為悲觀的尾巴很長。這正是「最可能的時間」不該拿來當承諾的原因：軟體任務的延遲分布是右偏的，出錯時多花的時間遠多於順利時省下的時間。
★ 多個任務加總：不確定性會互相抵銷
幾個互相獨立的任務加總時：
- 期望值直接相加：
- 變異數相加（不是標準差）：
例：三個任務，每個 μ = 4 天、σ = 1.33 天。
- 總期望 = 12 天
- 總標準差 = 天（而不是 3 × 1.33 = 4 天）
所以「拆小再估」有數學上的理由：拆得越細，整體的相對不確定性越小（大數法則）。但前提是任務真的互相獨立——如果它們共用同一個風險（例如都依賴一個還沒釐清的 API），不確定性不會抵銷。
★ 用機率溝通，而不是單一數字
假設總時間近似常態分布：
| 說法 | 計算 | 例（μ = 12、σ = 2.3） |
|---|---|---|
| 「一半機會能完成」 | μ | 12 天 |
| 「八成把握」 | μ + 0.84σ | 約 14 天 |
| 「九成五把握」 | μ + 1.65σ | 約 16 天 |
對方要承諾日期時，給「九成把握是 15 天」比「12 天」誠實得多——後者只有一半的機會做到。
★ 團隊估算的方法
| 方法 | 做法 | 解決什麼問題 |
|---|---|---|
| 寬頻德菲法（Wideband Delphi） | 每人各自估，再公開、討論差異、再估一輪，直到收斂 | 避免被第一個開口的人或資深者錨定 |
| 規劃撲克 | 德菲法的快速版：同時亮牌，差異大的兩人說明理由 | 同上，而且快 |
| 親和估算 | 不估數字，先把任務依相對大小排序，再分組 | 人對「比較」比對「絕對數字」準 |
最有價值的是差異本身：一個人估 2 天、另一個估 10 天，通常代表兩人對任務的理解不同——討論出來的往往是被遺漏的需求或風險。
★ 校準：拿過去的資料修正
記錄每個任務的估算與實際時間。一段時間後算出實際 ÷ 估算的比例：
- 比例穩定在 1.5 → 你系統性地低估 50%，之後的估算直接乘 1.5。
- 比例變異很大 → 問題不是偏差，而是任務拆得不夠細、或需求不穩定。
🧪 我實際套用的紀錄
- 2026-07-15：（待填）
⚠️ 注意
- 被逼給「一個數字」時，別把樂觀估算當承諾——那是延遲與加班的起點。
🔗 相關工具
- 工具-專業地說不與承諾、工具-時間複雜度分析（成本估算的另一面）