第2章：角色职责定义——产品经理、设计师、开发、QA 对齐责任
适用场景
当团队进入原型设计阶段，需要明确各角色在 Solution Design 对齐 中的具体职责时使用。典型场景包括：
- 原型初稿完成后，产品经理、设计师、开发工程师、QA 需要共同评审并确认设计方案
- 跨部门协作中因职责不清导致原型返工或设计遗漏
- 项目早期需要建立统一的职责边界，防止后期责任推诿
前置条件
- 产品经理已完成 PRD（产品需求文档） 初版
- 设计师已输出 至少一版可交互原型（Figma / Axure / Sketch）
- 开发与 QA 已了解项目背景并能参与评审会议
- 团队已确定 统一的协作工具链（如：Figma + Jira + Confluence）
操作步骤
- 步骤一：梳理原型对应的需求点清单
产品经理将原型中每个交互、状态、边界条件拆解为颗粒度一致的需求条目。 - 步骤二：定义各角色在每一条需求上的责任标签
使用R（负责）、A（执行）、C（咨询）、I（知悉） 四类标签，在 RACI 矩阵中明确责任。 - 步骤三：召开对齐会议
由产品经理主持，逐条过原型页面，设计师负责讲解交互细节，开发评估技术可行性，QA 补充测试边界。 - 步骤四：输出《角色职责确认书》
将所有条目与责任人签署确认，存档至项目协同文档。 - 步骤五：更新原型注释与状态
在原型工具中为每个环节添加角色标签和确认时间戳，形成可追溯记录。
输入输出物
| 输入物 | 输出物 |
|---|---|
| 原型源文件（含全部页面与交互） | 《角色职责确认书》（含 RACI 矩阵） |
| PRD / 用户故事 | 对齐会议纪要（含遗留问题清单） |
| 团队角色花名册 | 原型注释（责任人标签 + 确认日期） |
责任边界
| 角色 | 核心职责 | 不应越界的动作 |
|---|---|---|
| 产品经理 | 产出需求条目、确定功能优先级、组织对齐会议 | 自行修改 UI 像素级设计 |
| 设计师 | 输出可交互原型、讲解交互逻辑、标注异常状态 | 擅自增加未评审的功能点 |
| 开发 | 评估技术可行性、反馈实现风险、确认接口定义 | 不经过产品同意直接改需求 |
| QA | 补充测试用例、确认验收标准、检查边界与异常流 | 在原型阶段要求全量自动化通过 |
记录材料
- 《角色职责确认书》 模板：需包含原型版本号、日期、每一需求的 RACI 分配、签名栏。
- 对齐会议录音/录屏（可选）：用于后期争议追溯。
- 原型工具内嵌评论日志：记录每次修改的责任人及时间。
异常处理
| 异常场景 | 应对措施 |
|---|---|
| 角色之间对职责划分有争议 | 由产品经理仲裁，必要时升级至技术负责人或项目总监 |
| 原型不完整导致责任无法对齐 | 暂停对齐会议，要求设计师补齐遗漏页面后再重新对齐 |
| 开发或 QA 反馈技术限制导致原型需大幅修改 | 产品经理与设计师共同评估改动范围，重新走步骤一至五 |
| 多方已确认但后续发现遗漏需求 | 新增需求条目并补充角色职责确认，不允许口头承诺 |
验收标准
- 所有原型页面（含异常状态、边界条件）均已有 明确的角色责任人标签。
- 每个需求条目在 RACI 矩阵中至少有一个 R（负责） 和一个 A（执行）。
- 团队在产品、设计、开发、QA 四方确认后，无未解决的遗留问题。
- 对齐会议纪要已上传至项目知识库，并通知所有相关人员。
💡 最佳实践： 建议在原型工具（如 Figma）中直接使用自定义组件“角色责任标签”，将产品经理、设计师、开发、QA 以不同色块附着在原型页面上，这样在评审时一目了然，减少会后沟通成本。
📌 关键检查点： 每个需求条目必须且只能有一个 R（负责），不能出现多个 R 或没有 R 的情况。如果发现某条需求有多个 R，需要产品经理重新裁定主负责人。