PRD评审场景识别与触发条件
本章是《PRD文档对齐跨团队共识的评审节奏教程》的开篇，帮助团队准确判断“什么时候应该启动一场正式的PRD评审”。错误的触发时机（过早或过晚）会导致评审流于形式、反复返工或临时插入非共识问题。本章围绕适用场景、前置条件、操作步骤、输入输出物、责任边界、记录材料、异常处理和验收标准八项要素，建立标准化的PRD评审触发判断机制。
学习前提：建议读者已经了解团队的产品开发流程（如双周迭代、阶段门模型），并拥有至少一次参与跨团队PRD评审的经验。本章不讨论评审的具体执行细节，只聚焦于“什么时候该评审”这一前置判断。
1.1 适用场景
PRD评审并非每一次PRD更新都需要启动。以下三类场景属于必须触发的典型情况：
| 场景编号 | 场景名称 | 典型特征 | 风险等级 |
|---|---|---|---|
| S1 | 新项目/新模块启动 | 从0到1，无历史PRD可参考；涉及多个后端/前端/数据/算法团队协作 | 高 |
| S2 | 重大功能变更 | 已有功能的交互逻辑、数据流、接口规范发生不可向下兼容的修改 | 高 |
| S3 | 跨依赖边界调整 | 变更影响超过3个团队，或涉及外部系统/第三方服务的依赖切换 | 中—高 |
除上述场景外，对于纯文案修正、字段命名统一、不影响接口/数据流的小型优化，可走“轻量级确认”（如群内确认或异步评论），不纳入本章定义的正式评审流程。
1.2 前置条件
在确认场景成立后，还需要满足以下四项前置条件，才能正式发起PRD评审请求：
- PRD草稿已通过产品负责人（PO）内部审查：产品侧已完成逻辑闭环、无明显的功能矛盾或缺失。
- 关键角色已确认参加时间：至少获得研发负责人、QA负责人、运营（若涉及）的会议时间承诺；不强制所有人都在，但缺席者需指定代表。
- PRD版本号已固化：当前版本已标注为评审候选版本，不再允许在评审前频繁修改核心内容。
- 基础依赖物料已就绪：例如原型图、数据流简图、接口定义表（或早期API文档）已随PRD附件提供。
⚠️ 常见陷阱：部分团队在PRD尚处于“想法阶段”就发起评审，导致会议变成“产品答疑会”。务必先完成前置条件 #4，至少保证参会者能通过阅读物料自行理解50%以上内容。
1.3 操作步骤
识别场景并确认前置条件后，按以下步骤完成触发动作：
- 步骤1：场景自检 – 产品经理对照“适用场景表”，判断本次变更是否命中S1/S2/S3。若命中，继续；否则降级处理。
- 步骤2：前置条件核验 – 使用检查清单（参见下表）逐项打勾，任何一项未满足则退回补充。
- 步骤3：发起评审请求 – 在团队协作平台（如Jira/Confluence/Trello）创建评审任务，标题格式：
[PRD评审] 项目名 - 版本号 - 触发场景编号。 - 步骤4：发送预读通知 – 评审会议开始前至少24小时，将PRD文档链接、评审议程（重点讨论模块、预期输出）发送给所有参会者。
- 步骤5：确认会议时间 – 与关键角色协调，锁定1.5小时的会议窗口（超出则拆分为多场）。
1.4 输入输出物
| 类型 | 输入物名称 | 输出物名称 |
|---|---|---|
| 输入 | PRD草稿（含原型 & 数据流图） | — |
| 输入 | 变更影响范围清单 | — |
| 输入 | 预读通知邮件/消息 | — |
| 输出 | 评审会议邀请 & 议程 | 已预约的日历事件 |
| 输出 | 评审触发确认单 | 场景编号 + 前置条件核验结果 |
1.5 责任边界
| 角色 | 职责 | 不可推卸的责任 |
|---|---|---|
| 产品经理 | 完成场景判断、前置条件核验、发起评审请求 | 确保PRD物料齐全、版本冻结 |
| 产品负责人（PO） | 内部审查PRD逻辑，确认满足评审条件 | 对PRD内部质量负责 |
| 研发团队代表 | 确认能够参加评审，并指派技术代表 | 不得在评审前临时取消或替换无法了解背景的人 |
| QA 代表 | 确认测试资源，提前反馈可测试性 | 帮助识别前置条件 #4 中的物料不足 |
1.6 记录材料
触发阶段需保留以下记录：
- 评审触发确认单（模板示例）：
【评审触发确认单】
项目名称：智能助手 v3.2
触发场景：S2（重大功能变更）
前置条件核验：
✅ PO内部审查完成（2025-04-07）
✅ 关键角色确认参加（研发/QA/运营）
✅ PRD版本：v3.2-rc1（已冻结）
✅ 物料就绪：原型图、接口定义表v1.0
发起人：张三（产品经理）
发起时间：2025-04-07 14:30
- 预读通知记录：聊天记录或邮件截图，证明满足24小时预读要求。
- 变更影响范围清单（建议使用表格或共享文档）：列出受影响团队、模块及预期改动范围。
1.7 异常处理
| 异常场景 | 处理措施 | 责任人 |
|---|---|---|
| 前置条件不满足 | 退回 PO 或产品经理补充，重新进入步骤2 | 产品经理 |
| 关键角色缺席且无代表 | 推迟评审至该角色可参加，或经 PO 批准降级为异步评审 | 产品经理 / PO |
| PRD在评审前24小时内频繁变更 | 冻结版本，变更内容追加到“修订记录”中，不影响评审主体；若变更导致逻辑产生新的依赖冲突，则取消评审，重新自检 | 产品经理 |
| 跨团队冲突导致会议不可协调 | 由PO升级至项目组高层或技术委员会裁决，指定决策者代表参与 | PO |
1.8 验收标准
本章内容的成功应用可通过以下标准衡量：
- ✅ 产品经理能够参照“适用场景表”在5分钟内判断是否需要触发正式评审。
- ✅ 每次评审发起前，关联的“前置条件核验清单”100%勾选完成。
- ✅ 评审触发通知发出后，24小时内未出现“物料不全”或“版本未冻结”的撤回情况。
- ✅ 评审会议实际召开时，参会者对PRD基本理解率达80%以上（通过会议开始时的快问快答抽样）。
📌 关键提示：触发阶段的质量直接影响整场评审的效率。如果触发条件判断不准或前置条件未满足，后续的讨论大概率会偏离评审目标。将本章SOP作为每个迭代的“门禁”，可以有效降低无效会议。