第2章 评审角色与责任矩阵
原型评审不是单一角色的独自审视，而是产品经理、设计师、开发、测试、运营五方围绕同一份原型，从各自专业视角交叉验证的协作过程。本章建立一张评审角色责任矩阵，明确每位成员在评审中的重点审视领域与必须交付的评审产物，避免“谁都能说两句、但谁都不对结果负责”的评审失焦问题。
2.1 适用场景
- 团队首次建立原型评审流程，需要定义各角色参与深度。
- 新项目启动，评审成员来自不同部门，需统一责任语言。
- 评审效率低、反复返工，经复盘发现角色责任边界模糊。
- 跨职能评审时，某角色“只提意见不产出”，评审结论无法落地。
- 组织从“单角色评审”转向“全角色联合评审”的过渡阶段。
2.2 前置条件
- 已完成项目需求文档（PRD）初稿，并同步给所有评审角色。
- 已确定本次评审的参与角色名单与具体人员。
- 各角色已阅读项目背景、业务目标与用户故事。
- 准备一份空白《评审角色责任矩阵表》（模板见下文）。
2.3 操作步骤
- 列席确认：在评审邀请中明确标注本次评审的五个角色及对应人员。
- 分发责任矩阵模板：将空白矩阵表随评审议程一同发出，要求各角色提前填写自己关注的评审重点。
- 定义评审重点：组织评审启动会（15分钟），逐角色确认其核心审视维度（需求、视觉、技术、测试、运营）。
- 锁定交付物：每位角色需明确自己在评审前、评审中、评审后必须产出的具体交付物（文档、标注、用例等）。
- 签署责任矩阵：将确认后的矩阵表归档至项目空间，作为本次评审的“责任契约”。
- 过程跟踪：评审进行时，主持人按矩阵表逐项核对各角色是否完成其评审重点；评审结束后，检查交付物是否齐全。
实操提示：责任矩阵表建议使用共享在线表格（如飞书多维表格、Notion），让各角色在评审前48小时完成预填，主持人提前识别“无人认领”的评审盲区。
2.4 输入输出物
下表列出每位角色在原型评审中的输入物（评审前需准备好的材料）与输出物（评审后必须提交的交付件）。
| 角色 | 输入物（评审前） | 输出物（评审后） | 说明 |
|---|---|---|---|
| 产品经理 | PRD、用户故事地图、业务流程图 | 评审后的需求修订稿、需求优先级排序表 | 确认原型是否完整覆盖所有用户故事，业务逻辑无遗漏。 |
| 设计师 | 设计稿、交互说明文档、设计规范 | 交互验收清单、视觉走查报告、设计标注更新 | 检查视觉一致性、交互流程是否闭环、异常状态是否涵盖。 |
| 开发 | 技术架构图、数据结构文档、接口文档 | 技术可行性评估表、实现成本预估、技术风险清单 | 评估原型中每个功能点的实现难度、依赖关系与潜在重构点。 |
| 测试 | 测试策略文档、历史缺陷库 | 测试场景清单、边界条件列表、自动化测试建议 | 识别原型中的可测性盲区，补充未覆盖的异常路径与极限条件。 |
| 运营 | 运营活动排期表、用户行为数据报告 | 运营兼容性检查表、用户触点优化建议、数据埋点需求 | 验证原型是否支持即将上线的运营活动，以及用户行为数据是否可追踪。 |
2.5 责任边界
责任边界定义了每位角色在评审中必须表态的领域，以及不得越权决策的界限。
- 产品经理：对需求范围、业务逻辑、用户价值负总责；不得替设计师决定视觉风格，不得替开发承诺技术方案。
- 设计师：对视觉一致性、交互流畅性、可访问性负责；不得擅自变更需求范围，涉及流程修改需知会产品经理。
- 开发：对技术可行性、实现成本、系统性能负责；不得否决合理需求，应提供替代技术方案而非直接拒绝。
- 测试：对测试充分性、边界覆盖、缺陷预防负责；不得越权评估需求优先级，发现的缺失去向由产品经理裁决。
- 运营：对运营策略兼容性、用户触达有效性、数据可追踪负责；不得要求增加与核心用户故事冲突的功能。
责任边界检查工具：在评审会议中设置“责任铃”——当讨论偏离当前角色的责任边界时，主持人可摇铃提醒，将讨论拉回正轨。
2.6 记录材料
每次评审必须归档以下记录材料，作为责任矩阵执行的证据与复盘依据：
- 《评审角色责任矩阵表》（含各角色填写的评审重点与交付物清单）。
- 《评审纪要》：记录每位角色提出的关键意见、争议点及最终裁决。
- 《交付物签收单》：评审结束后24小时内，各角色提交交付物并由主持人签收。
- 《责任偏差日志》：记录评审过程中出现的角色越界、责任遗漏等偏差及纠正措施。
2.7 异常处理
| 异常场景 | 可能原因 | 处理方式 |
|---|---|---|
| 某角色未提前填写评审重点 | 角色对责任矩阵不熟悉，或认为与自己无关 | 主持人现场引导其逐项勾选，并记录为“责任意识待加强”；会后一对一沟通。 |
| 产品经理与设计师对交互方案争执不下 | 责任边界未约定“最终决策权”归属 | 以用户测试数据或A/B测试结果作为裁决依据；若无数据，产品经理拥有最终决定权。 |
| 开发提出实现成本超出预期 | 评审前技术调研不充分 | 开发在24小时内提交成本明细与替代方案，产品经理据此调整需求优先级。 |
| 测试发现原型缺少边界状态 | 设计师未在设计稿中覆盖异常流程 | 测试直接提交缺失状态清单，设计师在评审结束后补充设计，无需重新评审。 |
| 运营提出功能与运营策略冲突 | 评审前运营需求未对齐 | 产品经理评估冲突影响范围，决定是否调整功能或运营策略；若调整范围超过20%，需发起二次评审。 |
风险预警：责任矩阵不是“责任甩锅”的工具。如果某个角色在评审中持续“无意见、无交付、无问题”，主持人应主动干预，排查是能力不足还是参与度不够，及时调整人员或培训补充。
2.8 验收标准
以下标准用于判断本章责任矩阵是否被有效执行：
- 覆盖度：每位角色在矩阵表中至少勾选了3项评审重点，并按时提交了对应的交付物。
- 清晰度：评审过程中，每位角色能明确说出自己的责任范围与交付要求。
- 可追溯：评审纪要中每条意见都可以追溯到具体角色及其责任领域。
- 闭环率：评审结束后48小时内，所有角色交付物已归档，责任偏差日志已更新。
- 改进率：连续3次评审后，角色责任边界导致的争执次数下降50%以上。