第1章 PRD评审概述与SOP定位：评审目标、评审触发条件、SOP覆盖范围、核心交付物清单
PRD评审是需求从“写完”走向“可开发”的关键质量闸门。本章明确SOP的定位与边界，帮助团队统一认知：在什么场景下启动评审、需要哪些前置条件、SOP覆盖哪些环节、最终要产出什么交付物。以下内容按SOP标准结构展开，适用于产品、研发、测试、项目经理等所有评审参与角色。
1.1 适用场景
PRD评审SOP适用于以下四类典型场景，超出范围时应触发特殊流程（见1.7异常处理）。
- 新产品/新功能首次评审：从0到1的需求定义，需验证完整性与可行性。
- 重大功能迭代评审：涉及架构变更、多模块联动或用户流程重组。
- 跨团队/跨部门协作评审：需求影响两个以上技术团队或业务部门时，必须组织联合评审。
- 里程碑节点强制评审：项目立项、TR1/TR2、版本封板等关键节点。
提示：日常小迭代或纯文案修正（无逻辑/交互变化）可走“轻量确认”通道，不触发本标准SOP。
1.2 前置条件
以下条件全部满足后，方可进入PRD评审SOP流程；任意一条不满足应暂缓评审。
| 序号 | 前置条件 | 验证方式 |
|---|---|---|
| 1 | PRD文档已完成内部自审，版本号明确（V1.0+） | 自审签字记录 |
| 2 | 评审材料（PRD、原型、流程图、术语表）已提前至少2个工作日分发 | 邮件/IM发送记录 |
| 3 | 所有关键干系人（开发、测试、业务方）已确认评审时间并预留 | 会议邀请接受状态 |
| 4 | 评审会议已创建，包含议程、时间、参会人、材料链接 | 日历项检查 |
| 5 | 产品经理已完成需求自检清单（检查功能逻辑闭环） | 自检清单归档 |
常见踩坑：前置条件未满足时强行评审，会导致会议反复中断、效率极低，且容易遗漏关键问题。建议由项目经理或产品负责人执行“条件门禁”检查。
1.3 操作步骤
本标准SOP将PRD评审拆解为四个宏观阶段，每个阶段包含明确的动作与责任角色。
- 评审准备（产品经理 + 项目经理）
完成前置条件检查，确认材料版本，发送评审邀请与议程。 - 评审召开（全体参会人）
产品经理按模块讲解需求，参会人现场提问，记录员同步记录问题。 - 问题跟踪（产品经理 + 记录员）
会后24小时内输出问题跟踪表，分类（严重/一般/建议），分配责任人。 - 评审收尾（产品经理 + 项目经理）
确认评审结论（通过/有条件通过/不通过），归档纪要，更新PRD版本。
1.4 输入输出物
| 输入物（评审前） | 输出物（评审后） | 责任角色 |
|---|---|---|
| PRD文档（含需求描述、业务规则） | 修订版PRD（如有变更） | 产品经理 |
| 原型图 / 交互设计稿 | 评审会议纪要（含决策记录） | 记录员 |
| 业务流程图 / 状态机图 | 问题跟踪清单（优先级+责任人） | 产品经理 / 项目经理 |
| 术语表 / 数据字典 | 评审结论报告（通过/有条件/不通过） | 项目经理 |
| 需求自检清单 | 行动项追踪看板（可选） | 项目经理 |
1.5 责任边界
以下表格明确了各角色在PRD评审SOP中的核心职责，避免“谁都管、谁都不管”。
| 角色 | 核心职责 | 不承担职责（边界） |
|---|---|---|
| 产品经理 | 需求讲解、问题记录、PRD修订 | 不代替技术做方案决策 |
| 开发负责人 | 技术可行性评估、工作量预估 | 不负责业务价值判断 |
| 测试负责人 | 可测试性评估、验收标准确认 | 不负责需求完整性核查 |
| 项目经理 | 资源协调、进度把控、评审结论归档 | 不介入具体需求细节讨论 |
| 业务方/需求方 | 需求价值确认、优先级排序 | 不参与技术实现方案讨论 |
1.6 记录材料
评审过程中必须使用标准化模板进行记录，确保信息不丢失、可追溯。
- 评审会议纪要模板：包含会议基本信息、参会人、评审结论、问题摘要、行动项。
- 问题跟踪表模板：包含问题ID、描述、提出人、严重等级、责任人、状态、闭环日期。
- 评审签到表：记录实际参会人及角色，用于合规审计。
- 需求自检清单：产品经理前置自用，确保基本质量。
建议：所有记录材料统一存放在项目Wiki或共享文档空间，命名规则为“项目名_PRD评审_日期_版本”。
1.7 异常处理
评审过程中可能出现三类典型异常，对应处理预案如下。
| 异常类型 | 表现 | 处理预案 |
|---|---|---|
| 需求争议 | 多方对需求逻辑、优先级或实现方式存在重大分歧 | 现场记录争议焦点，升级至产品负责人/业务决策委员会裁决；必要时暂缓该模块评审 |
| 关键角色缺席 | 开发负责人或业务方代表未出席且无授权代表 | 评估影响范围：若缺失角色对当日评审内容无直接决策权，可继续；否则改期或远程接入 |
| 需求范围蔓延 | 评审过程中新增大量未在PRD中覆盖的需求 | 记录为“待评估需求”，不纳入当前评审范围；由项目经理评估是否触发变更流程 |
1.8 验收标准
以下标准全部满足时，本SOP章节对应的评审活动视为合格完成。
- 所有评审问题均已记录在问题跟踪表中，且每个问题都有明确的处理意见或责任人。
- 关键干系人（开发负责人、测试负责人、业务方）均已确认评审结论，无遗留重大分歧。
- 评审会议纪要已签发并发送给全体参会人，包含决策记录和行动项。
- 问题跟踪表已建立，问题按严重等级分类，责任到人，且已设定预计闭环日期。
- 评审结论明确标注为“通过”、“有条件通过”或“不通过”，项目经理已归档。
质量门禁：验收标准由项目经理在评审后48小时内检查，不达标则标记SOP未完成，触发整改流程。