第 3 章：标准评审流程六步法

适用场景

本流程适用于所有需要进行正式技术决策与风险控制的 PRD 评审活动。具体场景包括但不限于：

• 关键里程碑评审：产品进入开发前的最终设计确认。
• 跨团队协同评审：涉及研发、测试、数据、风控、法务等多个部门的功能。
• 高风险需求评审：对支付、安全、数据一致性、业务流程重构等需求进行评审。
• 变更引入评审：对迭代中新增或大幅变更的需求进行追加评审。

前置条件

在执行标准流程之前，必须完成以下准备工作：

1. PRD 文档已通过自查清单，确保无低级错误（如错别字、缺失字段）。
2. 所有相关方角色（产品、研发、测试、设计、业务）已确认。
3. 评审会议室或线上会议链接已预订，且资料已提前2个工作日发出。
4. 决议人/关键决策者（如技术负责人、业务方负责人）确认可以出席。

核心流程六步详解

1. 发起评审：产品经理通过系统或邮件发出评审通知，明确时间、地点、参会人员及本次评审重点。
2. 预审：参会人员在正式会议前，花 30-60 分钟独立阅读 PRD，标注疑问点。此为“异步评审”环节，减少会议中基础问题的提问时间。
3. 正式评审：由产品经理主持，逐条过所有核心需求。此环节专注于“决策”与“澄清”，而非“教学”。
4. 问题记录：指定记录员将所有疑问、意见、待办事项记录在案。记录应明确“提出人”、“问题描述”、“解决方案方向”、“负责人”及“预计解决时间”。
5. 结论确认：评审结束时，由决策者对整体文档状态做出最终判断。
   • 通过：可直接进入开发。
   • 有条件通过：需修复特定问题且无需二次评审。
   • 不通过：需大改并重新发起评审流程。
6. 闭环跟踪：会后，产品经理需在规定时间内完成问题修改。测试及研发负责人需对修改结果进行确认，并在任务管理系统中关闭对应的缺陷或待办任务。

输入输出物

环节	输入物	输出物
发起评审	最终版 PRD 文档、会议邀请	评审议程表、预审通知
预审	PRD 文档	个人预审意见列表
正式评审	PPT 摘要、预审问题列表	澄清后的需求描述
问题记录	评审现场讨论内容	评审问题日志（必填项）
结论确认	评审问题日志、待办清单	评审结论单（通过/有条件/不通过）
闭环跟踪	评审结论单、修改后的 PRD	确认关闭邮件或系统状态更新

责任边界

• 产品经理：负责发起、组织、陈述、记录并推动修改。是流程的唯一发起人与主要执行人。
• 研发/测试：负责预审并提出技术可行性及测试用例层面的问题。具有一票否决权（针对技术不可实现或严重违反架构的需求）。
• 决策者（如技术负责人/业务负责人）：负责做出最终“通过/不通过”的裁决，并协调资源。

记录材料

必须记录的标准化文档包括：

• PRD_评审问题日志_v1.0.xlsx
• PRD_评审会议纪要_v1.0.md

日志模板示例（需包含列：序号、问题提出人、问题描述、所属章节、严重程度、处理人、状态、解决方案）：

| 序号 | 提出人 | 问题描述                  | 所属章节 | 严重程度 | 处理人     | 状态   | 解决方案                 |
|------|--------|---------------------------|----------|----------|------------|--------|--------------------------|
| 1    | 研发A  | 支付接口超时未定义兜底策略 | 第4.3节  | 高       | 产品经理B  | 处理中 | 增加5秒超时自动重试机制 |

异常处理

异常编号	异常描述	处理策略
A-01	关键决策者缺席	立即暂停评审，改期举行。预审意见收集后，由决策者书面确认。
A-02	评审现场长时间无争议	强制进行“红队演练”环节，指定一名测试人员故意提出极端场景问题。
A-03	问题记录超时	启动“2小时修订”机制：会后2小时内必须发出问题清单，否则视为评审失败。
A-04	结论分歧	引入仲裁人（一般为产品总监或技术总监），进行最终决策。

验收标准

本流程执行完毕后，必须满足以下标准方视为“完成”：

• 评审问题日志中所有“高/中”级别问题均已关闭或“确认延期”并附有原因。
• 输出明确的评审结论（通过/有条件/不通过），且有对应负责人签字或系统确认。
• 闭环跟踪记录中，修改后的 PRD 版本号已更新（例如：从 v1.2 更新至 v1.3）。
• 无遗留的“待定”或“未知”状态问题。

理解记忆：标准评审流程六步法（SVG 概览）