第二章 评审角色与职责边界
1. 适用场景
本章定义的原型评审角色职责边界，适用于以下跨职能协作场景：
- 正式原型评审会议 — 设计师完成高保真原型后，组织产品、开发、测试进行集中评审。
- 关键需求对齐节点 — 产品需求与设计方案之间存在模糊地带，需要多方共同确认。
- 技术可行性校验 — 原型中包含创新交互或复杂逻辑，需要开发提前介入评估。
- 测试用例前置评审 — 在测试用例编写前，让测试团队从原型中提取可测点。
2. 前置条件
- 原型设计稿已完成并通过产品经理初审，可分享链接或离线包已提前 24 小时 同步。
- 产品经理已输出当前迭代的 PRD（产品需求文档），并与设计师完成需求串讲。
- 各角色已收到评审会议邀请，并明确评审目标与议程。
- 开发与测试团队已预留完整的评审参与时间，无并行冲突。
3. 操作步骤
以下按角色分解评审 前、中、后 三个阶段的关键动作：
3.1 产品经理
- 评审前：确认原型覆盖 PRD 全部核心场景；准备需求变更清单（如有）。
- 评审中：主持评审节奏；对需求偏差做现场裁决；记录待确认事项。
- 评审后：发出评审纪要，更新需求优先级，推动设计修改排期。
3.2 设计师
- 评审前：确保原型交互链路完整、异常态已覆盖；准备设计决策说明材料。
- 评审中：按场景逐页演示原型；解释交互逻辑与用户体验依据；标注修改点。
- 评审后：输出《设计修改清单》，更新原型并通知相关方二次确认。
3.3 开发工程师
- 评审前：预审原型，标记疑似技术不可行或高成本实现区域。
- 评审中：逐条反馈技术可行性结论；提出替代方案或降级策略。
- 评审后：输出《技术评估备忘》，更新开发排期估算。
3.4 测试工程师
- 评审前：熟悉原型功能清单，提炼初始测试场景。
- 评审中：评估关键路径的可测性；补充边界条件与异常场景。
- 评审后：更新测试用例库，标注依赖原型修改的阻塞项。
4. 输入输出物
| 角色 | 输入物（评审前需准备） | 输出物（评审后需提交） |
|---|---|---|
| 产品经理 | PRD、需求变更清单、评审议程 | 评审纪要、需求优先级更新 |
| 设计师 | 高保真原型、设计规范、用户研究报告（可选） | 设计修改清单、原型更新版 |
| 开发工程师 | 技术预审记录、架构约束说明 | 技术评估备忘、排期估算更新 |
| 测试工程师 | 初始测试场景列表、历史缺陷报告 | 测试用例补充清单、阻塞项标注 |
5. 责任边界（核心）
以下矩阵定义每个角色的 应做事项 与 不应做事项，避免评审中角色越位或责任真空：
| 角色 | 核心职责 | 应做事项 | 不应做事项 |
|---|---|---|---|
| 产品经理 | 需求确认与目标对齐 | 明确 PRD 要点、确认需求覆盖、裁决需求争议、控制评审节奏 | 代替设计师做交互细节决策、代替开发承诺技术方案 |
| 设计师 | 交互展示与设计说明 | 逐页演示原型、解释设计逻辑、记录修改反馈、输出修改清单 | 直接承诺技术实现可行性、自行决定需求范围变更 |
| 开发工程师 | 可行性评估与风险识别 | 评估技术复杂度、识别实现风险、提供备选方案、估算开发成本 | 仅否定设计而不给出替代建议、过度承诺排期、忽视用户体验细节 |
| 测试工程师 | 可测性评估与场景覆盖 | 识别测试场景、评估验收标准可测性、补充边界条件、提出数据需求 | 评判技术实现内部细节、代替产品经理决定需求优先级 |
最佳实践： 在产品经理主持评审时，可使用「责任边界卡」—— 一张 A5 卡片正面印有各角色应做/不应做清单，会议开始时分发，快速对齐角色预期。
6. 记录材料
评审过程中建议使用统一的 《原型评审记录表》，包含以下字段：
- 原型版本 & 评审日期
- 参与角色（产品 / 设计 / 开发 / 测试）
- 评审项（页面 / 交互 / 异常态）
- 反馈内容（按角色分色标注）
- 责任归属（明确修改负责人）
- 结论（通过 / 有条件通过 / 需二次评审）
示例记录条目：
| 评审项 | 反馈内容 | 责任归属 | 结论 |
|-----------------|----------------------------------|------------|----------|
| 登录页 - 忘记密码 | 建议增加邮箱验证前置提示 | 设计师 | 修改后通过 |
| 支付页 - 倒计时 | 后端接口超时可能引起倒计时不同步 | 开发工程师 | 需二次评审 |7. 异常处理
| 异常场景 | 处理方式 |
|---|---|
| 关键角色缺席（如开发负责人） | 评审改为「设计对齐会」，不做出技术可行性结论；会后单独收集书面反馈。 |
| 角色间职责争议（设计与开发争论交互细节） | 产品经理以用户目标和业务价值为基准做最终裁决，记录争议项并约定专题讨论。 |
| 评审中频繁出现需求变更 | 产品经理冻结本次评审范围，变更需求进入下一迭代 backlog，避免原型反复修改。 |
| 测试角色提出大量阻塞性问题 | 区分「设计缺陷」与「测试数据缺失」；设计缺陷由设计师跟进，测试数据由产品协调。 |
常见越位警示： 开发在评审中直接要求设计师修改交互方案，而未先评估技术可行性或提供替代方案，容易导致设计质量下降。正确的做法是：开发先给出技术约束说明，由设计师基于约束重新设计。
8. 验收标准
本章节所定义的角色职责边界是否落地，可通过以下标准检验：
- 评审会议中，各角色发言人 90% 以上的发言内容 落在其应做事项范围内。
- 评审纪要中每个修改项均标注了唯一的 责任归属角色，无「共同负责」导致的推诿。
- 评审后 24 小时内，各角色已完成输出物的提交或更新。
- 角色满意度调研（匿名）中，「职责清晰度」评分 ≥ 4.2/5.0。