估时：给任务留出被现实打断的空间
估时偏差通常不是能力问题，而是只算了顺利路径。用历史数据、拆分和缓冲来修正。
结论先行：估时的三步是：拆到小时级、参考同类任务的历史耗时、再加一段缓冲，覆盖沟通与返工。
这个两天能做完是工作中最常见的乐观判断。两天通常指顺利情况下的纯执行时间，不含等回复、改需求、开会和返工。结果到期未完成，看起来像执行力问题，实际是估时方法问题。
偏差从哪来
| 因素 | 影响 | 对策 |
|---|---|---|
| 只算执行 | 忽略沟通与等待 | 单独列出协作时间 |
| 假设一次通过 | 忽略评审与返工 | 按历史返工率加比例 |
| 任务太大 | 误差叠加 | 拆到半天以内再估 |
| 并行任务 | 切换损耗 | 同一时段只排一件 |
三个修正方法
- 查历史：同类任务上次实际花了多久，用实际值而不是记忆。
- 拆小再估：把任务拆到半天以内，逐项估，误差更容易控制。
- 加缓冲：在总和上加 20% 到 30%，用于沟通、等待和意外。
缓冲不是虚报。它对应的是真实发生但常被忽略的时间。把缓冲单独写出来，也方便他人在排期时理解你的时间构成，而不是把缓冲误当成可以随意压缩的余量。
怎么对外承诺
对外给时间时，给区间而不是单点，并说明前提：例如三天到四天，前提是需求在周一前冻结。前提被打破时，及时更新区间，而不是硬撑到截止日才说延期。越早更新，对方越有时间调整。
一次修正后的估时
从两天到两个工作日
- 原始估计：写接口文档，两天。
- 拆解：梳理字段 2 小时、写初稿 4 小时、评审 1 小时、按意见修改 3 小时。
- 历史参考：上次同类文档实际用了 12 小时，含两轮修改。
- 加缓冲 25%：约 15 小时，折合两个工作日。
- 承诺：两个工作日，前提是接口字段在开始前确认。
复盘自己的估时
每次任务结束后，记录预估与实际，并写一句偏差原因。积累十几次后，你会发现自己稳定的偏差比例，例如总是低估三成。下次估时按这个比例修正，比每次凭感觉更准。
自检清单
- 估时是否包含了沟通、评审和返工？
- 任务是否拆到了半天以内？
- 是否参考了同类任务的历史耗时？
- 对外承诺是否写明了前提和区间？
关于加急： 加急通常压缩的是等待和评审时间，不是执行时间。接受加急时，要同时确认哪些环节被跳过，以及由此带来的风险由谁承担。
估时是一种可以练习的技能。记录、对照、修正，几轮之后偏差会明显缩小，排期也会更从容。