第2章 PRD评审的角色与职责

1. 适用场景

本章适用于以下场景中的角色责任对齐与协作边界确认：

• 新功能立项评审：产品经理首次输出完整PRD，需要跨团队评估可行性。
• 重大改版评审：涉及流程重构、UI重设计或底层技术变更，各角色需同步认知。
• 争议需求复审：前期存在职责不清或方案分歧，需要重新界定责任边界。
• 敏捷迭代中的快速评审：压缩评审周期时，各角色需明确自己的输入输出节点，避免遗漏。

2. 前置条件

进入角色职责对齐前，必须满足以下条件，否则责任边界无法清晰定义：

• PRD初稿已完成版本冻结，并同步至各角色（建议提前 ≥72h）。
• 各角色已指定唯一对接人（如开发主R、测试主R），避免多头沟通。
• 评审会议议程已发布，议程中需包含角色职责确认环节。
• 基础协作工具已就位（如Confluence、Jira、飞书文档），确保输入输出可追溯。

3. 操作步骤

按照评审流程的三阶段，各角色需执行以下操作：

3.1 评审前准备（会前 24~72h）

3.2 评审中同步（会议进行时）

• 产品经理：按议程逐条宣讲PRD，优先说明变更背景与业务目标。
• 开发/测试/设计/运营：依次发表专业意见，每人限时 5 min，聚焦 可行性与风险。
• 全员：对争议点进行 三轮辩论（观点→依据→方案），超时则记录为待办项。
• 记录人（通常为产品经理或PMO）：实时记录结论与待办，形成评审纪要。

3.3 评审后跟进（会后 24h 内）

• 产品经理：发布评审纪要，更新PRD版本，标记待办项负责人与截止时间。
• 各角色：在 24h 内确认纪要内容，若有异议需书面回复。
• 项目负责人：跟踪待办项闭环，确认所有角色完成责任确认后，进入开发排期。

4. 输入输出物

5. 责任边界

责任边界是本章的核心。每个角色在评审中拥有 一票否决权（仅限本专业领域），但同时也承担 对应的解释与替代方案义务。

各角色的责任边界具体定义如下，不可越界也不可推诿：

6. 记录材料

每次评审必须保留 评审记录表，作为责任追溯与复盘依据。推荐使用以下结构：

记录表推荐使用以下Markdown模板存储于文档协作平台：

# PRD评审记录表

**评审版本**：v2.1.3 / 2025-06-18  
**PRD标题**：会员中心积分体系优化  
**参会角色**：PM-张三 / DEV-李四 / QA-王五 / UE-赵六 / OP-陈七  

## 需求评审结论
| 需求ID | 需求名称       | 结论     | 备注                     |
|--------|----------------|----------|--------------------------|
| F001   | 登录流程优化   | 通过     | 无                       |
| F002   | 积分兑换系统   | 待办     | 阈值争议，周三再确认     |
| F003   | 会员等级展示   | 通过     | 设计稿需补充空状态       |

## 争议点记录
- **F002-积分兑换阈值**：PM提议10积分起兑，DEV认为5积分更合理。  
  待办：DEV-李四分析用户积分分布数据，周三17:00前同步结论。

## 角色确认
- PM（张三）：已确认责任边界，无异议。  
- DEV（李四）：已确认技术评估范围，无异议。  
- QA（王五）：已确认测试策略，F002待办不影响整体排期。  
- UE（赵六）：已确认设计交付物，F003需补充空状态。  
- OP（陈七）：已确认运营方案，埋点需求周四前输出。

7. 异常处理

8. 验收标准

第2章内容的落地以以下 六项标准 是否全部满足为衡量依据：

• 标准一：每个角色都收到了完整的 输入物清单，并且确认清单中的每一份文档都已到位。
• 标准二：评审会结束时，每个角色都输出了各自 责任范围内的专业意见（口头或书面均可）。
• 标准三：所有 争议点 都记录了各方观点、待办责任人和解决时间，无悬而未决项。
• 标准四：评审记录表已完成填写，并包含 各角色责任确认 的签字或等效记录。
• 标准五：无角色在评审后24h内提出 “我不知道这是我的责任” 或 的抱怨。
• 标准六：异常处理流程已演练过一次（至少团队知晓且认可处理策略）。