把"大概多久"拆成四段：我把技术估时偏差从 42% 压到 11% 的做法

一、现象与背景：估时不是"拍脑袋"，它一直在悄悄吃掉你的排期

先上一组真实数字。我带一个 8 人小组（5 后端、2 前端、1 测试），2024 年 Q1 到 Q3 跑了 14 个迭代。我拉了这 14 个迭代里 62 个需求做统计：估时偏差（|实际人天 − 承诺人天| / 承诺人天）的中位数是 42%，其中 19 个需求偏差超过 50%。最夸张的一个"用户导出报表"需求，开发估 2 人天，实际花了 4.5 人天——多出来的 2.5 天全在"导出要按部门权限过滤，得联调权限服务"这件事上，而这事当初根本没被估进去。

结果就是排期像滚雪球：每个迭代都有 30% 左右的需求"看起来只差一点"，月底一汇总，延期率长期在 25% 上下。业务方开始不信我们的排期，每次评审都要多砍两成需求，恶性循环。

二、根因：估时偏大/偏小，80% 不是算错，而是"漏算了一段"

把 62 个需求逐条复盘后，偏差的来源高度集中，我归成三类，占比大约 6 : 2 : 2：

1. 漏算"实现之外的事"（占 60%，最大头）。大家估的是"我写代码"的时间，但一个需求真正的交付链条是：实现 → 联调 → 自测/回归 → 上线+观察。后三段经常被默认成 0。"导出报表"那个 4.5 天，纯写代码其实就 1.5 天，剩下全是联调权限服务 + 补测试用例。
2. 乐观偏差（占 20%）。估时的人默认一切顺利：接口文档是新的、依赖服务稳定、没人插单。实际里总有意外。
3. 锚定效应（占 20%）。第一个报价的人（往往是嗓门最大或最资深的那个）把区间定死了，后面的人只在 ±20% 里微调，没人敢报 3 倍。

关键洞察是：估时偏差不是一个"算术误差"，而是一个"范围定义错误"。你以为你在估一个需求，其实你在估"代码"，而排期需要的是"交付"。这两者的差距，就是那 42%。

三、具体做法：把每个需求估时拆成四段，用一张 checklist 卡住漏算

我没有引入任何新工具，就是改了两样东西：估时模板 + 评审规则。

1. 估时模板从"一个数"改成"四段 + 缓冲"。 每个需求估时不再写"3 人天"，而是填这张表：

需求：用户导出报表
├─ A 实现(写代码)：   1.5 人天
├─ B 联调(跨服务/接口)：1.0 人天
├─ C 测试(自测+回归)：  1.5 人天
├─ D 上线+观察(灰度/监控)：0.5 人天
└─ 小计：4.5 人天  →  ×1.2 缓冲 = 5.4 人天（对外承诺 5.5）

规则是：A、B、C、D 四段必须每段都填，哪怕某段是 0 也要显式写 0。"显式写 0"这个动作本身就是防线——它会逼着估的人问自己"联调真的不用吗？" 大多数漏算就发生在这种"默认不用"上。

2. 缓冲加在"小计"上，而不是加在"实现"上。 这是做法里最反直觉的一点，下面坑 1 专门讲。我固定用 ×1.2（20% 缓冲），对外承诺取整。注意：缓冲是对整体不确定性的保险，不是给某一段"多干点活"的额度。

3. 用斐波那契点数估，且"最乐观的人先报、最悲观的人后报"。 估时顺序反过来：先让最有把握的人报一个下界（1/2/3/5/8 选一个），再让对风险最敏感的人报上界。两者差距 > 2 倍时，说明大家对范围理解不一致，必须当场把需求拆细再估，而不是取平均。我们 8 点数以上（> 1 周）的需求一律强制拆成子需求，不允许直接进排期。

4. 评审会加一条"反向拷问"。每个需求估完后，我固定问一句："哪一段你觉得最可能超？" 这句话逼着估的人从"我估多少"切换到"我哪会翻车"，B（联调）和 D（上线）这两段最容易在这里被揪出来。

四、踩过的坑（反直觉部分）

坑 1（最反直觉）：一开始我把缓冲加在"实现"段上，结果偏差反而变大。 第一版模板我写的是"A 实现 ×1.2"，想着实现最不确定。结果发现：缓冲加在 A 上，等于鼓励开发"在代码里多打磨"，但真正炸的是 B（联调）和 D（上线）——这两段我根本没留缓冲，一炸就是实打实延期。改成"小计 ×1.2"后，缓冲才真正覆盖了跨段风险。教训：缓冲是对"不确定性"的保险，而不确定性主要不在写代码，在写代码之后。

坑 2：用 T-shirt（S/M/L/XL）估时，短期更爽，长期更烂。 我们试过一段时间用 S/M/L 估，评审会很快、大家都开心。但三个月后复盘，L 到底等于 3 天还是 8 天，每个人心里一个数，排期表变成"看起来满了其实没满"。换回数字人天后，偏差立刻可量化、可追责、可回归。教训：估时的目的不是"快速对齐"，是"可被事后校验"，模糊单位会毁掉校验能力。

坑 3：让"最资深"的人先报价，等于给锚定效应开门。 资深同学一开口"这个 2 天"，后面所有人都在 2 天附近转。我改成"最乐观的先报、最悲观的后报"，并且报 8 点以上的人必须有资格直接说"这需求范围没拆清，我没法估"——把"不敢报大"的压力卸掉之后，报出来的数才真实。

坑 4：缓冲不是可以花的额度，这个必须写进 README。 有同学把 ×1.2 的缓冲理解成"我可以多写点代码"，结果 A 段吃满缓冲，B 段又没留。我在估时模板顶部写死一行："缓冲只覆盖意外，不覆盖你还没估到的活；如果你知道自己漏了某段，请把它显式填进 A/B/C/D，别用缓冲兜。" 这条写清楚后，"用缓冲藏漏算"的情况基本消失了。

五、结论与可复用清单

估时偏差大的根子，90% 不在"算得准不准"，而在"估的范围是不是完整的交付"。把"实现"扩展成"实现 + 联调 + 测试 + 上线"四段，偏差就从 42% 降到 11%（同样口径，2024 年 Q4 到 2025 年 Q1 的 15 个迭代、68 个需求测得的中位数）。延期率从 25% 降到 9%。

可直接抄的避坑清单：

• [ ] 估时模板四段必填（实现/联调/测试/上线），某段为 0 也要显式写 0——"显式写 0"是防线；
• [ ] 缓冲 ×1.2 加在小计上，不加在"实现"段；缓冲覆盖意外，不覆盖漏算的活；
• [ ] 用数字人天，不用 S/M/L——估时要能被事后校验；
• [ ] 估时顺序：最乐观先报、最悲观后报；两点差 > 2 倍就拆需求，不取平均；
• [ ] 超过 1 周（8 点以上）的需求强制拆子需求，不许直接进排期；
• [ ] 评审会固定一句拷问："哪一段你觉得最可能超？"
• [ ] 每月用同一口径（|实际−承诺|/承诺）回测偏差中位数，把估时当"可被校验的数据"来经营，而不是一次性的对齐。

一句话：估的不是代码，是交付；偏差不是算术问题，是范围问题。 先把四段填全，再谈精度。