心理・行為
Pro規劃謬誤檢查
Planning Fallacy Check · 出處: Daniel Kahneman / Amos Tversky
在做時間和資源估算時，對抗系統性過度樂觀的傾向
核心概念
人在估算未來計畫時，幾乎普遍地低估時間、成本和難度，同時高估完成的概率。這不是個人缺陷——是認知系統的內建偏誤。解藥是「外部視角」：不看這個計畫的內部細節，而是看類似計畫的實際結果統計。
✓ 適合在這些情境使用
估計專案完成時間、產品上線日、創業到獲利的距離時。人類系統性低估時間與成本——尤其當你對計畫充滿熱情時，更該強制套用這個檢查。
✗ 不適合用的情況
高度標準化、有可靠歷史時程的工作（生產線、套裝服務）不需要這個檢查。也不適合用來合理化過度悲觀——過度膨脹估計同樣有害。
引導問題預覽
使用這個框架時，你會被問到——
- 1.你的計畫或承諾是什麼？你對完成時間和成本的原始估算是多少？
- 2.你找到哪些類似計畫的歷史數據？它們的實際結果是什麼？
- 3.根據這些外部數據，更現實的估算應該是多少？
- …還有 3 個問題
填答範例
展開看一個假設情境填完後長什麼樣
›
填答範例
展開看一個假設情境填完後長什麼樣
情境
估自己「3 個月內把新產品 MVP 做完上線」，準備跟投資人 pitch 這個時程。團隊 4 人。
1. 你的計畫或承諾是什麼？你對完成時間和成本的原始估算是多少？
估 MVP 開發時間：3 個月。
2. 你找到哪些類似計畫的歷史數據？它們的實際結果是什麼？
我假設一切順利、團隊全速、沒有 spec 改動、無人請假、API 沒問題、QA 一次通過。
3. 根據這些外部數據，更現實的估算應該是多少？
過去 3 個 project 我估的時間：6 週/8 週/10 週，實際完成：12 週/14 週/18 週。平均偏差 70%。
4. 你的計畫中哪些環節最容易出現延誤或超支？
可能讓進度延後的具體原因：第三方 API 改版（過去 6 個月已經改 2 次）、QA 來回 2–3 輪、設計師會接其他案子、年中有 2 週連假。
5. 你打算如何調整計畫，以建立足夠的緩衝？
用外部視角校正：我抓 3 個月，歷史偏差 70%，意味實際大概 5 個月；加上具體可預見的延誤再 +0.5 個月，誠實估計約 5.5 個月。
6. 基於調整後的估算，這個計畫還值得繼續嗎？承諾是否需要重新談判？
對外承諾「6 個月內 MVP 上線」（含 buffer），對內目標 4.5 個月衝。寫下 milestone 在 2 個月時做 checkpoint。
在 ChatGPT / Claude 裡用
把下面這段貼進對話，AI 會逐題引導你跑完這個框架。
你現在是引導使用者做「規劃謬誤檢查」的教練（Kahneman / Tversky）。 依序問： 1) 你估的時程或預算是什麼？ 2) 你的估計假設了什麼順利情境？（坦白回答） 3) 過去類似 project 你估了多久、實際多久？平均偏差多少？ 4) 寫下至少 3 個可能讓進度延誤的具體原因——它們在過去 6–12 個月發生過嗎？ 5) 用歷史偏差比例校正：原估 × (1 + 平均偏差 %)，再加上可預見的具體延誤。 6) 你的修正版估計是什麼？對外承諾要不要再加 buffer？ 提醒：知道有規劃謬誤不會讓你免疫——必須強制用歷史資料校正。 互動規則： 1. 一次只問一題，等使用者回答後再進入下一題。 2. 使用者答完所有題目前，不要做總結或下結論。 3. 若答案太抽象、太籠統，請追問一次具體例子或數字後再繼續。 4. 全部答完後，輸出三段：(a) 摘要使用者的關鍵判斷；(b) 你看到的盲點或張力；(c) 一個具體下一步行動建議。 5. 不要替使用者做決定，只把判斷攤開讓他自己決定。
相關框架
常見偏誤
常見問題
規劃謬誤檢查跟基準率參照是什麼關係？
規劃謬誤檢查用的核心解藥，就是基準率參照／外部視角：不看這個計畫的內部細節，而是看「類似計畫實際花了多久、花了多少」。可以說它是 base rate forecasting 在「時間與成本估計」這個特定場景的專門應用。
我已經加了 buffer，還是超時，怎麼辦？
因為連你刻意給的「務實估計」都還是低估——研究反覆驗證這點。改用外部視角：直接以類似 project 的實際耗時為起點，而不是從你的內部估計往上加。並把專案拆成小段、各自獨立估計再加總；整體一起估，幾乎一定更樂觀。
buffer 到底該加多少？
預設加 50%；新領域或高度不確定的專案加 100%。更可靠的做法是用「校正係數」——統計你過去類似專案的「實際時間 ÷ 估計時間」比值，用那個比值來放大這次的估計，而不是憑感覺抓一個好聽的數字。
相關研磨誌