为什么估算会变成错误的承诺

Management 需要规划。

这完全合理。

团队需要方向，预算需要假设，Stakeholder 需要一定程度的可预期性。一个企业、产品或项目，不可能面对所有问题都只回答一句“谁知道呢”。

问题不在于有人要求规划。

问题从另一个时刻开始：一个本来充满不确定性的估算，被当成了看似可靠的承诺。

“我们只需要一个大概估算”

这句话听起来很无害。

“只是大概。”

“只是为了做计划。”

“只是想先有个感觉。”

然后，组织里几乎总会发生同样的事情。

这个粗略估算开始向外流动。

先进入 Roadmap。 然后进入预算计划。 然后进入 Steering。 接着变成期待。 最后变成 Eskalation。

再过一段时间，已经没人记得这个数字最初是在高度不确定的情况下给出的。

“如果这些假设都成立，大概两周”最终会变成：

“团队已经承诺两周完成。”

规划就是在这里发生了变质。

不是因为 Management 不该做计划。

而是因为不确定性被从计划中删掉了。

软件开发不是流水线工作

很多时间估算背后有一个很古老的误区：

把软件开发当成确定性的生产过程。

仿佛流程已知。 步骤已知。 重复性已知。 剩下只需要知道执行速度。

在流水线生产中，这个模型往往更接近现实。

如果材料、流程、工具和目标都已知，就可以测量 Throughput，规划也会更可靠。依然不会完美，但至少过程本身是可观察的。

软件开发通常不是这样。

它不只是执行。 它包含分析。 包含建模。 包含 Integration。 包含排错。 包含业务澄清。 包含风险降低。 也包含发现那些事先根本不知道的东西。

尤其在已有系统中，真正的工作很少只是：

“实现 Feature X。”

更常见的是：

“先弄清楚 Feature X 在这个系统里究竟意味着什么，存在哪些隐含规则，会触碰哪些依赖，以及哪些原本的假设其实是错的。”

这和打字速度没有关系。

这是在不确定性下进行的知识工作。

经验不是 X 光机

另一个经常出现的说法是：

“你都是 Senior 了，这应该能估吧？”

可以。

也不完全可以。

经验当然有帮助。

有经验的开发者更快识别 Pattern。 架构师更早看到依赖。 Tech Lead 往往在风险还没在 Daily 里“发臭”之前就能闻到它。

但经验不是 X 光机。

它不会自动让未知的业务规则显现出来。 不会自动发现隐藏的副作用。 不会自动揭开历史特殊情况。 不会自动告诉你测试数据其实已经坏了。 也不会自动预测第一次真正 Debugging 时，哪一块旧债会从墙里掉出来。

恰恰是经验丰富的人，往往在估算时更谨慎。不是因为他们知道得更少，而是因为他们见过得更多。

Junior 看到的是一个 Ticket。

Senior 看到的可能是一个 Ticket、三个隐含假设、两个未知接口、一个潜在权限问题、缺失的可测试性，以及一个大概率还没人真正决定过的业务问题。

这不是因为能力不足而产生的不确定性。

这是来自系统理解的不确定性。

Seniority 并不意味着消除不确定性。
Seniority 意味着更早识别不确定性。

研究把这叫作 Planning Fallacy，而不是“凭感觉”

人们倾向于低估工作量，并不是什么新现象。

心理学中有一个概念叫 Planning Fallacy。人们在预测未来任务时，常常比类似任务的真实历史数据更乐观。尤其危险的是“内部视角”：我们会想象工作按照理想路径推进，却系统性低估干扰、等待、澄清、错误和依赖。

软件开发还多一层问题。

估算通常来自 Expert Judgment，也就是经验丰富的人做出的判断。这并非没有价值，但它同样会受到乐观偏差、Anchoring、社会压力以及过窄的不确定区间影响。

如果一个期望日期已经摆在桌上，估算就不再中立。

如果预算压力已经在场，估算就不再中立。

如果有人先说“这不就是个小改动吗”，估算也不再中立。

这时发生的就不只是估算。

而是谈判。

很多时候甚至不是公开谈判。数字只是被心理压力一点点推向期望的方向。

Cone of Uncertainty 不是借口

Cone of Uncertainty 描述了一个简单但不舒服的事实：

越早期的估算，通常越不确定。

不是因为做早期估算的人能力差。

而是因为一开始确实缺少信息。

需求还不清楚。 接口还没有真实验证。 风险还没有显现。 业务规则还没有显式表达。 依赖还没有真正经历。 技术债也还没有被触碰。

这个阶段当然仍然可以规划。

但不能假装一个项目最初的数字，和已经做过多个真实 Slice、Integration 和 Feedback Cycle 之后的预测一样可靠。

