需求为什么会错:问题先于方案
这一章讲三件事: 为什么需求错误的根子在「问题没定义」;为什么真实需求只有等用户摸到东西才浮现; 以及四个对应的做法——尽早交付、准备抛弃、能买不造、写下假设。 第 04 章会给出一个数字:这里犯的错,拖到交付时修要贵 200 倍。本章先解决「为什么会错」。
1. 先看现象:需求评审通过了,系统上线了,没人用
需求阶段最容易出的三种事,作者列成「三种徒劳的希望」——草率写完需求就冲向编码, 指望其中某一个成立1:
- 任何系统都比没有系统好;
- 需求的问题「迟早会解决」;
- 设计师边做边会搞清楚该做什么。
三种希望有一个共同前提:假设「要做的事」是清楚的,只是还没写细。 这一章要拆掉的正是这个前提——多数失败的需求,错不在「写得不够细」,错在「问题就没找对」。
先立一个词。需求:一个系统必须表现出的外部行为,也就是「它得做到什么」。 把这些写成正式文档,得到的东西叫需求规格说明2。 本章管「把需求找对」,第 04 章管「把需求写清楚」。
2. 顶层全景:需求错在哪一环
世界里有个「不舒服」(现象)
│ ① 谁的问题?他图什么?──多数项目跳过 这一步
▼
问题定义(电梯问题:六种解法,成本差几个数量级)
│ ② 真实需求不在嘴上,在手上的反馈里
▼
尽早交付(5%~20% 资源时给用户第一次摸)
│ ③ 所以第一个系统大概率要扔
▼
做好抛弃的准备(Royce:预发布版要花 25% 资源)
│ ④ 能不造就不造;说不出口的假设单独记账
▼
能买不造(10 倍价差) + 假设清单(每 10 行代码一条)
图说:①→④ 层层递进:问题定义错了,后面全白干;
就算定义对了,不摸到实物,用户自己也说不全。
3. 核心原理
3.1 主走查:一栋楼的电梯,六种「解决方案」
书里最著名的一段,来自 Gause 与温伯格的书中案例,值得整段走完3:
场景: 一栋高层办公楼,住户抱怨等电梯时间太长。 工程团队的直觉方案是「让电梯更快」。但先停一下,问两个问题——
这是谁的问题?
| 站谁的角度 | 问题其实是 |
|---|---|
| 住户 | 我的时间被浪费了 |
| 房主 | 抱怨会变成退租,入住率和租金要跌 |
同一个现象,两个主人,两种「修好」的定义。
有哪些解法? 书里列了六条,我们补上量级感(成本数字是为演示编的,用来说明「差多少」):
| # | 解法 | 成本量级 | 风险 | 生效前提 |
|---|---|---|---|---|
| 0 | 提高电梯速度(直觉方案) | 高(几十万级改造) | 施工停运 | 物理上还提得动 |
| 1 | 新增一部电梯 | 最高(百万级,还要打洞) | 建筑结构 | 井道位置存在 |
| 2 | 错峰安排上班时间 | 低(管理成本) | 租户不配合 | 房主说得起话 |
| 3 | 给快递/货运保留专用电梯 | 低 | 快递员绕路 | 货梯存在 |
| 4 | 提高租金,接受低入住率 | 负(还增收) | 市场行情 | 房主肯认 |
| 5 | 改进电梯的归位算法(闲着的电梯自动移到需求大的楼层) | 最低(改代码,2 人周级) | 程序缺陷 | 电梯系统可编程 |
(归位算法:让闲置电梯「住」在历史需求高的楼层附近等活,而不是固定回底层。)
六条解法的成本、风险、生效时间差出几个数量级——而它们解决的都是同一个「抱怨」。 书里给出的收束句是本章的题眼:方案的变化总是比构建系统的成本低3。 在纸上多列五个方案只花一下午;选错了再盖楼,花的是解法 1 的百万级。
走查的结论: 需求错误的根源,是在「这是谁的问题」都没回答时,就冲向了第 0 号方案。 工程师的通病是「匆忙提供解决方案」——问题对的时候方案灵,问题错的时候方案越努力越错3。
3.2 真实需求不在嘴上:尽早交付
就算问题定义对了,还有第二层坑:用户自己也说不全他要什么。 作者的原话很直接:需求阶段你再怎么努力,都不如给他们一个东西用——用,才是确定真实需求的最有效方法4。
传统做法(书里叫瀑布式开发:一口气从需求走到测试、中间不回头的流程)的问题用数字看得最清楚: 99% 的开发资源(人手、钱、时间)已经耗尽之后,客户才第一次见到产品——所有反馈都发生在改不动之后4。
书里给的替代路径,把第一次见面提前到了资源消耗 5%~20% 时: 先快速拼一个粗糙的原型(能跑、能点、能看,但内部马虎的样品),交出去,收反馈, 然后才写正式的需求规格说明、开始正规开发4。
作者 2021 年复审时补了一段现身说法,等于给这条原则盖了章: 他后来创业,「向客户提供一系列不断增大的最小可行产品(MVP)以获取反馈」至关重要—— MVP 指只带最核心功能、足够验证方向的最小版本5。
配套还有一条「弄清优先级」的纪律(原则 130):很可能,客户只要能按时拿到必需的 10% 的功能, 就可以忍受其余 90% 晚拿到——作者的感叹是「一定要弄明白!」6。 这句话把「尽早」的目的说穿了:早交付不是为了交差, 是为了把「客户眼里真正的 10%」问出来——而这个问题,坐在会议室里是问不出来的。
3.3 所以第一个系统要扔:做好抛弃的准备
既然第一次交付的目的是「学」,那么第一个系统大概率不合格。这条原则的历史很硬: 第一个被完整部署的系统,往往是第二个被创建的系统——这话是 Royce 1970 年说的, Brooks 后来在《人月神话》里压缩成那句著名的「无论如何,你一定要做好抛弃的准备」7。
而且它有预算口径:Royce 建议,拿大约 25% 的资源做这个用来学习、注定被扔的预发布版本7。 按 100 人月的项目算,就是 25 人月买到「关键设计问题提前暴露」——对照第 02 章的兑换率, 这是全项目性价比最高的一笔支出。
3.4 抛弃也要讲方法:两种原型
「做原型」不是一句口号,作者把它拆成两类,选错类型会白花钱8:
| 一次性原型 | 演进式原型 | |
|---|---|---|
| 建法 | 快速、粗糙 | 高质量 |
| 交出去干嘛 | 收集反馈,然后扔掉 | 收集反馈,然后一直改,改到贴近客户要的样子为止 |
| 什么时候用 | 关键特性还没被理解时 | 关键特性已被理解、次要特性还不清时 |
| 做哪些特性 | 只做没被理解的(做已理解的是浪费) | 先做已被理解的(用它们引出其余需求) |
| 做多快 | 越快越好:一页纸需求、不写设计文档、什么工具顺手用什么9 | 正常质量标准 |
配套的一条:用户界面这种「一眼定生死」的东西,原型法收益最大—— 用故事板(把一串屏幕画面串成可点的演示)让用户在全面开发前先「用上」界面,既确认需求又赢得人心10。
3.5 能买不造:10 倍的价差
就算要造,也先问一句:真的要从零造吗?
原则 17 的账是这样的:现成软件通常只能解决你 75% 的问题——听着不甘心。 但自己造的对照项是:至少 10 倍于购买的价钱,还要冒着超支 100% 和延期的风险(如果最终能交付的话), 而交付物「能满足的需求,也许跟现成软件差不多」——因为成本上涨逼你砍需求,砍到最后剩下的就是那 75%11。
新项目最迷人的错觉是「我们的情况特殊,值得从零写」。这条原则的深层版本是复用: 在团队里问一句「谁做过能干 X 的组件」,找到就适配来用——作者管这叫「废物利用」,不用大投资也能开始复用12。
3.6 把没说出口的记账:记录你的假设
最后一层:就算问题对了、原型用了、能买的也买了,系统仍然是对世界做的一组简化。 Lehman 给了个量级:大约每 10 行代码,就会做出一个假设——偏差两三倍也是每 20~30 行一条13。
(假设:你认为「世界是这样」所以 没写进文档的前提。比如「用户不会同时提交两个请求」。)
他讲的故事值得复述:一台直线加速器(放疗设备)表现不如预期,物理学家提议——会不会和月相有关? 所有人都说「你开玩笑吧」。结果把月球因素算进去后,方程解释了大多数「不正确」的行为13。 连月相都能咬人,何况「假设用户网速够快」。
作者开的方子不是「管理所有假设」(做不到),而是:凡是你有意识做出的假设,写下来; 连同它的影响一起写——理想情况下,把每个假设封装在系统的一小块里,世界变了只改那一小块 (这个「封装」的机制,第 06 章专讲)13。
3.7 顺带一提:需求错了,估的工期必然错
这一章收尾前,把钩子挂到第 10 章:作者引的调查显示,成本估算错误的前 5 个原因, 全部与需求有关——频繁变更、清单不全、沟通不足、规格低质、分析不充分14。 「需求为什么会错」不仅是质量问题,它直接污染工期和预算。
4. 作者的判断与证据
| 说法 | 谁的 | 证据 |
|---|---|---|
| 方案的变化比构建便宜 | 作者引 Gause/温伯格案例3 | 思想实验(六解法对比),非统计数据 |
| 99% vs 5%~20% 的资源点 | 作者对比瀑布与原型4 | 流程结构推算(不是实测样本) |
| 第一个系统要扔、25% 预算 | Royce 1970,作者转述7 | 经验法则;流传 50 年 |
| 每约 10 行代码一个假设 | 作者引 Lehman13 | 经验量级,作者注明「偏差两三倍」 |
| 前 5 个估算错误全在需求 | 作者引 Lederer/Prasad 调查14 | 调查数据(样本书里未给) |
判断(我们的,不是书里的): 「尽早交付看得见的东西」这条原则,今天最普遍的执行方式就是 MVP 加灰度发布; 但它有一个书里没说的暗面——过早的实物会锁死用户的想象力(第 11 章那条「看到越多,需要越多」 在反方向同样成立:给什么,用户就以什么为基准想问题)。 原型的形状(粗糙还是精致、给哪几个功能)本身就在替用户回答「可能是什么」。 如果错,会错在: 如果用户对目标域的理解本来就比开发者深,那么任何「引导式」的原型都只是多余的误导, 直接给工具和自由度反而更好——判据是:这个用户群以前有没有用别的方式表达过需求。
5. 边界与局限
- 「25% 做预发布版」是大系统的口径。 小项目照搬就是浪费;书里说的是「全新领域」的程序7, 成熟领域里复制既有模式,第一个版本就靠谱得多。
- 「能买不造」在 1995 年是买「套装软件」,今天是买云服务与开源(源码公开、 允许自由使用与修改的软件)组件——价差逻辑没变, 但新代价(供应商锁定、依赖的组件本身出事故)书里没有,需要自己记入风险账。
- 一次性原型「不担心质量」有严格边界:它只对「注定要扔的东西」成立。 把原型当演示、然后被客户逼着「就这样上线吧」,是这条原则最常见的事故现场(第 02 章 3.6 的「质量无法事后补」)。
- 「每 10 行一个假设」没有给出可执行的管理密度。 写下所有假设仍是理想态;作者自己退了一步: 只要求有意识的假设写下来13。
6. 可带走的
- 接到需求先问「这是谁的问题,他图什么」——同一栋楼的电梯,住户和房主的「修好」是两件事;
- 在纸上把方案列全再动手:方案的变化总是比构建便宜,六个解法能差几个数量级;
- 第一次交付越早越好:99% 资源烧完才见客户,还是 5%~20% 就见,是两种命运;
- 全新领域的第一版按「会扔」预算:25% 资源买「提前暴露致命设计问题」;
- 原型分两种:没理解的用一次性(越糙越快越好),理解的用演进式(直接长成产品)——选错类型白花钱;
- 能买不造:75% 的现成方案,好过 10 倍价钱造出一个(因砍需求而缩水的)75%;
- 每 10 行代码一个假设——有意识的那部分,连影响一起写下来;
- 需求质量直接决定估算质量:估算错,先查需求。
7. 原文地图
| 主题 | 原书章 | 原文位置 |
|---|---|---|
| 三种徒劳的希望、立即确定需求 | 第3章 需求工程原则 | text/15-ch03.txt:43(搜「徒劳」) |
| 电梯问题(谁的 problem/六解法) | 第3章 需求工程原则 | text/15-ch03.txt:33(搜「电梯」) · text/15-ch03.txt:35(搜「归位算法」) |
| 方案变化比构建便宜 | 第3章 需求工程原则 | text/15-ch03.txt:35(搜「变化总是比」) |
| 尽早交付(99% vs 5%~20%) | 第2章 一般原则 | text/14-ch02.txt:61(搜「99%」) |
| 做好抛弃准备、25% 资源 | 第2章 一般原则 | text/14-ch02.txt:91(搜「抛弃」) · text/14-ch02.txt:95(搜「25%」) |
| 两种原型的选法 | 第2章 一般原则 | text/14-ch02.txt:45(搜「一次性」) · text/14-ch02.txt:107(搜「充分理解」) |
| 一次性原型要快 | 第2章 一般原则 | text/14-ch02.txt:123(搜「一页纸」) |
| 故事板降低界面风险 | 第3章 需求工程原则 | text/15-ch03.txt:77(搜「故事板」) |
| 能买不造(75%/10 倍) | 第2章 一般原则 | text/14-ch02.txt:163(搜「75%」) |
| 废物利用式复用 | 第4章 设计原则 | text/16-ch04.txt:279(搜「废物利用」) |
| 每 10 行一个假设、月相故事 | 第2章 一般原则 | text/14-ch02.txt:191(搜「每10行」) · text/14-ch02.txt:191(搜「月球」) |
| 客户优先级(10% 必需) | 第7章 管理原则 | text/19-ch07.txt:41(搜「10%」) |
| 估算错误前 5 因在需求 | 第3章 需求工程原则 | text/15-ch03.txt:13(搜「前5个」) |
| 作者 2021:MVP 实践 | 作者序 | text/08-fm.txt:37(搜「MVP」) |