评审前准备 SOP：前置条件、材料清单、预审机制

适用场景

本章 SOP 适用于以下四类典型场景，覆盖从常规迭代到紧急变更的全部评审前行动：

• 常规迭代评审：每轮 Sprint 启动前的 PRD 正式评审前准备。
• 跨部门需求评审：涉及研发、测试、运营、数据等多团队协作的需求评审前准备。
• 需求变更评审：已进入开发阶段的需求发生变更时，重新发起的评审前准备。
• 紧急上线评审：线上缺陷或业务紧急需求必须压缩评审周期时，按加速版 SOP 执行准备。

前置条件

以下五项前置条件必须全部满足方可进入材料清单准备环节，缺一不可：

1. 需求已冻结：产品经理确认本次评审的需求范围不再新增或变更，已与业务方达成书面共识。
2. 关键角色已确认参与时间：研发负责人、测试负责人、设计负责人、业务方代表均已回复评审会议邀请，确认时间无冲突。
3. PRD 版本号已固化：PRD 文档使用语义化版本号（如 v2.3.0），且评审前 48 小时内无未记录的重大修改。
4. 依赖项已对齐：涉及外部系统、第三方 SDK、数据中台等依赖项的评估结论已返回，无 blocking 级别的风险。
5. 评审环境就绪：评审所需的原型、交互稿、数据看板、测试环境等资源可正常访问，无需临时申请权限。

操作步骤

评审前准备共包含 6 个标准步骤，严格按照顺序执行，每个步骤完成后需由责任人签字确认：

输入输出物

评审前准备的输入输出物按照“材料清单”维度统一管理，具体如下：

责任边界

评审前准备涉及 5 类角色，各自的职责边界如下，严禁越权或职责缺失：

记录材料

评审前准备阶段需完整归档以下 4 份记录材料，作为评审质量追溯的原始凭证：

1. 《前置条件核验表》—— 记录五项前置条件的逐项核验结果、核验人、核验时间。
2. 《评审材料清单核对表》—— 记录所有输入输出材料的版本号、提交人、提交时间、审核状态。
3. 《预审问题清单》—— 记录预审中发现的全部问题，包含问题描述、严重等级（P0/P1/P2）、责任人、要求解决日期、最终解决状态。
4. 《材料修正记录表》—— 记录从预审结束到正式评审之间的所有修改条目，每次修改需注明变更原因、变更内容、影响范围。

记录材料的归档格式建议使用统一模板：

# 预审问题清单模板
## 问题编号：PR-2025-001
- 问题描述：【必填】清晰描述问题所在章节与具体内容
- 严重等级：P0（Block）/ P1（Major）/ P2（Minor）
- 提出人：【必填】姓名 + 团队
- 提出日期：【必填】YYYY-MM-DD
- 责任人：【必填】负责解决该问题的人
- 要求解决日期：【必填】YYYY-MM-DD
- 解决状态：待处理 / 已解决 / 已排期延后
- 解决备注：实际修改的内容或延后原因

异常处理

评审前准备阶段常见的 5 类异常及其处理策略：

验收标准

评审前准备是否完成，以以下 5 项验收标准全部达标为准：

• ✅ 前置条件全部满足：《前置条件核验表》中 5 项均为“通过”，且有责任人签字。
• ✅ 材料清单完整且版本一致：《评审材料清单核对表》中所有材料均标注为“已提交 + 版本一致”，无“缺失”或“版本冲突”。
• ✅ 预审问题已全部关闭或明确排期：《预审问题清单》中 P0 问题全部关闭，P1/P2 问题已有明确的解决方案和解决日期。
• ✅ 关键角色已确认参与：评审会议邀请已发出，研发负责人、测试负责人、业务方代表等关键角色的 RSVP 状态均为“已接受”。
• ✅ 评审就绪确认书已签署：评审组织者发布《评审就绪确认书》，各方确认无阻塞项，正式评审按计划进行。

流程总览：评审前准备 SOP 全景

以下 SVG 视图完整呈现了从“评审需求提出”到“评审就绪确认”的全流程，包含前置条件核验、材料准备、预审评审、材料修正循环以及最终的就绪判定：