需求清单不是功能列表，是一份可以吵架的合同附件
很多项目里的需求文档，是开发启动前三天赶出来的一张功能表：一行一个模块，一行一句话。写完发给开发方，双方确认，项目就算「需求阶段」结束了。这份文档后来通常有两个命运：开发做到一半被要求加功能，它被判定「没写清楚」；或者项目做完了，业务方说这不是他要的，它被判定「执行不力」。
问题出在这份文档的身份上。它被当成了一份介绍材料，而不是一份可执行、可追溯、可变更的约定。
一份合格的需求清单，本质上是一份可以拿来吵架的依据——当三个月后有人说「这个功能我早就说过了」或者「这个功能你没说要」的时候，清单上有没有写、写在哪一条，决定了谁付钱、谁认账。所以需求阶段最值钱的产出不是把功能想全，而是把每一句话写成可判定的：成立或不成立，正确或错误，达标或不达标，不能是「体验良好」「响应快速」这种无法举证的描述。
这不是本文要讨论的重点。真正要讨论的是一个更有用的问题：在所有的项目失败原因里，需求问题到底占多大权重？这个问题国际上有过两次范围很大的量化调查，结论对所有做数字化项目的企业都适用。
45%：需求问题在失败原因里的真实权重
第三方研究机构 Standish Group 从 1995 年开始做了一项持续跟踪调查，样本覆盖全美范围内的 8000 个软件项目，输出通常被称为混沌报告。里面有两个数字应该被所有甲方记住。
第一个数字是超支幅度：未完成和未成功实施的项目，实际消耗的经费平均超出预定经费 189%，消耗的时间平均超出规定时间 222%。注意这里的基数——是「已经失败的项目」相对「原定预算」，不是全部项目。也就是说，一旦项目进入失败区间，代价是原计划的两到三倍。
第二个数字是需求相关原因的权重：分析失败原因后发现，与需求工程相关的因素合计占 45%，其中「缺乏最终用户的参与」占 13%、「不完整的需求」占 12%，这两项是最大的单一原因。
| 需求相关因素 | 权重 | 在实践中的典型表现 |
|---|---|---|
| 缺乏最终用户参与 | 13% | 需求由管理者凭想象写出，一线员工从未参与，项目验收时才第一次看到成品 |
| 不完整的需求 | 12% | 边开发边冒出新需求，且都以「这个很简单」的形式提出 |
| 需求理解偏差 | 10% | 双方对同一句话的理解不同，三个月后才发现分歧 |
| 需求优先级缺失 | 10% | 所有功能同等重要，于是所有功能都抢在最后做 |
| 需求相关因素合计 | 45% | 是所有因素类别中占比最高的一类 |
同一份报告里还有两个更狠的对照。在「十大成功保证」中，与需求直接相关的有三项，累计权重 37.1%；而在「十大败因」中，与需求直接相关的有五项，累计权重高达 51.6%。换句话说，需求做得好不好，同时是成功和失败的第一解释变量。
还有一组来自麻省理工学院系统与软件安全性项目组的研究结论值得注意：他们统计了大量与软件相关的事故，发现几乎所有软件相关事故都涉及软件需求问题。这条结论把需求从「钱的问题」升级成了「安全问题」——需求没写清楚导致的缺陷，不只是延期上线，它会在生产环境里变成事故。
所以有一句话对甲方是残酷的：你在需求阶段省下的每一行字，都会在开发阶段加倍还回来。这不是道德问题，是算术问题。
第一层：业务目标层——写不出来的目标就是没有目标
需求清单应该分四层来写，从上到下逐层具体。绝大多数项目只写了第二层，然后在后面几层反复扯皮。
第一层是业务目标层，回答「做完之后公司的哪个数字会变」。这一层最容易被写成口号，因为写口号不需要成本。「提升管理水平」「实现数字化转型」「打通数据壁垒」——这三句话都没有信息量，因为它们无法被证伪。
判断一条目标写得合不合格，有一个很硬的标准：它能不能挂到一个已有的经营指标上。如果答案是不能，那这条目标就还没写完。
| 写得不合格 | 写得合格 | 差别在哪 |
|---|---|---|
| 提升客服效率 | 售后工单的平均首次响应时长从 6 小时降到 2 小时以内 | 后者可以被测量，也可以在验收时被判定 |
| 减少库存积压 | 呆滞库存金额占库存总额的比例从 18% 降到 12% 以内 | 后者有明确的口径和基线值 |
| 让老板看到全局数据 | 管理层在每周一上午 9 点前无需追问即可看到上周全店经营数据 | 后者把「看到」这件事变成了可验证的交付 |
| 实现数据打通 | 销售系统与生产系统的订单状态每天凌晨自动同步一次，无需人工导出 | 后者同时写清了频次和「无需人工」这个约束 |
这张表的用法是：写不出右边那列，说明左边的目标还没想清楚。在这个阶段卡住是好事——卡住的成本是一次会议，放行到开发阶段的成本是整个项目。
还要注意一件事：第一层最多写三条。如果业务方能列出七八个目标，那实际上没有目标，因为没有优先级就没有取舍，没有取舍就意味着每个目标都会以最低标准被实现。
第二层：功能层——每条需求必须能被测试否证
第二层是功能层，也就是大家通常理解的「需求清单」主体。这一层的唯一标准是：每一条都写成系统可观察的动作，而不是业务方的愿望。
检验方法很简单：把每一条需求交给一个没参与过讨论的人，问他「怎么算做到了」。如果他的回答包含「基本」「大致」「比较」「良好」这类词，这条需求就是废的。
功能层写作里有四条实操规则，每一条都对应一类高频返工：
- 写主语和动作，不写名词。「订单管理」不是需求，「销售可以按客户、按时间区间、按状态三种条件组合查询订单」才是需求。前者是模块名，后者才是可开发的东西。
- 写边界，不写正面。「支持导出」没有边界，「支持导出当前筛选结果下的全部字段，包含附件下载链接，导出文件为可被 Excel 直接打开的格式」才有边界。
- 写异常，不只写正常流程。列表页、审批流、报表这三类需求，返工几乎全部来自异常分支：没数据时显示什么、并发提交怎么处理、外部接口超时怎么办、数据被删了记录还在不在。
- 一条需求对应一个可验收的动作。如果一条需求里出现了「并且」「同时」「另外」，大概率应该拆成两条。合在一起写的需求，在验收时会变成两倍的扯皮。
这四条不是本文的发明，它们是需求工程领域最基础的可测试性要求。而它们之所以重要，是因为需求文档的最终用途不是指导开发，而是作为验收依据——一年后回头争议「这个功能做没做到」，靠的是需求文档，不是靠记忆。
第三层：非功能层——最容易被漏掉也最难补做的一层
第三层是非功能层：系统「要多好」，而不是「要能干什么」。这一层是需求清单里漏得最多、事后补得最贵的一层。
原因很直接：非功能需求不写，不影响开发启动；非功能需求后写，要改已经写好的代码。项目进行到一半补一条「系统要支持 500 人同时在线」，代价可能是重做整个数据层，而不是加一个配置项。
非功能层至少要写清这七类，每一类都有明确的可判定值：
| 类别 | 必须写清什么 | 不写的典型后果 |
|---|---|---|
| 性能 | 哪些操作要求在多少时间内返回，是平均值还是最高值，在多少人同时在线时测 | 上线后被认为「太慢」，但因为没有基准无法判定是否违约 |
| 可用性 | 允许的宕机时长，维护窗口在哪一段，宕机由谁通知 | 出故障时责任无法界定，双方各自举证 |
| 数据量 | 三年内预计积累多少条记录，按什么增速推算，是否需要分表或归档 | 数据库在第二年突然变慢，重构成本极高 |
| 兼容范围 | 要支持哪些终端、哪些浏览器、哪些打印设备、最低系统版本 | 兼容问题在验收阶段集中爆发 |
| 安全 | 谁能看到哪部分数据，密码策略，敏感字段是否脱敏，日志留存多久 | 默认按最严格的方式做，成本被无谓放大 |
| 备份 | 备份频率、保留周期、恢复时间目标、恢复演练由谁做 | 出事故才发现备份文件也存在，但恢复要两天 |
| 可维护性 | 源码是否交付、文档交付到什么程度、部署环境由谁掌握 | 供应商离场后系统成为黑盒 |
这七类里最值得甲方提前想清楚的是「数据量」和「可维护性」两项。前者决定了架构，后者决定了这套系统在三年后还是不是你的资产。数据量这一项经常被写成「按实际情况」，这等于没写——正确写法是拿现在的数据量乘以一个明确的增长倍数，并把这个倍数写进合同。
第四层：约束与边界层——把「以后再说」变成「现在写明」
第四层是约束与边界层，它不描述系统应该有什么，而是写明它明确不做什么、什么条件下要改、以及改动怎么计价。
这一层是四层里最被低估的。它的存在意义是：把项目里最可能吵架的六类问题，在开工前用文字定死。
- 明确不做的清单。把「本期不做」的功能一条条写出来，并写明「什么条件下会纳入下一期」。没有这张清单，本期结束时的验收争议会集中在这里。
- 依赖的边界。系统要对接哪些外部系统，每个外部系统由谁负责提供接口，对接不通算不算延期理由。这一条极其重要——很多项目延期到最后一刻，双方才发现依赖方还没到位。
- 数据来源的边界。业务数据从哪来，谁负责保证数据的完整性和及时性。如果数据源是手工维护的表格，那系统的自动化程度就受限于填表的人。
- 上线的前置条件。服务器、账号、域名、备案、员工培训、线下流程调整——把这些列成清单并标注责任人，因为它们绝大多数不在开发方的控制范围内。
- 验收的判定方式。谁来验、验多久、验不过怎么办、谁有权最终判定。这一条不写，验收就会变成一场辩论赛。
- 变更的处理流程。谁有权提出变更，怎么评估影响，工期和费用怎么调整。
这六条对应着甲方在项目里最常见的三种失控：范围失控、依赖失控、验收失控。它们的原因都是同一件事——在开工前没有把话写下来。
需求变更：唯一必须留出弹性的部分
有一个常见的要求是「需求要一次定死，定了不许改」。这个要求在理论上正确，在实践中有害。
按上文那份 8000 个项目的调查数据，失败项目平均超支 189%、超期 222%。但这些数字的成因不只是需求没定清楚，还有另一半：业务在项目过程中发现需求确实需要变，而当时没有一套处理变异的机制。需求一变，要么停下来等，要么偷偷做，两种做法都会让项目变形。
正确的做法是：需求应当可变更，但变更要走流程、要重新估算、要双方签字。这和「不许改」是相反的两件事。
关于变更，有三条实操建议：
第一，变更必须换东西，不能加东西。增加一个功能意味着要减少别的功能或者延长时间。如果不换，就一定会延期——这不是执行力问题，是算术问题。
第二，变更的估算要基于清单而不是口头。说「这个改动很简单」是没有任何信息量的判断。判断一个变更的大小，要看它触及四层结构里的哪几层：只改功能层是小的，改到非功能层（比如新增一类终端）就是大的，动到第一层（业务目标）则意味着要重新对齐。
第三，设一个变更预算的上限。比如把合同总额的百分之十作为变更预留，超过这个数就要重新审视整个项目范围。这是一个很有效的强制机制——它逼着双方在早期就把范围谈清楚，而不是留到最后算总账。
换算到枣庄：四类项目的需求清单差异
四层结构是通用的，但每类项目真正该花时间写的层不一样。下面这张表给出四类常见项目的权重建议：
| 项目类型 | 最该花时间的层 | 最容易被漏的层 | 一句话判断标准 |
|---|---|---|---|
| 企业内部管理系统 | 第三层非功能与第四层约束 | 第一层业务目标 | 写不出能挂到经营指标上的目标，说明需求会无限膨胀 |
| 面向客户的线上系统 | 第一层业务目标与第二层功能 | 第四层约束 | 没有写「本期不做什么」，验收阶段一定扯皮 |
| 与既有系统对接的集成项目 | 第四层依赖边界 | 第二层功能 | 外部接口的责任方没写明，项目延期无法归因 |
| AI 与自动化类项目 | 第一层目标与第四层止损条件 | 第三层非功能中的准确率口径 | 「效果好」不是指标，需要在开工前定义什么情况下算失败 |
这张表最后一列的最后一句值得单独说：AI 类项目最常见的需求缺陷，是没有定义失败。传统软件的需求清单默认「系统会做对，只是做得好不好」，而 AI 类项目的现实是准确率天然不完美。所以在需求阶段就必须写清楚：准确率到什么水平算达标，什么情况算试点失败，什么情况下停止投入。这一条不谈清楚，项目就永远处在「再试一段时间」的状态里。
另外三类项目各自有一个高频漏项：管理系统的漏项是「谁来维护数据」，客户系统的漏项是「异常流程」，集成项目的漏项是「对方接口变更了怎么办」。三个漏项的共同点是——它们都属于运营阶段的事，但都必须在需求阶段写下来。
结语：需求阶段省下的每一行字都会加倍还回来
回到开头那个数字：需求相关因素占项目失败原因的 45%，其中最大的两项是缺乏用户参与和需求不完整。这两项有一个共同点——它们都不是技术问题，都是可以在两周内用会议和文档解决的组织问题。
但现实是这两项被跳过的频率极高，原因通常是「先做着，做到哪儿说哪儿」。这个做法在项目早期确实省事，代价在第 90 天到第 180 天之间集中兑现：范围失控、延期、超支、验收不通过，然后回到起点重新谈需求。
所以判断一份需求清单够不够用，只问三个问题：
第一，三个月后有人说「这个我早就说过了」，能不能在文档里找到对应那一条？
第二，验收的时候，能不能拿着文档一条一条判，而不是靠回忆和感觉？
第三，如果需求要变，谁有权力定、工期怎么算、费用怎么调，这三件事有没有写在纸上？
三个答案都是「能」，这份需求清单就已经值回它花掉的时间了。至于它有多长——四层结构写清楚的清单通常不会很短，但它的长度和它在开发阶段为你省下的时间相比，是个不需要争论的比例。
