评审角色与责任边界
适用场景
- 跨职能原型评审：产品、设计、前端、测试需要联合确认 Figma 原型与 Confluence 需求的一致性。
- 边界争议预防：当原型功能归属（设计实现 / 逻辑判断 / 测试验证）容易混淆时，通过角色职责清单规避推诿。
- 新团队 / 新项目启动：为首次协作的角色提供明确责任分工基线。
前置条件
- 产品经理已在 Confluence 创建包含 PRD 及验收标准的评审页面。
- 设计师已将 Figma 原型标注版本号、交互逻辑并共享为可评论链接。
- 前端开发与测试工程师已收到评审通知并掌握基本上下文。
- 团队已签署《原型边界评审角色约定》文档（可在本章末尾记录材料中获取模板）。
操作步骤
- 产品经理宣读边界：在评审开始前，先用 5 分钟对照 Confluence 需求表逐条说明“哪些是页面布局/动效，哪些是数据逻辑/状态切换”。
- 设计师确认交付物：展示 Figma 原型并逐帧说明设计意图，标注“仅做视觉参考”和“严格按照此状态实现”的区域。
- 前端开发认领可执行点：口头或在线表格中勾选自己负责的组件、动画、响应式适配项，并询问设计规范中未覆盖的边界情况。
- 测试工程师补充验证点：从用户视角提出极端值、错误态、空状态等用例，判断这些是否已被原型覆盖或需要独立提需。
- 记录争议与归口：会议记录员（通常为产品经理）将责任不明的新增需求记入“待确认池”，会后 24h 内找到对应角色闭环。
输入输出物
| 类别 | 输入物 | 输出物 |
|---|---|---|
| 产品经理 | Confluence PRD、验收标准 | 角色责任分配表、评审决议记录 |
| 设计师 | Figma 原型、设计规范 | 已标注边界的新版设计图（可选） |
| 前端开发 | 原型 + PRD + 交互说明 | 技术可行性确认单、预估工时 |
| 测试工程师 | 原型 + PRD + 会议邀请 | 测试边界用例清单、漏测风险提示 |
责任边界
| 角色 | 负责 | 不负责 |
|---|---|---|
| 产品经理 | 定义功能逻辑、验收标准、需求变更判定 | 具体动画曲线、像素级样式、组件命名 |
| 设计师 | 视觉风格、交互流程、组件状态、响应式布局 | 数据格式、状态机描述、后端接口字段 |
| 前端开发 | 代码实现、动效还原、浏览器兼容、性能优化 | 非功能性需求如 SEO、无障碍标准（除非写在 PRD 中） |
| 测试工程师 | 用例设计、边界测试、回归验证、缺陷确认 | 产品路线图、UI 风格调整、开发架构选型 |
关键原则：任何角色认为“这应该是别人的事”的新增项，必须当场记录并指定唯一 owner，否则视为待定项由产品经理负责兜底。
记录材料
每场评审后由产品经理更新以下模板至 Confluence 评审页面：
# 原型边界评审记录 —— [项目名 / 版本号]
## 评审日期：YYYY-MM-DD
## 参与人：PM, UI, FE, QA
### 已确认边界项
| 功能模块 | 负责角色 | 原型版本 | 验收状态 |
|----------|----------|----------|----------|
| 登录页表单校验 | FE | v2.3 | ✅ 通过 |
### 待确认池（24h 内闭环）
| 问题描述 | 提出人 | 主张归属方 | 最终决策 |
|----------|--------|------------|----------|
| 空搜索结果页是否展示插画 | UI | PM → 需求决定 | |
### 争议记录
- （无）
提示：记录材料需在评审结束后 2 小时内上传，避免遗忘。
异常处理
| 异常场景 | 处理措施 |
|---|---|
| 角色缺席（如测试未到场） | 产品经理代行测试边界视角，会后单独征求测试意见并补录记录。 |
| 责任推诿（谁都说不清该谁做） | 暂标记为“PM 兜底”，由产品经理在 24h 内做出最终分配并通知相关角色。 |
| 原型与 PRD 严重不一致 | 暂停评审，PM 与设计师在会下对齐后重新发起评审。 |
| 新增需求超出边界框架 | 归入“待确认池”，由 PM 评估是否需要发起单独需求评审。 |
验收标准
- 每项功能模块都有唯一对应的责任角色（无空白、无双人负责）。
- 待确认池条目不超过总条目数的 10%，且均在 24h 内关闭。
- 测试工程师根据评审边界生成的用例清单与原型覆盖率 ≥ 95%。
- 前端开发能明确说出“哪些部分属于设计交付，哪些属于开发决策”。
- 评审记录表在会议结束后 2 小时内上传至 Confluence，且全员可访问。