1. PRD评审概述与核心价值
1.1 章节导语
PRD评审不是“走过场”或“读文档”的仪式，而是一次跨职能对齐共识、暴露风险、降低返工成本的关键决策节点。缺乏评审或评审流于形式的产品，在开发阶段会出现大量需求漏洞、逻辑冲突、实现歧义，最终导致交付延期、质量下降。本章从流程SOP视角，明确定义评审的目标、角色分工与节点设置，为后续章节的常见问题与应对策略奠定结构基础。
1.2 适用场景
- 新功能或模块的PRD初次定稿，待进入技术设计阶段
- 重大需求变更导致PRD逻辑重构
- 跨团队协作项目（涉及多个后端/前端/数据团队）
- 高合规或高风险领域（支付、权限、数据隐私）
1.3 前置条件
- PRD已完成业务方确认，关键逻辑无悬而未决的争议
- 文档已通过产品负责人初筛（格式、完整度、核心流程）
- 评审材料（PRD文档 + 流程图 + 原型/线框图）提前至少24小时发出
- 参会角色已锁定，会议邀请包含明确的评审议程
1.4 评审目标
核心目标：对齐价值 → 验证可行性 → 检查完整性 → 暴露风险 → 输出决议。
具体分解为五个子目标：
- 价值对齐：PRD描述的功能是否解决了真实用户问题，是否符合业务目标
- 逻辑一致：需求内部是否自洽，边界分支是否被覆盖
- 技术可行性：开发评估可实现性，识别隐藏的技术债或依赖
- 完整可测：测试视角判断场景完备性、验收标准是否可量化
- 风险暴露：提前发现延迟、资源、第三方依赖等非功能风险
1.5 角色分工与责任边界
| 角色 | 评审核心职责 | 责任边界 |
|---|---|---|
| 产品经理 (PM) | 主持评审，讲解PRD，记录问题与决议 | 需求完整性与业务价值的第一责任人 |
| 开发工程师 (Dev) | 评估技术实现方案、识别依赖与约束 | 技术可行性、实现成本预估 |
| 测试工程师 (QA) | 检查验收场景完备性、竞品分析测试点 | 测试覆盖率、边界条件识别 |
| 设计师 (UX/UI) | 确认交互逻辑与PRD的一致性，交互与文案规范 | 交互合理性与视觉完整性 |
| 项目/项目经理 (PMO) | 评审排期、资源依赖、里程碑对齐 | 项目节奏与风险管控 |
| 业务方 / 运营 | 确认功能是否符合业务预期，提供最终决策视角 | 业务目标达成度 |
1.6 评审节点
标准产品流程中，PRD评审至少出现在以下三个节点之一，不可滞后：
- 需求评审（功能/逻辑层面）—— 产品经理主导
- 技术架构评审（技术实现层面）—— 开发主导
- 交互/视觉评审（用户体验层面）—— 设计主导
理想情况下，需求评审应当先于技术评审，避免在技术评估阶段发现结构性问题导致大面积返工。
1.7 PRD评审流程结构图
1.8 输入输出物
| 阶段 | 输入 | 输出 |
|---|---|---|
| 评审前 | 完成品PRD（含原型/流程图）、评审预约、参会人确认 | 评审会议议程、PRD附件抄送 |
| 评审中 | PM讲解 + 参与者提问 + 现场讨论 | 评审纪要（问题清单 / 决议 / 待办项） |
| 评审后 | 评审纪要 + 修改后的PRD（如有） | 基线锁定PRD + 相关Jira/Tapd条目 |
1.9 记录材料
- 评审纪要模板：会议时间、参会人员、评审结论、问题列表（编号/描述/负责人/状态）、待处理事项
- 附件：评审期间产出的草稿流程图、逻辑补丁截图、会议录音（可选）
- 决策记录：有条件通过的需记录具体补提交条件
1.10 异常处理
典型异常场景：
- 评审超时：超出预定时间仍有大量未覆盖项 → 暂停会议，标记未评审章节，另约续会
- 角色缺席：关键角色（如核心开发/测试）不在场导致无法决议 → 延期评审，重新排期
- 争议无法当场解决：业务逻辑分歧或技术选型冲突 → 升级决策人（产品总监/架构师），会后48小时内输出结论
- 评审变成了“读文档”：说明准备不足或参与者未预读 → 停止评审，退回前置条件，要求与会者预读
1.11 验收标准
- 评审结束时有明确的评审结论（通过 / 有条件通过 / 打回）
- 所有驳回或待办项指配了具体责任人与完成日期
- PRD基线版本已更新并同步给所有参会者
- 评审纪要归档至项目Wiki或共享文件夹