第1章 PRD评审的全局价值与目标

PRD评审是产品研发流程中的关键质量门禁，也是团队对齐需求认知的核心协作节点。本章从全局视角出发，明确PRD评审的核心价值与目标，为后续流程改进和常见误区规避奠定认知基础。所有后续章节的操作细则、节点控制、冲突处理均围绕本章定义的三大目标展开。

1.1 适用场景

PRD评审并非每次需求变更都必须执行；以下四种典型场景必须启动正式评审流程：

1. 新产品功能PRD首次内部评审——需求从「概念」进入「规格」的第一道质量门禁，需要研发、测试、设计三方确认方案可行性。
2. 重大需求变更后的PRD修订评审——变更影响范围跨越两个以上模块或涉及核心逻辑重构时，必须重新评审修订后的PRD。
3. 跨部门/跨团队协作需求联合评审——涉及前端、后端、数据、运维等多团队配合的需求，需联合评审以消除接口与依赖盲区。
4. 关键里程碑节点的PRD复审——在迭代规划会前或发布前，对PRD进行整体复审，确保需求与业务目标一致、无遗漏。

1.2 前置条件

启动PRD评审前，以下四项条件必须全部满足，否则评审效率与质量将大幅下降：

• PRD文档已通过作者自检， 对照评审Checklist逐项核查，确保无明显的逻辑遗漏、数据矛盾或验收标准缺失。
• 评审议程已正式发布， 包含评审时间、地点/会议链接、预计时长（不超过90分钟）、各模块主讲人。
• 评审材料已提前至少24小时分发， 参与者有充足时间阅读PRD、标记疑问、准备反馈。
• 关键角色确认可全程出席， 包括研发主程、测试负责人、交互/视觉设计师；任一关键角色缺席，评审应改期。

1.3 操作步骤

PRD评审按以下四个阶段有序推进，每个阶段都有明确的退出条件：

1. 准备阶段（作者自检 + 材料封装）

   产品经理使用评审Checklist逐项核对PRD完整性，确认需求背景、功能描述、业务规则、验收标准、异常流程均已覆盖；封装评审材料包（PRD文档、交互原型、业务流程图、数据字典、验收用例）。

2. 预审阶段（关键角色提前对齐）

   在正式评审前48小时内，产品经理与研发负责人、测试负责人进行15-30分钟预对齐，解决明显分歧，筛选出需要全体讨论的核心议题，避免正式评审陷入基础信息拉扯。

3. 正式评审（结构化会议执行）

   按照「主持人开场（5min）→ 产品经理串讲（25min）→ 分模块讨论（40min）→ 结论汇总（10min）」的节奏执行；每个模块讨论后立即记录结论、待办事项与责任人。

4. 跟踪阶段（问题闭环与确认）

   评审结束后24小时内发布评审纪要，明确每个待办项的负责人与截止时间；产品经理在3个工作日内完成PRD修订，并触发二次确认流程。

1.4 输入输出物

1.5 责任边界

1.6 记录材料