第 8 课：需求评审与迭代
模块二：需求定义与文档 | 第 8 课
课前思考
需求写好了，PRD 看起来很完整。接下来就该开发了吗？
还有一个关键步骤：让别人（和 AI）审视你的需求。 一个人在写 PRD 的时候，很容易陷入"我以为我说清楚了"的幻觉。需求评审的目的，就是在投入开发之前，让那些潜在的误解和遗漏暴露出来。
需求评审：为什么需要
需求评审的目标不是"让别人认可你的方案"，而是让问题在成本最低的阶段被发现。
问题发现的阶段和修复成本之间的关系：
| 发现阶段 | 修复成本 |
|---|---|
| PRD 评审时 | 改几行文字，5 分钟 |
| 方案设计时 | 调整流程，30 分钟 |
| 开发中期 | 重构代码，半天到几天 |
| 上线后 | 回滚 + 修 bug + 用户沟通 + 声誉损失 |
在 PRD 评审阶段发现一个问题，改几行文字的成本几乎为零。在开发阶段才发现，可能意味着大量代码重构。在上线后才发现，除了技术修复，还要加上用户沟通和声誉挽回的成本。
需求评审的三个维度
维度一：价值评审
- 这个需求解决了什么真实问题？（回顾灵魂三问）
- 目标用户会因为这个需求而使用产品吗？
- 不做这个需求会有什么影响？
价值评审关注的是**"该不该做"**。如果一个需求通不过价值评审，后面的评审就没有意义。
维度二：方案评审
- 这个解决方案是最简洁的吗？有没有过度设计？
- 有没有更简单的方式能达到同样的效果？
- 边缘情况和异常路径都考虑到了吗？
方案评审关注的是**"做得对不对"**。同样的需求，可能有完全不同的实现路径。评审时要特别关注是否存在过度设计——"杀鸡用牛刀"是需求评审中最常见的问题之一。
维度三：可行性评审
- 在现有技术栈下是否可以实现？
- 需要多少资源（时间、人力）？
- 有没有被忽视的技术风险？
可行性评审关注的是**"做不做得到"**。特别在 AI 辅助开发中，要确认技术方案是否在 AI 可靠执行的范围内。
如何进行需求评审
第一步：准备评审材料
不需要 PPT。把你的 PRD（特别是第一部分和第二部分）作为评审材料。确保包含：
- 需求背景和价值说明
- 用户故事
- 核心业务流程图
- In-Scope / Out-of-Scope
第二步：邀请正确的评审人
不同角色从不同角度审视你的需求：
| 角色 | 关注点 |
|---|---|
| 开发 | 技术可行性、是否过度设计、边界是否清晰 |
| 设计 | 用户体验是否合理、交互流程是否自然 |
| 业务方 | 商业价值是否成立、是否解决真实问题 |
| 测试 | 边缘情况是否覆盖、是否有遗漏的测试场景 |
如果是个人项目，至少让 AI 扮演这些角色帮你审视——"请你以资深前端开发的角度审视这份 PRD，指出可能的技术问题。"
第三步：结构化推进评审
- 讲背景（5 分钟）：为什么要做这个需求，解决什么问题
- 讲方案（10 分钟）：核心业务流程，关键设计决策
- 开放讨论（15-20 分钟）：收集各方反馈，不要急于辩护
- 汇总行动项（5 分钟）：明确哪些需要改，谁来改，什么时候改完
第四步：评审后跟进
记录所有反馈和决议，更新 PRD，标注版本号和更新内容。评审不是终点——评审后的跟进决定了评审的价值。
应对需求变更
需求评审通过 ≠ 需求不会再变。变化是常态，但如何管理变化决定了项目的健康度。
变更的来源
| 来源 | 举例 | 特点 |
|---|---|---|
| 用户反馈 | "能不能加个导出功能？" | 真实但可能不具有代表性 |
| 老板要求 | "竞品有了 XX 功能，我们也加" | 紧急但未必重要 |
| 技术限制 | "这个方案实现不了，得换一个" | 必须面对 |
| 自我发现 | "我觉得加一个 XX 会更好" | 警惕范围蔓延 |
处理变更的三步法
第一步：理解变更的真正原因。
不要直接接受或拒绝。先问：这个变更要解决什么问题？有没有其他更简单的方式达到同样的效果？很多时候，用户说的"加个功能"背后的真实需求可能用一个更简单的方案就能满足。
第二步：评估变更的成本和影响。
每个变更都有成本——开发时间、测试成本、对其他功能的连锁影响、对上线时间的影响。把这个成本明确地摆在桌面上，帮助所有人做出清醒的决策。
第三步：更新排期和范围。
决定接受变更后，要么延后上线时间，要么把其他不那么重要的功能延后。不接受"既要加功能又要不延期"的魔法思维。
学会说"不"
对于产品经理来说，说"不"是一项核心能力。
不是每个需求都值得做。一个好的拒绝不是简单的"不做"，而是带着逻辑："这个需求的核心诉求是 X，我们可以在 V2 版本中用 Y 方案来解决。现在的版本先聚焦在 Z 上。"
让 AI 帮你做需求评审
AI 可以作为一个非常有效的"评审助手"：
用 AI 审查 PRD 的完整性
"请以资深产品经理的角度审查这份 PRD：哪些信息缺失了？哪些描述有歧义？哪些边缘情况没有覆盖？"
用 AI 扮演不同角色提出挑战
"请你分别以（1）前端开发、（2）UI 设计师、（3）测试工程师的角度，审阅这份 PRD 并指出可能的问题。"
用 AI 检查一致性
"请检查这份 PRD 中的功能描述是否有前后矛盾的地方，以及 In-Scope 和 Out-of-Scope 的边界是否清晰。"
保持 PRD 与实现同步
PRD 不是写完就锁定的死文档，它应该随开发推进而更新。但一定要确保文档和实现的一致性：
- 重大变更必须更新 PRD。 如果开发过程中做了方向性调整，第一时间更新 PRD。
- 标注版本号和更新记录。 每个版本改了什么都记录下来，方便追溯。
- PRD 是单一事实来源。 当开发和 PRD 冲突时，要么改代码，要么改 PRD，不能两个都留着让后来的读者困惑。
模块二小结
恭喜你完成了需求定义与文档的 4 课。回顾一下：
- 第 5 课：与 AI 确认需求。AI 不会脑补，用"追问"和"确认模板"让 AI 显性化它的理解。
- 第 6 课：PRD 编写实战。五部分结构（文档信息 → 背景与目标 → 方案概述 → 细节方案 → 上线计划），初稿-中稿-定稿的迭代节奏。
- 第 7 课：可视化表达需求。Mermaid 流程图消除歧义，用户旅程地图定位情绪低谷，产品故事建立共情。
- 第 8 课：需求评审与迭代。让问题在成本最低的阶段暴露，学会说"不"，管理需求变更。
接下来进入模块三：产品开发协作——理解技术基础，学会与开发团队和设计团队有效协作。