第 8 课：需求评审与迭代

需求评审的参与方与关注点

PRD 写完不是终点，而是起点。一份没经过评审的 PRD，就像没经过测试的代码——你不知道它哪里有问题。

需求评审不是走流程，而是一次"找漏洞"的集体活动。不同角色看 PRD 的视角不同：

产品经理：逻辑是否自洽？用户故事是否完整？边界情况是否覆盖？
开发者：技术可行性如何？有没有隐含的技术复杂度？实现成本多大？
设计师：交互流程是否合理？信息架构是否清晰？有没有体验断点？
测试：有没有可测试的验收标准？异常场景够不够？数据边界考虑了没？

每个角色都在找不同维度的问题。一个好的评审，至少要覆盖以上四个视角。

如何做一次有效的评审

评审前

提前把 PRD 发给参与者，给他们时间读
明确评审目标：这次评审重点是确认方向还是补充细节？

评审中

让一个人按用户故事走一遍完整流程，其他人随时打断提问
记录所有问题，不要现场争论解决方案——评审是发现问题，不是解决问题
特别关注"你觉得呢？"这种模糊表达——如果有人这么说，说明他不确定但没想清楚怎么表述

评审后

把所有问题分类：必须修改、建议修改、待定
必须修改的立即改，建议修改的评估后决定，待定的标注后续跟进
修改后通知所有参与者，确保大家对最新版本有一致理解

处理需求变更的方法

需求变更不是坏事——如果变更是基于新的认知，那就是进步。问题是变更的管理方式。

处理变更的原则：

1. 评估影响范围

这个变更影响哪些功能？需要改多少代码？
对已有功能有没有副作用？
对上线时间有没有影响？

2. 判断必要性

这个变更是"必须有"还是"有了更好"？
如果推迟到下个版本，会怎样？
有没有更简单的替代方案？

3. 做决策并记录

每个变更都要有明确的结论：接受、拒绝、推迟
记录决策理由，避免以后重复讨论

一个常见的陷阱：把所有变更都当作"小改动"。很多"小改动"牵一发而动全身，改一个字段可能影响整个数据流。评估影响范围时，不要只看表面。

保持文档与代码同步

PRD 和代码的脱节是一个慢性病——PRD 改了但代码没跟上，或者代码改了但 PRD 没更新。时间一长，没人知道哪个是最新的。

在 AI 时代，这个问题变得更加严重。因为 AI 是根据 PRD 生成代码的，如果 PRD 过时了，AI 下一轮生成的代码就会基于错误的信息。

解决方法：

小步更新：每次变更后立即更新 PRD，不要攒一批再改
版本标注：在 PRD 顶部标注最后更新日期和版本号
变更日志：在 PRD 末尾维护一个变更记录——改了什么、为什么改、什么时候改的

这不是形式主义，而是让你的 PRD 始终是一个可信的、可以喂给 AI 的输入。

关键概念

评审是找漏洞，不是走流程：不同角色看不同维度的问题
需求变更不是坏事，但需要管理：评估影响、判断必要性、记录决策
文档与代码同步：PRD 过时 = 给 AI 喂错误信息

课后练习

模拟一次需求评审——把你的 PRD 给同事或 AI 阅读，记录他们提出的问题
根据反馈迭代 PRD——分类整理问题，修改必须改的部分
在 PRD 末尾添加变更日志