工期估算：为什么「大概三天」永远变成三周

估算失准很少是因为「想得太乐观」，而是因为口径不一致：你估的是敲键盘的时间，别人理解的是交付时间。

被漏掉的那几段

一个功能真正占用的时间，除了写代码，还有：

环节	常被低估的原因
读代码、理解现有结构	「我熟」是假设，不是事实
联调	对方的接口还没好
评审后的修改	评审意见本身不可预测
测试与修 bug	只估了顺利路径
部署与验证	环境问题一次能耗掉半天

只报「写代码」的天数，等于默认后面几项为零。

把区间报出来，而不是一个数

「三天」传递的信息量是零。改成区间并说明依据：

2 到 5 天。
2 天：接口已就绪，现有代码能直接复用。
5 天：需要新增一张表，且要跟另一个团队联调。

区间不是含糊，是把不确定性说出来。只给单点数字的人，要么在赌，要么没想过风险。

拆到「半天以内」才有意义

超过两天的任务无法估算，因为它包含太多未知。拆成若干不超过半天的子项之后，估算误差会显著下降 —— 不是因为变准了，而是因为每一小步的未知变少了。

✗ 做用户导出功能（5 天）
✓ 后端加导出接口（1 天）
  前端加下载按钮（0.5 天）
  大文件分片（1 天，不确定）
  权限校验（0.5 天）

那条标了「不确定」的，就是该单独拿出来讨论的地方。

用历史数据校准

感觉永远不可靠。记下每次的实际耗时，下次估算时对照：

估计 2 天 → 实际 4 天
估计 1 天 → 实际 1.5 天
平均系数 ≈ 2

有十几条记录之后，你会发现自己有个稳定的偏差倍数。先承认它，再在估算里直接乘上去，比每次发誓「这次一定准」有用得多。

什么不该估

• 需求还没定清楚的功能 —— 先估「把需求问清楚」要多久
• 依赖外部团队排期的部分 —— 那是等待，不是工作量
• 自己没做过的技术方向 —— 先安排一次探针

第三条尤其重要：没做过的事不该给承诺，只该给「多久能知道能不能做」。

估不准不是能力问题，是信息问题。把未知拆小、把区间报出来、用历史校准，剩下的交给时间。