129小时对49小时:工作量估算误差剖析
我们的项目档案里有一个季节性落地页项目。对客户报价49小时,实际投入129小时。项目按期交付,客户满意,款项到账——这也是唯一一个我确切知道两个数字的案例,因为两个数字都留存在文件中。
2.6倍的差距既不是纪录,也不是例外。在一项针对52个项目的实地调查中,76%的项目出现了工作量超支,平均超支幅度为41%。在做工作量估算(effort estimation)时,真正该问的问题不是"需要多少小时",而是"这个数字是在什么时点、基于什么依据说出口的"。
估算出错,不是因为有人把小时数算错了。它出错,是因为数字在需求确定之前就被说了出来,而此后第一个说出口的数字会成为一个锚点(anchoring),牵引之后所有的重新核算。解决办法不是让计算更精确,而是把估算变成流程中独立的一个阶段——放在范围描述之后、签约之前。
80个未预见的小时都花在了哪里
"低估了复杂度"这个答案什么都解释不了,也解决不了任何问题。真正有用的做法是把差距拆解成一个个可以指名道姓、标注日期的事件。在这个项目里一共有五个这样的事件,而且每一个在发生时都不像是问题。
估算在范围描述之前就被说出口。这个数字是在第一次通话中说出的,回答的是"大概多少钱"这个问题。这个大概的数字本来只是为了让客户对费用量级有个概念——却变成了约定中的数字。从"大概"到"已确认"之间,没有任何一份文件作为过渡。
每一次补充需求都是单独提出的。加一个节目单模块。用两种货币显示价格。做一个单独的邮件推送版本。单独看,每个补充需求都只是半小时到一小时的工作量,拒绝它显得斤斤计较。正是这些半小时累加起来,构成了差距的主要部分。
沟通协调被当作免费的。估算中只包含了设计师和排版人员的工作。没有包含的是:往来沟通、三轮文案修改、等待素材、客户把设计稿给同事看后要求的重新制作。这些都是项目经理和执行人员的实际工时,不管有没有被计入估算,它们都实实在在地发生了。
季节性吃掉了风险预留(risk buffer)。这是一个新年主题的项目,上线日期不能推迟。当工作进度滞后而日期又是固定的,唯一可动用的资源就是团队晚上和周末的时间。在普通项目中本该体现为工期顺延的预留,在这里直接变成了额外工时。
没有人在项目进行中重新核算。超支的信号大约在项目进行到一半时就已出现——但没有转化为一次对话。在工作已完成一半时谈钱,永远比在开始时谈更不舒服,于是这个话题被一拖再拖,拖到项目结束时已经没有意义。
| 事件 | 损失的是什么 | 谁会注意到 |
|---|---|---|
| 估算在范围描述之前说出口 | 不伤面子地修改数字的权利 | 没有人——这个数字看起来像是幸运 |
| 补充需求逐条单独提出 | 执行人员的工时,一次一小时 | 执行人员——但保持沉默 |
| 沟通协调不计入估算 | 项目经理的全部时间 | 没有人——这些工时不在任何地方被记录 |
| 固定日期且没有预留 | 团队的晚上和周末 | 团队——以疲惫的形式,而非数字 |
| 项目中期没有重新核算 | 协商的机会 | 负责人——在月底才发现 |
请注意第三栏。五个事件中有三个在公司内部完全没有人能看到:它们没有报告,没有责任人,也没有应当浮现的时间点。这正是它们反复出现的原因。
为什么第一个说出口的数字会决定后面所有数字
估算差距不是某个团队独有的特点。这是一种在不同样本、不同国家反复出现的稳定规律。而且它背后有一套已经被单独描述过的机制。
在对真实软件项目的调查中,76%的案例出现了工作量超支,平均超支幅度为41%。作者综合更早的多项国际研究后指出,典型的低估幅度区间为30%至40%。
这项数据的局限性应当主动指出:样本来自挪威,已有二十年历史,而且实际工时是根据项目经理的口述收集的,并非来自工时记录系统。它的价值不在于百分比的精确性,而在于这一现象本身的稳定性——超支是常态,而不是例外。
接下来才是真正有意思的部分。一项关于专家估算的实证研究综述表明,问题的根源不在算术,而在数字出现的先后顺序。
专家对工作量的估算会系统性地偏向第一个说出口的数字——即"锚点"。在信息最少时做出的早期粗略估计,即便后来出现了更详细的需求,依然会持续影响之后的每一次重新核算。
这是一篇综述性研究,汇总的是他人的实验结果,其中部分是实验室环境下完成的——文中并没有给出锚定效应生效的确切比例。但它的定性结论比任何数字都更能解释我们这个案例:第一次通话中说出的"大概49小时"根本不是一个估算。它是一个锚点,此后所有的核算,包括那些在完全了解范围之后做出的核算,都在向它靠拢。
这个项目之后我们改变了什么
我们得出的结论,不是关于计算方法,而是关于流程结构。估算不再是对话中的一句应答,而是成为一个拥有独立输入和输出的阶段。流程顺序变成了:接单、需求澄清、需求规格说明书(ТЗ)、工作量估算、双方确认、执行、交付、三天验收期。
这个顺序中有两点是关键。第一:估算排在需求规格说明书之后,而不是之前——只能对已经写清楚的内容做估算。第二:估算和执行之间要有一个确认环节,也就是一个明确的节点,双方都看到同一个数字并加以确认。
解决方案的第二部分是关于费用的。在服务中引入了明确标出工作范围的服务包年费(retainer),并为超出范围的工时设置了单独的计费标准。这样做不是因为更划算,而是因为在这种机制下,关于额外工时的对话是按规则进行的,而不是看当时的心情。
典型的估算差距到底有多大
这个对比之外还有一个关键点:平均值具有误导性。超支的分布并不对称——大部分风险不在中间地带,而在尾部,这正是为什么按平均值做计划无法起到保护作用。
在1471个IT项目的样本中,平均预算超支为27%。但每六个项目中就有一个是"黑天鹅":平均预算超支达200%,工期超出近70%。
这里的局限性很明显:这些是大型企业和政府项目,不是季节性落地页项目。可迁移的不是规模,而是分布的形态。六个项目中有一个会彻底失控,而它的代价由另外五个的利润来承担。
2026年发生了什么变化,又有什么没变
变化的是,部分工作确实变快了。原型、初稿文案、需求拆解、方案初稿——这些现在都能明显更快完成,以此为由缩减估算的诱惑也随之增大。没有变化的是差距的来源:它来自范围,而不是执行速度。
在过去12个月内完成的项目中,有52%遭遇了不受控的范围蔓延(scope creep)。五年前这一比例是43%。
这份报告基于从业者的自我陈述,发布方是一家在推广自身标准上有既得利益的行业协会——这一点应当记在心里。但变化的方向本身很能说明问题:尽管方法论已经发展了二十年,范围蔓延项目的比例仍在上升,而不是下降。
由此得出的实践结论很简单。如果工具让执行速度提升了一倍,但范围仍然在逐条、悄悄地被补充,估算与实际之间的差距依然会存在——只是换了一种计量单位表现出来。
消除大部分差距的四条规则
范围描述完成前不报数字
面对"大概多少钱"这个问题,只有一个安全的回答:一个量级区间,以及给出正式估算的时间点。其他任何回答都会变成锚点。
不只计算生产工作
沟通协调、等待素材、多轮修改、重新制作——这些都是实实在在的工时。如果估算里没有它们,实际发生时它们依然存在。
写明不包含的内容
不包含项清单比工作项清单更短,效果也更好。正是它让新增需求变成一次独立的对话,而不是免费的附加项。
在项目中期重新核算
设定一个把实际情况与估算做对比的节点,并将其设为必做环节。项目中期一次不舒服的对话,比项目结束时悄悄认栽要便宜得多。
如果估算在范围描述完成之前就已经出现在往来沟通中,那么你做的已经不是项目估算,而是在为一个偶然说出口的数字讨价还价。
常见问题
需求尚未确定时,应该如何正确进行工作量估算?
没有办法——这是诚实的答案。在范围描述完成之前,能估算的不是整个项目,而是一个阶段:拆解需求并完成需求规格说明书需要多长时间。这个阶段可以精确估算,因为它的内容是已知的。整个项目的估算在这个阶段之后给出,客户得到的不是开始时的一个数字,而是在两个明确时点分别给出的两个数字。
如果客户要求立刻给出一个数字该怎么办?
给出一个量级区间,并说明正式估算会在什么时候给出。区间必须足够宽,才不会变成锚点:"两到六周之间,需求规格说明书完成后再确定。"出于想显得胸有成竹而给出的窄区间,其作用等同于一个精确数字,会造成同样的问题。
估算中应该预留多少风险预留(buffer)?
按百分比设置的风险预留解决不了问题,因为差距来自范围变化,而不是计算不精确。真正有效的做法是:在预算中单独设立一条线,用于承接首次展示成果之后出现的新需求,并配有明确的负责人和使用规则。如果没有这条线,这些需求依然会被完成——只是代价由执行方承担。
129小时对49小时这个差距有多大代表性?
这只是一家公司的一个项目,不是行业基准。它真正有代表性的地方不在于比例本身,而在于两个数字都被完整保留了下来:实际工时是当时记录的,而不是事后凭记忆还原的。在大多数公司里,这种对比根本无法做出来,因为实际工时从来没有被记录在任何地方。
"实际129小时"和"报价49小时"这两个数字,来自Alego.Digital档案中一个季节性落地页项目的内部预算表。流程顺序(接单→需求澄清→需求规格说明书→工作量估算→确认→执行→交付→三天验收期)以及带有单独超出工时计费标准的服务包年费模式,来自同一时期的客户协作规范。这些是作者所在公司的内部文件,未经独立第三方核实,仅作为机制说明,不作为行业基准引用。差距所拆解出的五个事件,是根据项目文件和往来沟通记录还原的。
- Moløkken-Østvold K. J. Effort and Schedule Estimation of Software Development Projects. University of Oslo, PhD thesis, 2004年8月。simula.no
- Jørgensen M. A Review of Studies on Expert Estimation of Software Development Effort. Journal of Systems and Software, 2004年。simula.no
- Flyvbjerg B., Budzier A. Why Your IT Project May Be Riskier Than You Think. Harvard Business Review, 2011年9月。hbr.org
- Project Management Institute. Pulse of the Profession 2018(5402名受访者调查)。pmi.org