3. 评审角色与责任矩阵
适用场景
本流程适用于PRD正式评审会议，及跨部门关键决策点的责任划分场景。当需要明确谁主要陈述、谁负责评估、谁拍板决策、谁记录遗留问题时，启动本责任矩阵。
核心目标：消除“都同意但没人负责执行”“评审完了不知道谁批准”的责任模糊地带。
前置条件
- PRD已完成至少一次自审，版本号≥v1.1。
- 已确认参会人名单（至少包含产品经理、技术TL、测试TL、业务方代表）。
- 评审会议已发出日历邀请并附带PRD文档链接。
操作步骤（SOP）
- 主持人开场（通常为产品经理）：宣读本次评审的目标 PRD 章节范围，并正式明确 决策人 与 记录人。
- 按模块逐一过稿：产品经理按用户场景或功能模块，逐条宣读需求描述。
- 技术评估（技术TL）：评估技术可行性、依赖系统、开发工作量。
- 测试准入（测试TL）：判断是否符合可测试性条件，提出测试数据需求。
- 业务确认（业务方）：验证用户场景是否覆盖真实业务流程。
- 决策人拍板：对有争议的变更、资源冲突、优先级做出最终决策。
- 记录问题并归档：
记录人将待处理项录入评审问题追踪表。
输入输出物
| 类型 | 名称 | 责任人 |
|---|---|---|
| 输入 | PRD v1.x（待评审版本） | 产品经理 |
| 输入 | 评审会议邀请与议程 | 产品经理 |
| 输出 | 评审纪要（含遗留问题清单） | 记录人 |
| 输出 | 修订版PRD v2.0（评审通过后归档） | 产品经理 |
责任边界（强矩阵）
| 角色 | 核心职责 | 决策权 | 签字/确认 |
|---|---|---|---|
| 产品经理 | 陈述需求背景、用户故事、验收标准 | 需求优先级（≤P2） | 需求完整性确认 |
| 技术TL | 评估技术可行性、依赖、工作量 | 技术方案否决权 | 技术实现交叉确认 |
| 测试TL | 提出可测试性要求、数据准备 | 不可测试退回权 | 测试准入签字 |
| 业务方 | 验证用户场景、确认业务规则 | 关键业务逻辑确认 | 业务验收代表 |
| 决策人 | 处理争议、资源冲突、优先级升级 | 最终否决 / 批准权 | 考核会签 |
| 记录人 | 速记问题、待办、责任人、到期日 | 无（中立记录） | 纪要完整性 |
决策人定义：通常由项目经理、产品总监或业务线VP担任。决策人必须拥有“打破部门墙”的行政或预算权限。当技术TL与产品经理就“做不做”僵持时，由决策人限时拍板。
避坑指南：切勿让“产品经理”同时担任“记录人”。记录需要保持中立，产品经理同时记录会遗漏自己发言中的破绽。建议由QA或项目管理助理担任记录人。
SVG：评审责任矩阵与角色关系图
记录材料（模板）
【评审问题追踪表（节选）】
会议ID: REV-2025-003
记录人: 张三（QA）
决策人: 王五（产品总监）
| 序号 | PRD章节 | 问题描述 | 提出方 | 决策人意见 | 责任人 | 到期日 | 状态 |
|------|---------|---------|--------|-----------|--------|--------|------|
| 1 | 3.2.1 | 未明确库存判断逻辑 | 测试TL | 同意按A方案执行 | 产品经理 | 2025-04-10 | 待解决 |
| 2 | 5.1 | 旧接口需改造，多2人日 | 技术TL | 预算内，批准 | 技术TL | 2025-04-12 | 进行中 |
| 3 | 7.0 | 订单状态机缺少已取消分支 | 业务方 | 必须补充 | 产品经理 | 2025-04-08 | 已关闭 |
异常处理
- 决策人缺席：暂缓涉及资源/范围变更的决策项，只记录待办，不得现场拍板。
- 关键角色缺席（技术TL/测试TL/业务方）：相应模块的评估结果标记为“待补充”，不纳入正式通过范围。
- 重大分歧无法当场决策：决策人须在24h内给出书面结论（邮件/IM），逾期则按默认方案（拒绝变更）执行。
- 范围蔓延（新增需求）：现场只记录，不讨论。若决策人当场要求变更，必须单独走变更控制流程。
验收标准
- 每个角色都已明确自己的职责卡片，并签字确认。
- 决策人的书面否决/批准意见已归档。
- 遗留问题清单中每个条目的责任人和到期日均明确。
- 评审纪要中不存在“由某人私下沟通”的模糊表述。