1. PRD评审的适用场景与目标：识别评审时机、明确评审目标、确定评审范围

1.1 适用场景

PRD 评审并非“一刀切”活动，需根据研发阶段与需求规模判断是否触发。核心触发场景包括：

• 版本规划节点： 季度/月度版本立项时，进入评审区域；单独大特性开发前必须评审。
• 需求复杂度临界点： 单个用户故事拆分后超过 3 个验收条件，或涉及跨系统变更。
• 风险控制点： 涉及资金、隐私、合规、核心流程变更时，强制组织正式评审。
• 非正式场景： 小型优化、Bugfix 可不组织正式会议，但需技术预审 + 邮件确认。

1.2 前置条件

1. PRD 文档已锁定冻结： 评审前 24h 文档冻结，禁止评审期间修改。
2. 自查清单已运行： PM 完成 PRD自查清单（AC标准、流程图、数据字典、异常状态）。
3. 核心干系人已预约： 至少包含开发 TL、QA lead、UI 设计师（如涉及前端）。
4. 内部预审已通过： 需求分析师或产品组长已完成逻辑初步审查。

1.3 操作步骤（SOP）

1. 识别评审时机： 在需求拆解完成后、设计阶段入场前，检查版本规划日历与风险清单。
2. 明确评审目标： 确认是否“通过”、“驳回重写”或“条件性通过”；输出结论。
3. 确定评审范围： 在评审邀请函中标注边界（哪些需求纳入、哪些预留至下一期、哪些已弃用）。
4. 分发材料： 提前 24h 在知识库中发布 PRD、原型、影响域分析文档。
5. 执行会议： 按“顺序通过”模式验证每批需求。
6. 记录纪要： 即时记录每个模块的结论、待办负责人、DDL。
7. 签发决议： 会后 4h 内发出会议纪要，如有驳回则进入返工流程。

1.4 输入输出物

1.5 责任边界

• 产品经理（Owner）： 准备评审材料、控制会议节奏、裁决需求优先级分歧。
• 开发 TL： 评估技术可行性、实现成本、现有模块影响。
• QA lead： 确认需求可测试性、验收条件覆盖率。
• 设计师： 如果涉及 UI/UX 变更，需提供设计稿一致性验证。
• 主持人（可轮值）： 控制时间盒（60min/场）、避免死锁讨论。

1.6 记录材料

评审工单模板：
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 评审ID: REQ-2025-001
 模块: 用户登录
 评审日期: 2025-01-15
 评审结果: □通过  ■条件通过  □驳回
 关键待办:
  - [#1] 补充token过期策略 (Owner: PM, DDL: 01-17)
  - [#2] 确认第三方SDK包大小超限 (Owner: 开发TL, DDL: 01-18)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

1.7 异常处理

1. 超时未冻结： 若 PRD 在评审前仍有修改，主持人有权推迟会议；仅允许修正错别字。
2. 关键角色缺席： 若开发 TL 或 QA lead 缺席，会议降级为“需求说明会”，不计入正式结论。
3. 争议死锁： 超时 5 分钟仍未达成一致，暂停该议题，指定单独研讨会 PM 与开发 TL 线下决议。
4. 事后发现遗漏： 评审通过后若发现重大逻辑缺陷，PM 必须申请重开评审，不可直接合入开发迭代。

1.8 验收标准

• 每个需求模块至少有 1 位开发与 QA 签字认可。
• 所有待办事项必须设置责任人、到期日、验收人。
• 评审后 PRD 版本号 +1（如 v1.0 → v2.0），差异记录可追溯。
• 跨系统边界在评审纪要中有明确界定（如“此功能不包含支付通道二期”）。

1.9 评审时机与目标框架图

1.10 常见避坑提示