早期估算不是事实。

它只是我们当前“不知道多少”的一种表达。

听起来有些刺耳。

但很有帮助。

因为一旦接受这一点，团队就可以做真正有意义的事：减少未知。

“It’s done when it’s done” 很诚实，但没有用

有时候，内心最诚实的答案确实是：

“不知道。做完的时候就做完了。”

这很正常。

尤其是在一个新的系统里。 面对新的业务领域。 面对未知架构。 未知数据。 未知依赖。

但作为对外回答，它帮不了任何人。

帮不了 Management。 帮不了团队。 帮不了客户。 也帮不了规划。

更专业的回答是：

“目前缺少足够的系统知识和业务知识，无法给出可靠的完成时间。不过我可以估算接下来哪些步骤能够降低这些不确定性。”

这是一个非常重要的区别。

不是拒绝规划。

而是不去规划一个尚未被理解的结果。

我们先规划下一个获得信息的步骤。

例如：

• 一个 Technical Spike
• 分析受影响的接口
• 实现一个最小 End-to-End Slice
• 用具体示例澄清业务规则
• Characterize 当前系统行为
• 用真实数据做 Prototype
• 在真正实现前先完成风险决策

这才是成熟的规划。

不是：

“我们已经知道什么时候全部做完。”

而是：

“我们知道下一步必须弄清楚什么，才能做出更好的计划。”

当估算开始给人排序

来看一个小例子。

团队正在估一个 Ticket。

Junior 说：

“五天。”

Senior 说：

“一天。”

讨论之后，团队最后记下：

“两天。”

然后出现了一个看似非常实际的问题：

“那谁来做？”

如果答案是：

“当然让 Senior 做。”

那整个机制已经坏了。

因为此时估算的已经不是工作。

而是在给人排序。

估算不再表达团队对工作复杂度的共同理解，而变成一种隐性的提前分配。

它会带来后果。

Junior 学不到东西。 Senior 变成瓶颈。 知识继续集中。 团队越来越依赖少数人。 复杂工作永远落到同一批人手上。 Senior Burnout。 Junior 更久地停留在 Junior。 所谓 Self-Organization 变成表面形式。

短期看，这很高效。

长期看，它会制造一个系统：最有经验的人永远负责救最困难的任务，其他人则没有足够空间在真实复杂度中成长。

这不是 Agile Planning。

这是披着敏捷外衣的 Capacity Management，同时还在阻止学习。

Goodhart 已经在 Jira 里等着了

估算还有另一个问题。

一旦某个指标本身变成目标，人们的行为就会围绕这个指标发生变化。

这就是 Goodhart’s Law：

当一个指标成为目标，它就不再是一个好的指标。

放到软件开发里：

如果“估算工时”变成管理目标，整个系统就会开始优化估算工时。

而不是价值。 不是学习。 不是质量。 不是风险降低。 也不是真正的交付能力。

优化的是那个数字。

举个例子。

开发者估算一个 Ticket 需要 40 小时。

20 小时之后，他已经完成了。

接下来会发生什么？

在健康的系统里，这是好消息。

工作比预想中小。 团队获得了新信息。 后续预测可以更准确。 也许 Ticket 本来就简单。 也许方案更优雅。 也许估算过于保守。 也许关键风险被提前消除了。

但在一个失灵的系统里，会出现另一种冲动：

“还是记 40 小时吧，不然下次估算就不好看了。”

或者：

“如果我老实记 20 小时，下次他们就会默认还是 20。”

或者：

“如果我做得快，只会得到更多工作。”

或者：

“这次低于计划交付，下次计划只会被压得更激进。”

于是，估算变成了自我实现的预言。

不是因为开发者懒。

而是因为系统制造了错误激励。

如果把估算当作个人绩效指标，你并没有保护规划。

你是在摧毁那些本来可以让规划变得更好的数据。

此时，工时记录已经不再是观察。

它变成了防御。

虚假的精确感，比诚实的不确定性更让人安心

为什么这种事情仍然反复发生？

因为虚假的精确感让人安心。

“17 天完成”听起来比下面这句话舒服：

“8 到 30 天之间，取决于接口是否真的像文档描述的那样工作。”

单一数字更适合放进 Roadmap。 更适合预算。 更适合 PowerPoint。 也更适合拿去和不愿意听见“不确定性”的人沟通。

但一个数字并不会因此更准确。

它只是更容易被消费。

这正是危险之处。

你把不确定性从 Slide 上删掉，并不会让它消失。

它只会晚一点回来。

变成延期。 变成 Bug。 变成 Rework。 变成 Eskalation。 变成周末加班。 最后变成一句：

“你们为什么不早点说？”

而答案经常是：

