估算、排期与风险 — 预测为什么总是失败
这一章讲五件事: 完工时间的数学下限(主走查看一道开立方);估算为什么本质是概率题; 度量产出的两把尺子各断在哪;排期管理的一组纪律(相信它、重估它、按差异汇报它); 以及风险的算法——把「可能会出的事」折成一个数。第 03 章埋的钩子(估算错误前 5 因在需求)在这里收口。
1. 先看现象:每个项目都从「不可能的承诺」开始
「这个功能两周能上线吧?」「下个季度肯定交付。」
这些话的共同结构:先有了一个想要的日期,再倒推出一个「人月数」,仿佛人月是水,往里灌人就装满。 第 09 章已经拆过一半:加人不等于加工作能力(布鲁克斯定律)。这一章拆另一半: 就算人已经够了,日期本身也可能在数学上不成立。
本章其余部分都从这个事实展开:排期失败不是谁的错,是预测这件事的结构造成的—— 所以出路不是「更用力地估」,而是承认预测的天花板,把管理动作换成天花板以下还成立的那些。
2. 顶层全景
「我们要在 X 月交付」
│ 先验货:X 在不在可能区域内?
▼
数学下限:工期 ≥ 2.15 × ∛(人月数) (99% 的已完成项目遵守)
│ 过了这关,也别高兴太早——估算只是概率
▼
估算=抛 100 次硬币猜 50 次:不是承诺,是概率分布的峰
│ 分布怎么来?靠度量。可两把尺子都有洞
▼
代码行(越好的语言行数越少) · 功能点(量得出问题量不出难度)
│ 所以:剪裁模型、相信排期、定期重估、按差异汇报
▼
现实跑起来必有偏差 → 把偏差当产品管理:风险敞口 = 破坏 × 概率
图说:本章五个动作排成一条链,前两个管「别定不可能的目标」,
后三个管「目标可行时怎么执行」。估算要对未来发言,先把「概率分布」
(把每种可能结果和各自的可能性列出来)这个说法立在门口。
3. 核心原理
3.1 主走查:不可能区域——开一道立方根
原则 148 引 Boehm 的「不可能区域」(impossible region):从需求规格说明定稿到交付, 所花时间不会少于 2.15 乘以人月数的立方根;书里补了它的分量—— 所有已完成的项目中,99% 遵守这条规则1。
把公式走一遍(立方根和乘法是我们算的,公式与常数来自原书):
项目 A:估算工作量 1000 人月
最快工期 ≥ 2.15 × ∛1000 = 2.15 × 10 = 21.5 个月
—— 千人月的活,再多人手,也快不过约 22 个月
项目 B:估算工作量 8 人月
最快工期 ≥ 2.15 × ∛8 = 2.15 × 2 = 4.3 个月
—— 小活也快不过 4 个多月
对照:如果有人要求「1000 人月的活,12 个月交付」
→ 12 < 21.5,承诺落在不可能区域内
→ 谈判对象不是工期,是范围:砍需求(第 04 章 3.4 的优先级表这里用)
图说:立方根的含义:人月涨 1000 倍,最短工期只涨 10 倍——
人多确实能压缩工期,但压缩的曲线越来越平,永远压不到零。
这条公式是第 09 章 3.2 的另一半:布鲁克斯定律说「加人追不回延期的进度」, 不可能区域说「即使提前规划,工期也有底线」。两条合起来, 「人月是可以互换的水」这个直觉在两头都被数学拒绝。
3.2 估算的真实身份:一次概率表述
就算排期在可能区域内,估算出来的那个数也不能当承诺。原则 154 的类比精确无比2:
我要抛 100 次硬币,让你预测正面向上的次数。你答「50 次」——这是最优估计。 但真抛出来恰好 50 次,连你自己都会吃惊。「50」猜的是概率分布——把每种可能的结果 和各自的可能性列成的一张表——不是对一个结果的承诺。
软件估算同理。同一个「模型算出 100 万美元」,为什么实际会偏?书里给了三个原因2: 你(领导力能左右结果——「你可以在 5 秒内破坏团队花了一年建立的士气」); 假设(估算时假定的条件——人才、需求稳定、设备完好——任何一个可能不成立); 概率(估算值只是概率分布的峰)。
与 3.1 配套的纪律:真正决定排期成败的,书里说得很反直觉—— 排期成功的概率,与其说取决于排期现实,不如说取决于团队对排期的信心3。 所以最好的做法是让工程师自己制定排期;做不到,至少让他们参与「功能、进度、砍项目」之间的权衡3。 顺便破除一个心理安慰(原则 156):轻微低估不总是坏事——略落后会让人加劲; 但严重低估会砸掉士气,反方向失控4。
3.3 两把断尺:代码行与功能点
估算要有输入,输入靠度量——而这一行的两把尺子都有断口,书里各给了绝妙的反例:
尺子一:每行代码成本。 为什么它是没用的指标(用来衡量某件事的数)? 高级语言让总开发成本下降,但每行代码的成本反而上升——因为文档、需求、设计这些固定成本, 现在要摊到更少的行数上。书里借 Capers Jones 的制造类比:产量越少,单件成本越高, 因为固定成本由更少的件分摊5。
尺子二:代码行(产出)与功能点(问题规模)。 原则 145 拆得干脆: 用代码行量效率,奖励「写得啰嗦」——同样功能,两倍的行数在尺子上是两倍的产出,但小的那个才是好的; 用功能点量,量的是问题的大小而不是实现的难度——书里的反例: 两份需求规格说明只差一句话,一份说「如果系统崩溃,全人类将被摧毁」, 另一份说「如果系统崩溃,两个五岁的孩子将轻微感觉不便」—— 功能点数一样,难度天差地别6。
结论也干脆:十全十美是不可能的。度量只配做一件事——确认你的直觉和亲身经验;永远别让它们当唯一的裁判6。
配套三条工艺:
- 剪裁模型(原则 146):买来的估算公式(COCOMO 等)基于别人的历史项目;要用,先用你自己的历史数据 校准它——删掉在你环境里不变的变量,加上在你环境里起作用的变量7;
- 先懂再量(原则 149):数据先要定义清楚。书里的三连问:「纯新写的替代旧系统」算维护还是开发? 「功能翻倍、删掉 95% 旧功能」的改造算什么?——口径没定,数就是装饰8;
- 现在就开始收数据(原则 150):今天没数据,今天就剪裁不了模型——这是个借口; 明天还没数据,明天还是借口。少量经过认真收集、充分理解的数据,好过大量没有这些特性的数据9。 顺带修正语言错觉(原则 152):「每人每月 500 行」不是常数——500 行 Ada 干的活远多于 500 行汇编, 语言选择直接改变行数口径10。
最后把第 03 章挂的钩子收回来:估算的原料质量取决于需求质量——那项调查显示, 成本估算错误的前 5 个原因(频繁变更、清单不全、沟通不足、规格低质、分析不充分) 全 部与需求有关11。模型剪裁得再好,喂进去的是歪的需求,出来的就是歪的工期; 先按第 03、04 章把需求立住,这一章的数字才有意义。
3.4 排期的日常纪律
五条,每条一句机制:
| 原则 | 纪律 | 机制 |
|---|---|---|
| 别设不可能的死线12 | 不切实际的死线削弱士气、破坏信任、推高离职——让死线更加无法实现;问题根源是预先计划差,不是执行不力 | 自我实现的失败 |
| 分配合适的资源13 | 硬压排期或预算,工程师消极、延期无人行动,总花费反而更高 | 人在不可能的目标下不出活 |
| 定期重估14 | 每阶段结束重估;落后很少被追回;两种坏结局:低质量出厂,或很晚才告诉客户大延 | 偏差复利 |
| 防驻波15 | 别永远计划「未来几周康复」;不采取行动,波动越来越大;项目是一天一天落后的 | 「快好了」的谎言复利 |
| 别榨干硬件16 | 内存或 CPU 用到 90%,开发成本翻倍;95%,翻三倍(作者 2021:多数应用已不成问题) | 资源紧张放大一切摩擦 |
汇报也有纪律(原则 166、167):「比预算低 25%」未必是好消息——可能活也没干完17; 按差异管理:每次汇报只说「计划与实际的差异」——「各项都按计划进行,除了……」, 把人手自动导向出问题的地方18。计划本身的最低配置(原则 158、159): PERT 表(任务依赖网)、甘特图(时间条)、里程碑清单、文档与代码标准、人员分配—— 「如果你不知道要去哪里,那你也就无法到达那里」(柴郡猫)19; 而过时的计划比没有计划更糟——没计划,你知道自己失控了;过时计划,你以为自己还有控20。 流程模型(瀑布/原型/增量/螺旋)没有普适款,按企业文化、风险偏好、需求易变性选(原则 163)21。
3.5 风险的算法:把「担心」变成一个数
原则 162 给了两步22:
第一步:算敞口。 对每条风险,估两个数:真发生时的破坏程度 × 发生的概率。 风险敞口就是这两个数的乘积——(敞口:不采取任何防范措施时,你实际承担的风险大小)。 拿两条虚构风险走一遍(四个数都是演示编的):
| 风险 | 破坏(人月) | 概率 | 敞口 |
|---|---|---|---|
| 唯一懂老系统的工程师离职 | 80 | 15% | 12 |
| 上游团队改接口规范 | 30 | 40% | 12 |
| 机房断电 48 小时 | 5 | 5% | 0.25 |
第三行教会这张表的用法:破坏大、概率极小的事,敞口未必值得花钱防; 两行敞口相同的风险(一、二行),防哪条看处置成本——接口那条写个适配层就减半,人那条可能无解。 敞口把「哪种担心值得花钱」变成可比较的数。
第二步:建决策树(把「每一步选择及其后果」画成分叉的树形图):列出所有能降低敞口的办法, 要么立刻做,要么写下「敞口超过多少就启动哪个预案」, 并预先说明怎么识别风险已变成现实22。 清单起点是原则 161 的十大风险:人员短缺、不切实际的排期、不理解需求、糟糕的用户界面、 给用户不想要的东西镀金、需求变更失控、缺可复用组件、外部任务不达标、响应时间差、超越当前技术能力—— 「这些是你最可能遇到的风险,但很可能不是全部」23。
最后配上态度(泰坦尼克效应,第 09 章 3.6)和预测史(原则 169、170): 1984 年 13 家大航空公司预测「到 1988 年 50% 的开发仍在哑终端(无处理能力的纯显示终端)上」——错, 开发早已迁到 PC 和工作站;同一批人预测 Ada 占 46%、复用 54%、1994 年 70% 开发由知识系统辅助——全错24。 书里的总结成对:对硬件的演化要乐观,对软件的演化要悲观24。
4. 作者的判断与证据
| 说法 | 谁的 | 证据 |
|---|---|---|
| 工期 ≥ 2.15×∛(人月数),99% 项目遵守 | 作者引 Boehm1 | 历史项目统计回归(COCOMO 体系) |
| 估算=概率分布的峰 | 作者(原则 154)2 | 硬币类比+三因素(你/假设/概率) |
| 每行成本无用(固定成本摊薄) | 作者引 Capers Jones5 | 成本结构论证+制造类比 |
| 功能点量不出难度(全人类例) | 作者自设反例6 | 思想实验 |
| 排期信心>排期现实 | 作者引 Lederer/Prasad3 | 调查结论 |
| 十大风险 | 作者引 Boehm 199123 | 多项目经验归纳 |
判断(我们的,不是书里的): 「不可能区域」公式里最值钱的不是那个常数,是立方根的形状—— 它意味着靠堆人压工期,收益递减得极快;而今天的等价杠杆是砍范围与分期交付, 恰好落在本书第 04 章 3.4(优先级)和第 03 章 3.3(增量、可抛弃)上。 把三条原则串起来读:工期谈不动时,唯一还在你手里的变量是范围。 如果错,会错在: 如果某些工作确实高度可切分且部件间几乎不用沟通(比如大规模独立的人工打标签), 立方根的形状对这些工作就不成立——这条公式的适用域是「部件间要大量沟通的工程」, 而那几乎总是软件项目的实际情况。
5. 边界与局限
- 常数与指数是 1981 年 COCOMO 的口径。后来的估算模型改过系数; 用它的正确方式是 3.3 的「剪裁」——用你自己的历史数据重校7。
- 「99% 遵守」不保证你属于那 1%。书里紧接着反问:「是什么让你认为自己可以做得更好?」1 把宝押在自己是例外上,期望值上是输的。
- 「隐蔽收集数据」与隐私边界:原则 143 的自动化收集25在今天要过员工知情同意这一关, 书的年代没有这层约束。
- 十大风险清单是 1991 年的。清单里的条目(人员、排期、需求、界面、变更失控)依然是今天的高频风险, 但「超越当前计算机技术能力」的具体所指已换代;书里自己说了「很可能不是全部」23。
6. 可带走的
- 排期先过数学关:工期 ≥ 2.15×∛(人月数);99% 的项目逃不出——工期谈不动时,能谈的只剩范围;
- 估算别说「就是 100 万」,说「分布的峰在 100 万」:抛 100 次硬币,「50 次」是猜测不是承诺;
- 让工程师定排期;做不到,让他们参与「功能、进度、砍项目」的权衡——信心本身影响成败;
- 别用「每行成本」评语言、别用「行数」奖产出、别拿功能点当难度——度量只配确认直觉;
- 用自己的历史数据剪裁估算模型;口径没定义的数(什么叫维护?)是装饰;
- 今天不开始收数据,明天继续没得用:少量好数据 > 大量差数据;
- 汇报只讲差异:「各项都按计划进行,除了……」;过时的计划比没计划更糟;
- 每条风险算一个敞口(破坏×概率),敞口相同的,防处置成本低的那个;
- 对硬件乐观,对软件悲观:技术预测里,最稳定的只有「预测会错」。
7. 原文地图
| 主题 | 原书章 | 原文位置 |
|---|---|---|
| 不可能区域(2.15/99%) | 第7章 管理原则 | text/19-ch07.txt:231(搜「2.15」) · text/19-ch07.txt:233(搜「99%」) |
| 估算=概率(硬币/三因素) | 第7章 管理原则 | text/19-ch07.txt:297(搜「硬币」) · text/19-ch07.txt:155(搜「假设」) |
| 相信排期(信心) | 第7章 管理原则 | text/19-ch07.txt:285(搜「信心」) |
| 轻微低估不总是坏(休假) | 第7章 管理原则 | text/19-ch07.txt:315(搜「休假」) |
| 每行成本没用(固定成本) | 第7章 管理原则 | text/19-ch07.txt:195(搜「固定成本」) |
| 两把尺子的洞(全人类/五岁) | 第7章 管理原则 | text/19-ch07.txt:203(搜「全人类」) · text/19-ch07.txt:203(搜「五岁」) |
| 剪裁模型 | 第7章 管理原则 | text/19-ch07.txt:209(搜「剪裁」) |
| 先懂再量(什么算维护) | 第7章 管理原则 | text/19-ch07.txt:241(搜「什么是维护」) |
| 现在收集数据(少量好数据) | 第7章 管理原则 | text/19-ch07.txt:251(搜「过去的项目」) · text/19-ch07.txt:251(搜「少量」) |
| 500 行 Ada ≠ 500 行汇编 | 第7章 管理原则 | text/19-ch07.txt:269(搜「500行」) |
| 别设不可能死线(士气) | 第7章 管理原则 | text/19-ch07.txt:223(搜「士气」) |
| 资源硬压毁项目 | 第7章 管理原则 | text/19-ch07.txt:323(搜「毁了一个项目」) |
| 驻波 | 第7章 管理原则 | text/19-ch07.txt:363(搜「驻波」) |
| 详细计划(柴郡猫) | 第7章 管理原则 | text/19-ch07.txt:345(搜「柴郡猫」) |
| 过时计划比没计划糟 | 第7章 管理原则 | text/19-ch07.txt:357(搜「比完全没有计划」) |
| 进度含义(低 25%) | 第7章 管理原则 | text/19-ch07.txt:457(搜「低于预算」) |
| 按差异管理 | 第7章 管理原则 | text/19-ch07.txt:175(搜「除了」) |
| 别榨干硬件(90%/95%) | 第7章 管理原则 | text/19-ch07.txt:41(搜「90%」) |
| 流程模型选择 | 第7章 管理原则 | text/19-ch07.txt:427(搜「螺旋」) |
| 风险敞口与决策树 | 第7章 管理原则 | text/19-ch07.txt:413(搜「风险敞口」) · text/19-ch07.txt:415(搜「决策树」) |
| 十大风险(镀金) | 第7章 管理原则 | text/19-ch07.txt:389(搜「镀金」) |
| 对硬件乐观(哑终端) | 第7章 管理原则 | text/19-ch07.txt:481(搜「哑终端」) |
| 对软件悲观(Ada/复用) | 第7章 管理原则 | text/19-ch07.txt:493(搜「复用」) |
| 估算错误前 5 因在需求 | 第3章 需求工程原则 | text/15-ch03.txt:13(搜「前5个」) |