估算为什么总是偏乐观

几乎每个团队都经历过这样的场景：会上拍了一个工期，临到交付才发现做不完，于是加班、压缩测试，把技术债留给下一次迭代。问题往往不在执行力，而在估算本身缺乏依据。

估算偏乐观有几个稳定的来源：一是只算了顺利路径，忽略了联调、评审、等待与返工；二是把工时当成了可用时间，忘了开会、答疑和临时插入的任务；三是没有为不确定性留缓冲，把所有变数都当成不会发生。

估算不是预测未来的能力，而是在信息不足时做出一个可讨论、可修正的判断。

承认这一点，就会自然地接受两件事：估算需要方法而不是直觉，进度需要缓冲而不是满打满算。

本文核心知识点
  • 故事点用相对大小代替绝对工时，避免陷入无谓的精度争论。
  • 三点估算用乐观、最可能、悲观三个值给不确定性留出空间。
  • 计划扑克让团队独立估值后同时亮牌，把分歧暴露在讨论中。
  • 关键路径找出决定总工期的那条链，缓冲加在链的末端更安全。
  • 风险登记册把风险写成可跟踪的条目，而不是留在某个人脑子里。
项目估算示意：深蓝到亮蓝渐变背景上由发光里程碑方块串联的波形路径、中央悬浮的抽象天平与右下角的半透明风险网格组成的扁平插画
估算与风险是一体两面：先承认不确定，再把它拆成可管理的条目。

从故事点到三点估算

估算要落到具体产物上。团队常用的两把尺子：故事点衡量相对规模，时间衡量真实工期。故事点不做绝对换算，只回答「这个需求比那个大多少」，这样就能绕开「到底是三天还是四天」这类没有答案的争论。

当需要给出工期区间时，可以用三点估算：分别给出乐观值、最可能值与悲观值，再按经验公式合成一个期望值。下面的示例说明它的用法。

# 三点估算示例：单个任务的期望工期
乐观值   O = 2 天    # 一切顺利，无阻塞
最可能值 M = 4 天    # 常规情况
悲观值   P = 10 天   # 联调受阻、依赖延期

# 常用加权公式（PERT）
期望值 = (O + 4 * M + P) / 6 = (2 + 16 + 10) / 6 ≈ 4.7 天
标准差 = (P - O) / 6 = (10 - 2) / 6 ≈ 1.3 天

# 结论：把这个任务按约 5 天安排，
# 并为「可能变成 10 天」的下行风险预留缓冲。

三点估算的价值不在公式，而在逼团队讨论悲观值。当有人说「这次可能要十天」，讨论就自然转向了风险：是什么让它变成十天，能不能提前消除。

计划扑克：让分歧浮出水面

估算是群体活动，最容易失效的方式是「谁声音大听谁的」。计划扑克用一个简单规则解决这个问题：每人独立估值，然后同时亮牌，出现明显分歧时，让最高与最低的人各自说明理由。

  • 避免锚定：先亮牌再讨论，防止先发言的人影响其他成员的判断。
  • 暴露假设：分歧往往来自对需求的不同理解，讨论过程就是在对齐假设。
  • 控制成本：每个需求只讨论到「足够接近」即可，不追求精确一致。

有经验的团队会把扑克估值控制在很短时间内。如果某个需求反复估不出来，通常不是估值方法的问题，而是需求本身还没想清楚——此时应该回去拆需求，而不是继续争论数字。

进度基线：关键路径与缓冲

逐条估完只得到一堆数字，还需要把它们排出先后关系，才能得到项目工期。方法很直接：画出任务之间的依赖，找出关键路径——那条决定总工期的最长链。

# 简化的进度网络（左为前置，括号内为工期，单位：天）

需求梳理(3) -> 设计评审(2) -> 编码(8) -> 联调(5) -> 上线(1)
                        \----> 测试用例(3) ----/

# 关键路径（决定总工期）：
# 需求梳理 -> 设计评审 -> 编码 -> 联调 -> 上线
# 合计 3 + 2 + 8 + 5 + 1 = 19 天
# 测试用例(3) 存在浮动时间，不决定总工期

# 缓冲策略：把缓冲统一加在关键路径末端作为项目缓冲，
# 而不是让每条任务各自悄悄乘以 1.2。

缓冲的加法很关键。如果每条任务都私藏一点水分，延期会被隐藏到最后一刻才爆发。更安全的做法是统一留一块项目缓冲，并由负责人透明管理：谁消耗了缓冲、消耗了多少，团队都看得见。

风险识别与登记册

进度排好之后，真正决定成败的往往是不确定性。风险管理的起点是把它写下来。团队可以用一份简单的登记册，把风险变成可跟踪的条目。

风险影响概率应对措施
第三方接口未按时联调高中提前确认接口契约，准备本地桩服务
关键成员请假或离职高低核心模块结对开发，文档沉淀到仓库
需求在迭代中反复变更中高冻结迭代范围，变更走独立排期
测试环境不稳定中中环境即代码，故障时能快速重建

登记册不是一次性文档。每次迭代开始时，团队一起过一遍风险：哪些已经消除，哪些概率上升了，是否需要调整应对措施。风险一旦被写下来并定期回看，就不再是某个人心里隐约的担忧。