我们说过。
只是那种表达方式没有被允许进入计划。

真正有帮助的做法是什么？

糟糕时间估算的替代方案，不是完全不做计划。

而是更好的规划。

更好的规划首先要做的，不是隐藏不确定性，而是主动减少它。

1. 把工作切小

一个 Ticket 越大，未知风险就越容易主导结果。

如果一个 Ticket 粗略看上去超过三个开发日，这当然不是自然法则，但至少应该成为一个警报。

也许 Ticket 太大。 也许里面混着多个决策。 也许分析和实现没有分开。 也许缺少一个具体业务示例。 也许它依赖一个未知接口。 也许它其实是一个伪装成 Ticket 的小项目。

小 Ticket 不会让所有事情自动变简单。

但它会让偏差变小。

而小偏差更容易规划。

2. 估复杂度，而不是精确小时数

相对复杂度通常比小时数更诚实。

不要说：

“这需要 13 小时。”

而可以说：

“这是小型、已知、低风险的工作。”

或者：

“业务上还不清楚，技术上有耦合，应该先继续切分。”

Story Point、T-Shirt Size 或类似方法都不是魔法。

只有在团队不偷偷把它们重新换算成小时的情况下，它们才有意义。

一旦“5 Point”自动等于“3 天”，你只是用新货币重新包装了旧的虚假精确。

3. 显式表达不确定性

可用的估算不应该只有一个数字。

它需要上下文。

例如：

• 乐观情况
• 最可能情况
• 悲观情况
• 最大假设
• 最大风险
• 尚未决定的问题
• 外部依赖
• 下一步需要获得的知识

例如：

“大概率两到四天，但前提是现有 API 能提供预期数据。最大风险是权限逻辑。”

这对规划的价值，远远高于：

“三天。”

即使前者更不舒服。

4. 先降低风险，再固定日期

如果一个工作量很大、很模糊，或者业务领域完全陌生，就不应该第一步就去估完整实现。

先处理风险最大的部分。

不是最简单的。 不是最好看的。 也不是 Demo 时最容易获得掌声的。

而是最可能让整个计划失效的部分。

可能是一个接口。 一个权限模型。 一个数据模型。 一次 Migration。 一个业务特殊情况。 一个 Performance Risk。 一个 Deployment Path。 一个可测试性问题。

规划可靠性来自最大未知风险逐渐减少。

不是来自某个人盯着一个数字看得更久。

5. 使用历史数据

如果真的希望规划越来越好，就需要真实观察。

不是拿来控制某个个人。

而是给团队一个外部视角。

类似 Ticket 实际上需要多久？ 外部依赖平均阻塞多久？ Cycle Time 是多少？ 团队稳定能完成多少 Item？ 哪类工作经常突然爆炸？ Rework 发生在哪里？ Ticket 在哪里等待？ 哪里缺少决策能力？

这是规划开始成熟的地方。

从：

“大家觉得这要多久？”

变成：

“类似工作的真实 Throughput 和 Cycle Time 告诉了我们什么？”

6. 把 PERT 当作思考工具，而不是事实生成器

PERT 和 Three-Point Estimation 可以帮助显式表达不确定性：

• 乐观
• 最可能
• 悲观

这比只给一个数字好。

但如果最后又把 PERT 压成一个看似极度精确的数字，并把它当作承诺，它一样会失败。

PERT 在大量相互独立的任务可以通过统计效应相互抵消时尤其有帮助。

面对少数几个巨大且彼此耦合的风险，再漂亮的公式也帮不了你。

那时需要的是更小的 Slice。

规划可靠性，本质上是风险管理

规划并不会因为更强硬地逼人给出他们目前无法可靠知道的日期，就突然变得可靠。

真正的可靠性来自把工作组织成一种形式：未知更早显现，也能更早被缩小。

这意味着：

• 更小的 Ticket
• 真实的业务示例
• 尽早做技术贯通
• 清晰的接口边界
• 快速 Feedback Cycle
• 可见的风险
• 诚实的时间区间
• 历史 Cycle Time
• 持续更新预测

这不如一个单一数字方便。

但有用得多。

更好的问题

第一句不应该总是：

“这要多久？”

更好的问题是：

“我们确定知道什么？”
“什么仍然只是假设？”
“最大风险是什么？”
“怎样把它切得更小？”
“这周我们能验证什么？”
“哪一个真实观察会改善下一次预测？”

因为估算不是交付日期。

它只是对我们当前不确定程度的一种陈述。

Management 需要规划。

但规划需要面对不确定性，而不是制造虚假的精确感。

真正想获得规划可靠性的人，不会要求更漂亮的幻想数字。

他会建立一个能更早暴露风险的系统。