评审会上被怼了三次之后,我把需求文档改成了这样

那是 2019 年冬天，我在一家给某公司做平台的产品负责人。项目已经跑了三个月，我终于把一份 47 页的《需求规格说明书》发了出去，心里还有点得意——流程图画了、字段表列了、原型链接也挂了，怎么着也算"详尽"。

评审会定在周五下午两点。会议室坐了八个人：甲方的业务科长、两个科员、我们技术总监、开发组长、测试组长，还有一位分管领导。

我开场讲了不到三分钟，业务科长把笔往桌上一放："小X，你这个审批流不对。"

我心里咯噔一下，脸上还挂着笑："哪里不对？"

"我们市区两级审批权限去年就调了，区局能批到 50 亩，你这里还是 20 亩。你这系统上线，等于让所有人按旧规矩走。"

开发组长接了一句："而且主数据从哪来？你这写了'对接现有系统'，现有系统是什么？接口文档我看了，没地址、没负责人、没字段映射。"

测试组长翻了翻打印稿："再有，这一条'支持复杂查询'，验收的时候什么叫复杂？是三个条件还是三十个条件？"

我那天被怼了整整三次。准确地说，是三次当众把文档里的软肋挑出来。会议室里安静了至少十秒，我听见投影仪风扇呼呼响。最后分管领导说了一句话："回去改吧，下周再看。"

出了会议室，我没立刻回工位，跑到楼梯间站在那发呆。

我反复看那 47 页。字很多、图不少，但全是"功能说明书"，不是"问题说明书"。我把 PRD 当成产品设计的答卷，却忘了它是多方协作的契约。

当天晚上我列了个清单，把这三句话拆开看：

业务科长说审批权限不对——说明我没区分组织层级和业务规则。我把"审批"写成一个统一流程，没画市区两级差异化的权限矩阵。

开发组长说主数据没来源——说明我在数据层偷懒。只写了"系统对接"四个字，没有数据源清单、没有接口 owner、没有 fallback 方案。

测试组长说验收标准模糊——说明我把验收当成测试组的事。PRD 里没有给定输入、预期输出、边界条件，评审会当然会被追问。

那次返工我们花了三周。不是小改，是推倒了大半本：

流程图重画，增加了 12 个岗位的权限矩阵表；补了 8 个数据源确认单，找了 5 个系统负责人签字；把原来"支持复杂查询"这种空话，拆成 36 条带输入样本和预期结果的验收用例。

项目最终延期了两周，但后面再也没出现评审会翻车。

从那之后，我的需求文档固定成三层：业务层、数据层、验收层。不是章节顺序，而是评审时每一类问题都要有明确答案。

第一层：业务层——先把"谁、在什么场景、凭什么决定"写清楚。我不再一上来就写功能列表，而是先写：角色、场景、决策规则、异常情况。比如审批流，先列"市局/区局/科室"三级权限，再写"超过权限自动上送"和"退回时抄送谁"。业务科长想看的是他熟悉的权力结构有没有被系统还原，而不是系统有多少按钮。

第二层：数据层——每个字段都要能找到妈。我在 PRD 里加了一张《数据来源与责任人表》：字段名、业务含义、来源系统、接口 owner、更新频率、缺数处理。开发组长拿到这张表，不需要再开会找人确认；测试组长也知道数据异常该找谁。最关键的一列是"缺数怎么办"——源系统故障时能不能手动录入、多久补录、是否影响审批，这些必须在设计阶段定。

第三层：验收层——把"能用"改成"按这个输入，必须出这个结果"。我以前写"支持按区域、年份、类型筛选"，现在写"选择'思明区+2023年+商业用地'，列表应返回 17 条记录，分页每页 20 条，耗时≤1.5 秒"。测试同事看到这条，不用猜，直接写用例。

除了结构，我还加了一个动作：评审前一天，把文档提前发给关键三方，各收集三个最担心的问题。评审会不再是第一次公开处刑，而是确认共识。

从那次翻车后，我在团队里推广这套写法，跑了大概十几个项目。有几个变化很明显：

需求评审一次性通过率从原来的 55% 提升到 82%；评审会后平均返工天数从 4.3 天降到 1.2 天；测试阶段因需求理解不一致产生的 bug 占比从 31% 降到 9%。

最直观的感受是：会议变短了。以前评审会动辄两小时，大家都在找文档里没写的东西；后来基本 40 分钟结束，因为该吵的架提前吵完了。

能过评审的需求文档，不是最长的那份，而是当别人想问"但是"时，答案已经写在纸上的那份。