工作量估算应是流程的一个阶段,而不是谈判中的一句话
在大多数公司里,工作量估算(effort estimation)并不是流程中的一个阶段,而只是一句对话:有人问"这个大概要多少",有人给出一个数字。这样的回答没有输入,没有责任人,没有正式产出,也没有可以据以修改的规则。
差异会在冲突发生的那一刻显现出来。范围变了,数字却没变,双方争论的其实是诚信问题——因为没有任何东西可以拿出来说明。如果估算曾是一个正式阶段,双方争论的就是范围到底有没有变化,而这个问题有文档可以回答。
当估算具备四个要素时,它才变得可管理:输入——一份范围说明(scope description);责任人——一个具体的人;产出——一份正式的估算依据(basis of estimate);以及重新估算触发条件(re-estimation trigger)——范围一旦变化,流程就退回重新计算,而不是被悄悄塞进现有工作里。计算的精确度反而是次要的:提问的方式对结果的影响,远大于计算方法本身。
一个估算阶段应具备的四个要素
判断估算在你的公司里是否真的是一个流程阶段,五分钟就够了——只需检查四件事是否存在。缺少其中任何一项,估算就还停留在往来沟通里,而不是流程里。
输入:一份范围说明。只有被描述出来的东西才能被估算,而描述里必须包含一份"不包含什么"的清单。排除项比包含项更短,作用却更大:正是它们决定了下一次的需求澄清是免费追加,还是一次单独的谈判。
责任人:一个具体的人。不是"团队评估过了",而是一个名字挂在这个数字下面、能回答这个数字是怎么算出来的人。没有估算责任人(estimate owner)的集体估算,等于把责任同时从所有人身上卸掉,也让组织失去了从偏差中学习的机会。
产出:估算依据。不是一个数字,而是一个附带构成说明的数字:它由哪些工作构成,采用了哪些假设,哪些内容没有覆盖到。估算依据不是给客户看的——它是给一个月后需要弄清楚实际结果为什么偏离计划的人看的。
重新估算触发条件。一条规则:范围一旦变化,流程就退回重新计算,而不是直接叠加到当前工作里。没有这条规则,变更会悄无声息地累积,而这正是计划与实际脱节的主要机制。
| 要素 | 存在的标志 | 缺失时会出什么问题 |
|---|---|---|
| 输入:范围说明 | 有一份明确的排除清单 | 每一次澄清都变成免费追加 |
| 责任人 | 数字背后的作者是谁,人人都知道 | 没人能解释偏差 |
| 产出:估算依据 | 数字被拆解为构成和假设 | 无法复盘偏差的根源 |
| 重新估算触发条件 | 范围变化会触发重新计算 | 变更悄悄累积 |
这套结构不是我发明的。它已经在行业实践标准中被正式化,值得看看具体是怎么写的。
实践标准是如何描述估算的
估算的生命周期被描述为四个连续阶段:估算准备(建立方法和输入数据)、形成估算并产出正式的"估算依据"、估算管理(范围变化时重新评审)、以及根据累积的偏差改进估算流程本身。
这里的局限我直说:这是一份规范性文件,不是一项测量,我读到的是该组织网站上对其结构的介绍,而不是标准全文。它的价值不在于充当证据,而在于确认"估算是一个有输入和产出的流程"是行业公认的做法,而不是我的个人偏好。反面意见同样值得了解:更新的国际标准ISO 21502:2020有意放弃了"输入—产出"的表格化模型,转而采用对实践本身的描述。
提问方式对结果的影响大于方法本身
关于估算,最出乎意料的一点是:结果的质量更多取决于问题的措辞,而不是估算者的水平。这一点已经在实地得到验证。
当要求估算者以90%的把握给出一个"从-到"区间时,实际成本落在所给区间内的比例只有74%。当同样的问题被改写成概率式提问——"成本超过某个数值的可能性有多大"——命中率上升到87%。
样本量不大,且仅限于两家挪威公司和软件项目——这些百分比不能直接套用到其他行业。但可以迁移的是这个结论:问"大概多少",得到的是一种并不真实存在的确定感。问"我们超出X的概率有多大",得到的答案明显更诚实,更重要的是,它设定了一种可以讨论不确定性、而不必让任何一方丢面子的提问方式。
输入被正式化之后能带来什么
第二个可验证的效应,是估算前范围梳理的完整程度与最终结果可预测性之间的关系。这一点在资本建设(工业与建筑工程)领域得到了测量,那里的样本量比IT行业更大,数据也更完整。
项目前期范围界定的质量,大约能解释工业项目最终成本离散度的23%。范围界定得更好的项目,其成本和工期的可预测性始终优于界定较差的项目。
这是建筑行业,不是软件开发,具体百分比不应直接照搬。可以迁移的是其中的机制:被正式化的输入确实能为可预测性带来可衡量的贡献——但只占离散度的四分之一,不是全部。剩下的四分之三,取决于估算完成之后发生的事情,而这恰恰是重新估算触发条件要覆盖的部分。
确定性不会自动提升
有一种流行的看法认为,不确定性会随着项目推进自动收窄——也就是所谓的"不确定性锥"(cone of uncertainty)。这幅好看的图景经过了实证检验,而检验结果并不支持它。
在被研究的项目中,估算的不确定性区间在各个阶段几乎保持不变——上下限之比始终维持在约3.25——而不是预期中的收窄。估算误差的中位数为1.8倍,平均值为2.0倍。
这是一家公司的数据——是一个推翻流行曲线的案例,而不是对所有情境的最终否定。但对流程设计而言,结论是直接的:如果不确定性不会自动收窄,估算就不能是一次性的阶段,而必须在每次范围变化时重复进行——这正是为什么第四个要素、重新估算触发条件,比前三个更重要。
如何把这个阶段嵌入现有流程
这里真正难的只有一件事:守住"退回"这条规则。因为半小时的小修改就把流程退回范围说明,看上去像是官僚主义,正因如此,第一次例外几乎总会被放行——而从第一次开始,就再也没人计数了。可行的办法是设一个阈值:低于约定幅度的变更累积到一份单独清单里,按批次统一重新计算;其余的一律把流程退回第一步。这样的清单是如何累积起来的,以及它最终付出了怎样的代价,我在一个实际结果比估算超出2.6倍的具体项目里做了拆解。
让估算成为一个阶段的四个决定
范围说明之前禁止报数字
面对"大概多少"这个问题,给出一个数量级区间,以及给出正式估算的日期。
问超支概率,而不是问要多久
不是问"这个要多久",而是问"我们超出X的概率有多大"。提问方式的改变,会改变答案的质量。
记录依据,而不是记录数字
工作构成、假设条件、以及哪些内容没有覆盖。半页纸,一个月后就能用来解释偏差。
设定退回阈值
超过阈值的变更,把流程退回范围说明;低于阈值的,累积到清单里按批次重新计算。
如果一个数字背后既没有名字,也没有依据,你手里就不是一份估算——只是某个人曾经说出口的一个数。
常见问题
估算依据应该包含什么?
三样东西:带工作量的工作清单、所采用的假设、以及估算中没有覆盖的内容清单。篇幅半页到一页即可。这份文档的意义不在于精确,而在于一个月后能打开它,准确看到到底是哪一条假设没有成立。没有它,复盘偏差就会变成各说各的回忆。
谁应该是估算责任人?
应该是将来要为交付负责的人,而不是主导谈判的人。如果估算由销售给出、由团队执行,偏差几乎是必然的,而且到时候没人能解释:这个数字背后不会有一个愿意讲清楚其构成的作者。可行的折中方案是:估算由执行团队给出,商务条件在此基础上由客户经理搭建。
如果需求一直在变,该怎么估算?
估算迭代,而不是估算整个项目,并让估算这个阶段变成可重复的动作。实证数据表明,不确定性不会随项目推进自动收窄,因此在这种条件下,项目一开始就做一次性估算没有意义。真正有效的做法是:近期范围给出精确估算,同时为整体范围给出一个明确声明的区间,并按既定规则定期修订。
把估算正式化,会不会变成官僚主义?
如果什么都要走完整流程,就会变成官僚主义。退回阈值存在的意义正在于此:小的变更不会触发完整周期,而是累积到清单里按批次重新计算。阈值设置合理的标志是:这份清单每月被重新计算一到两次,而不是天天算,也不是从来不算。
流程的阶段划分(询价 → 需求澄清 → 需求规格说明书 → 工作量估算 → 双方确认 → 执行 → 交付 → 三天验收)来自Alego.Digital的客户合作制度。这是作者所在公司的内部文件,未经独立第三方核实,这里只作为机制说明的示例引用。退回阈值规则以及把小变更累积成批次重新计算的做法,是作者本人在复盘多个计划与实际脱节的项目后形成的实践经验;公司文件中并没有对这条规则的正式书面描述。
- Project Management Institute. Practice Standard for Project Estimating, 2011(结构说明见pmi.org). pmi.org
- Jørgensen M. Realism in Assessment of Effort Estimation Uncertainty. IEEE Transactions on Software Engineering, 2004年4月. simula.no
- Wang Y.-R., Gibson G. E. Jr. Project Definition Rating Index as an Indicator of Project Performance. PMI Research Conference, 2002. pmi.org
- Little T. Schedule Estimation and Uncertainty Surrounding the Cone of Uncertainty. IEEE Software, 2006. researchgate.net