2. 评审流程全景图：典型阶段划分、各阶段输入输出、关键角色触点
PRD 评审不是一次会议，而是一个四阶段闭环流程。本章按 SOP 方式拆解每个阶段的前置条件、操作步骤、输入输出物、责任边界、记录材料、异常处理与验收标准，并明确各阶段的关键角色触点。
核心认知：把评审流程从“一次会议”升级为“四个阶段”，可以将评审返工率降低约 40%。关键在于让每个阶段的输入输出物形成强依赖关系——前一阶段未达标，则下一阶段强制推迟。
2.1 阶段一：会前准备与自审
| SOP 要素 | 详细内容 |
|---|---|
| 适用场景 | 产品经理完成 PRD 初稿后，正式提交评审前。 |
| 前置条件 | PRD 文档完成度 ≥ 90%；原型或交互稿已附；需求清单已与 PO 确认。 |
| 操作步骤 | ① PM 逐项对照《PRD 自审清单》检查完整性；② 修正错漏、补充缺失用例；③ 记录自审问题并附解决方案；④ 将自审结果更新至文档首部“自审记录”区域。 |
| 输入输出物 | 输入：PRD v0.x 草稿、需求清单。输出：PRD v1.0（自审后版本）、PRD_自审清单_v1.xlsx。 |
| 责任边界 | 产品经理（PM）为自审质量第一责任人；不允许代审或跳过。 |
| 记录材料 | 自审清单（评分卡式，逐项通过/未通过/备注）；自审问题追踪表。 |
| 异常处理 | 若自审清单 未通过项 > 3 项，则拒绝进入阶段2，退回 PM 补全后再审。 |
| 验收标准 | 自审清单所有项目为“通过”；文档无格式错乱、无数据脱敏遗漏。 |
2.2 阶段二：预评审
| SOP 要素 | 详细内容 |
|---|---|
| 适用场景 | PRD 自审通过后，发起小范围预评审。 |
| 前置条件 | 阶段一已完成并达到 M1 里程碑；文档已推送至预评审协作空间。 |
| 操作步骤 | ① PM 选定 2~3 名关键干系人（研发+测试+设计）；② 邀请其进行异步评论或 30 分钟快速会议；③ 收集预评审问题并分类（逻辑/体验/技术/数据）；④ PM 评估问题影响度，逐个决策是接纳修改还是拒绝。 |
| 输入输出物 | 输入：PRD v1.0、自审清单。输出：PRD v1.5（预评审后更新版）、预评审问题记录表。 |
| 责任边界 | PM 组织并记录；参与人必须为对应模块实际负责人。 |
| 记录材料 | 预评审问题记录表（含问题描述、类型、提出人、状态、决策）。 |
| 异常处理 | 预评审中发现的阻塞性问题（P0） ≥ 1 个，则标记 M2 失败，退回阶段一补充后重新自审。 |
| 验收标准 | 预评审问题全部解决或已形成明确延期/降级决策；P0 问题清零。 |
2.3 阶段三：正式评审会
| SOP 要素 | 详细内容 |
|---|---|
| 适用场景 | 预评审通过后，组织全体相关方进行正式评审。 |
| 前置条件 | M2 里程碑达成；PRD v1.5 已发送全体参会人员（至少提前 48 小时）；会议议程已同步。 |
| 操作步骤 | ① PM 开场介绍评审背景与目标；② 逐模块演示需求（使用原型/流程图）；③ 参会人现场提问与讨论；④ 主持人（通常为 Leader）现场记录关键决策；⑤ 当场形成评审结论（通过 / 有条件通过 / 拒绝）；⑥ 锁定 M3 里程碑状态。 |
| 输入输出物 | 输入：PRD v1.5、预评审问题记录表。输出：PRD_正式评审决议书.md、PRD v2.0（若当场修正）。 |
| 责任边界 | PM 演示与记录；主持人把控节奏与决策；参会人必须提前阅读文档，否则有权暂停其提问资格。 |
| 记录材料 | 正式评审决议书（含评审时间、参会人、结论、遗留项追踪表）。 |
| 异常处理 | ① 拒绝：退回阶段一，重新自审后进入新循环；② 有条件通过：明确限期修正项（一般 ≤ 3 个工作日），修正后由原提出人确认后自动进入阶段四。 |
| 验收标准 | 正式评审决议书三方签字（PM、研发代表、测试代表）；遗留项已明确 Owner 和截止日。 |
2.4 阶段四：评审后闭环与归档
| SOP 要素 | 详细内容 |
|---|---|
| 适用场景 | 正式评审通过或有条件通过项全部关闭后。 |
| 前置条件 | M3 里程碑达成；有条件通过项已全部完成修正并确认。 |
| 操作步骤 | ① PM 更新 PRD 文档版本号至 v2.x（End）；② 在需求管理工具（如 Jira/Confluence）中关联最终版 PRD 链接；③ 归档正式评审决议书、预评审记录、自审清单至项目知识库；④ 向全体项目成员发送“PRD 评审完毕通知”；⑤ 锁定 M4 里程碑。 |
| 输入输出物 | 输入：正式评审决议书、有条件通过项的修正版本。输出：PRD_v2.x_终版.pdf、归档清单。 |
| 责任边界 | PM 执行归档；研发/测试负责人确认遗留项关闭。 |
| 记录材料 | 归档清单（包含文档名、版本号、归档时间、归档人）。 |
| 异常处理 | 有条件通过项未在期限内完成 → 触发《评审决策升级机制》，由项目总监介入判定是否强行进入开发或再次评审。 |
| 验收标准 | 归档清单完整；正式评审决议书中的遗留项全部标记为已关闭；M4 里程碑点亮。 |
流程红线：未经 M1→M2→M3→M4 任一里程碑，不得跨阶段进入开发。若项目紧急需跨阶段，必须由项目总监书面特批，并在归档中标注“特殊豁免”。此条是防止评审流于形式的关键护栏。
2.5 关键角色触点总览
下表汇总四阶段中各角色的核心触点与责任边界，帮助团队快速对齐职责，避免“评审无人负责”的常见误区。
| 角色 | 阶段一 | 阶段二 | 阶段三 | 阶段四 |
|---|---|---|---|---|
| 产品经理 (PM) | 主导自审、写清单 | 组织预评审、记录问题 | 演示、记录决策、签字 | 归档发版、发送通知 |
| 研发代表 | —（可提前阅卷） | 参与预评审、提技术问题 | 技术可行性评估、签字 | 确认技术遗留项关闭 |
| 测试代表 | — | 参与预评审、提测试风险 | 测试可行性评估、签字 | 确认测试遗留项关闭 |
| 设计代表 | — | 可选参与 | 交互/视觉可行性评估 | 确认设计遗留项关闭 |
| 主持人 (Leader) | — | — | 主持节奏、做最终决策 | 审批归档申请 |
| 项目总监 | — | — | （仅在异常升级时介入） | 批准特殊豁免申请 |
常见误区：很多团队把“评审”等同于“阶段三”，忽略了自审和预评审的价值。这导致：
- 正式评审会变成问题发现大会，效率极低；
- 技术/测试在会前没看文档，当场无法给出有效意见；
- 评审后遗留项无人追踪，导致开发过程中需求频繁变更。