第1章 PRD评审流程总览：阶段划分、输入输出、核心角色、评审决策类型

本章作为全课程的基础框架层，为后续29个关键节点处理提供统一的流程语言与决策坐标系。内容覆盖从需求就绪到评审结论输出的完整生命周期，明确每个阶段谁来交付、交付什么、谁有权决策、以及决策类型如何影响后续节奏。

1.1 适用场景

适用以下三类场景：

• 新建产品或大型特性：涉及多团队（开发、测试、运营、安全）协同，需要统一评审节奏。
• 跨版本迭代：在已有系统上做增量PRD修改，需评估回归影响与兼容性。
• 组织评审流程成熟度提升：团队从“无评审”或“口头评审”转向正式SOP。

1.2 前置条件

启动第1章内容的先决条件：

1. 已完成需求价值评估，并产出经PO/业务方签字确认的《需求列表（V1.0）》。
2. 产品经理已根据需求列表编写至少第一版PRD（草稿状态）。
3. 项目已分配评审主持人（通常为技术Leader或资深产品专家）。
4. 已申请评审会议时段（至少提前2个工作日）。

1.3 操作步骤

PRD评审流程从“需求准备”到“结论归档”分为五个阶段，每个阶段有明确的输入输出与决策点：

1. 阶段一：需求准备与PRD自检
   • PM完成PRD初稿，对照《PRD自检清单》逐项检查完整性。
   • 输出：自检通过的PRD V1.1。
2. 阶段二：预审与评审材料分发
   • 主持人在评审会议前2天将PRD、相关原型/流程图分发给所有评审角色。
   • 输出：各角色预审意见收集表。
3. 阶段三：评审会议召开
   • 主持人引导按模块（功能/数据/体验/安全）逐条过审。
   • 输出：会议纪要（含决策、待办项、负责人、截止时间）。
4. 阶段四：决策与表决
   • 技术、测试、运营、安全等核心角色对当前版本PRD投赞成/驳回/有条件通过票。
   • 输出：评审决策单（通过/有条件通过/不通过）。
5. 阶段五：结论落实与归档
   • 若通过，PRD进入基线管理；若有条件通过，PM需在指定期内完成修改并二次确认；若不通过，退回需求池重新分析。
   • 输出：基线PRD（含版本号） + 评审记录归档。

1.4 输入输出物

1.5 责任边界

• 产品经理：负责PRD撰写、自检、接受评审意见并修改；对功能逻辑完整性负主要责任。
• 技术负责人：评估实现可行性、技术风险、架构影响；对技术方案可行性负否决权。
• 测试负责人：评估可测性、测试数据准备、影响范围；对测试覆盖度负决策权。
• 安全负责人：评估数据安全、合规、风控；对安全红线有一票否决权。
• 评审主持人：控制节奏、引导讨论、记录结论、跟踪待办；不直接对PRD内容负责。

1.6 记录材料

每次评审必须归档以下三份文档：

1. 评审会议纪要：包含时间、参与人、每项评审结论、待办事项及负责人。
2. 评审决策单：包含审批签字（至少3个核心角色）、决策类型（通过/有条件通过/不通过）、二次评审触发条件。
3. 预审意见收集表：各角色评审前提出的书面意见，作为会议讨论依据。

1.7 异常处理

1.8 验收标准

第1章内容交付后，学员应能达成以下能力：

• 能口头复述PRD评审流程的五个阶段及每个阶段的强制输入输出。
• 能在实际项目中识别当前项目缺少的核心角色并建议补位。
• 能根据会议结论判断该PRD属于“通过/有条件通过/不通过”，并说出对应后续行动。
• 能正确填写《评审决策单》和《预审意见收集表》模板（文档格式将在附录中提供）。