每个开发者在冲刺规划会上都心知肚明，却没人说出口：

用小时估算，结果永远偏低。

打开网易新闻 查看精彩图片

资深工程师估低，是想显得高效。新人估低，是不想显得慢。整个团队估低，是因为产品经理就在会议室里。然后冲刺结束，一半工单延期，所有人假装惊讶。

多年观察不同团队、语言和技术栈之后，我越来越确信：问题不是我们不擅长估算小时数，而是"小时"本身就是错误的单位。

我现在改用复杂度估算。它带来更好的软件、更好的团队——意外的是，还有更靠谱的截止日期。

大多数团队掉进同一个陷阱：把复杂度和时间当成同一回事，只是换了把尺子量。它们不是。这是两个独立的维度。

想想翻译。把一段英文译成西班牙语，很简单，几乎没复杂度。但翻译整本圣经呢？依然简单——每句话的认知负荷没变，只是篇幅长。简单不等于快。

反过来。复杂的分布式系统迁移，听起来该花几周。但如果你的平台恰好有现成的工具，可能一个下午就搞定。复杂不等于慢。

一旦内化这一点，基于小时的估算游戏就开始显得荒谬。你在把两个维度压成一个，还假装结果有意义。

我待过的团队最终采用类斐波那契数列：3、5、8、13。超过13不算估算，而是信号——任务该拆分了。

数字本身不重要。重要的是它们代表什么：

你可以叠加不确定性、耦合度、影响范围、依赖关系、团队熟悉度等维度。但目标不是建立精确的量表，而是给团队一套共享词汇，用来讨论"这事有多难"，独立于"要花多久"。

关于故事点数，没人告诉你的真相是：它们比小时更好，不是因为更准确。说实话，绝对精度上可能更差。

它们更好，是因为改变了对话方式。

问"这事要花多久？"，对话是个人化的、防御性的。最懂的人抛出一个数字，其他人点头。真正干活的新人默默恐慌——他们知道做不到，但反驳等于承认自己慢。

问"这事有多复杂？"，对话是集体性的。为什么这是5不是3？有哪些模块？哪里可能出错？新人看着资深工程师推理问题，边学边做。资深工程师偶尔会发现，自己说的" trivial "其实并不 trivial。团队在动手之前，先理解了要做什么。