第3章 责任矩阵RACI：角色定义、RACI分配、签字权说明、变更审批节点
3.1 适用场景
在 AI Agent 需求优先级排序过程中，涉及产品、开发、算法、测试、业务方等多角色协同决策。RACI 责任矩阵适用于以下场景：
- 需求池中存在跨部门、跨职能的争议需求，需要明确谁有权决策
- 优先级排序流程中，需要分配需求分析、评估、审批、执行的具体责任人
- 需求变更频繁，需要界定变更审批的触发节点与签字权限
- 新建或重组 AI Agent 产品线，首次建立需求管理协作规范
⚠ 避坑提示： 如果团队少于 3 人（如仅 1 名产品经理 + 1 名开发），不建议引入正式 RACI 矩阵，改用线性责任表即可；过度形式化会降低小型团队响应速度。
3.2 前置条件
- 已完成 第2章 需求价值/成本量化评估（每项需求至少已获得
业务价值分与技术风险分） - 已识别出所有参与需求优先级排序的核心角色（至少 4 类：产品/业务/开发/测试）
- 已准备好组织架构图或项目干系人清单
- 已定义需求状态流转节点（提交→评估→排队→开发→验收→上线）
3.3 操作步骤
- 角色定义： 列出所有参与需求优先级排序的角色，为每个角色赋予唯一职责标签（R/A/C/I）。
- RACI 分配： 将需求池中的关键活动（需求提交、价值评分、技术评估、优先级排序、变更审批）填入矩阵，分配 R/A/C/I。
- 签字权说明： 明确每个 审批节点 的 签字人（即 A 或 R 角色），定义签字生效条件（如：必须技术负责人 + 产品负责人双签）。
- 变更审批节点设定： 在流程图中标记 变更触发点（如：需求优先级调整超过 3 级、需求新增或撤销），指定变更后必须重新执行的 RACI 活动。
- 矩阵发布与培训： 将最终版 RACI 矩阵发布至团队知识库，并对所有干系人进行 30 分钟的操作说明。
📎 关键指标： 每项活动必须且只能有 1 个 A（负责人）；若出现多个 A，需合并或拆分活动；若某项活动缺少 R，则必须指定执行者，否则矩阵无效。
3.4 输入输出物
| 输入物 | 输出物 |
|---|---|
| 需求优先级待排序列表（含价值/成本评分） | RACI 责任矩阵表（含签字权限列） |
| 项目干系人清单 / 组织架构图 | 签字权说明书（1 页文档） |
| 需求状态流转流程图（已有版本） | 变更审批节点流程图（标注 RACI 角色） |
3.5 责任边界
- R（执行者） — 负责执行具体任务，如：需求价值评分由业务分析师执行。
- A（负责人） — 对任务成败负最终责任，如：优先级排序由产品负责人签字。
- C（咨询者） — 在任务执行前或执行中提供输入，如：技术风险评分由技术架构师提供。
- I（知情者） — 任务完成后被通知结果，如：相关业务方被告知最终优先级排序。
💡 实践建议： 在 AI Agent 类需求中，算法负责人通常担任 技术评估的 C（咨询者） 角色，而非 A；因为优先级排序的最终责任人仍是产品负责人。切忌将 A 赋给纯技术角色，避免业务目标偏离。
3.6 记录材料
- 模板文件： 《AI Agent 需求优先级 RACI 矩阵_v1.xlsx》（含角色、活动、RACI 分配、签字栏、版本号）
- 会议纪要： 至少一次 RACI 对齐会纪要，记录角色争议与最终裁定结果
- 签字记录： 每个变更审批节点至少保留 签字截图或邮件确认，存档至需求管理工具
3.7 异常处理
| 异常场景 | 处理方案 |
|---|---|
| 某活动无人愿担 A 角色 | 升级至项目发起人（Sponsor）强制指定；或拆分活动，降低个人责任范围 |
| 签字权限冲突（多人同时有签字权） | 设定签字顺序（如：先技术负责人签字，再产品负责人签字）；或设定双签比例阈值（如：两票均同意方可生效） |
| 需求变更导致 RACI 分配失效 | 启动 最小变更审批：仅重新分配受影响活动的 R/A/C/I，其他活动保持不变；变更后 24h 内更新矩阵并通知 I 角色 |
| 外部咨询角色（C）长期不响应 | 设置 默认咨询反馈窗口（如：2 个工作日内），超时默认同意；或在矩阵中标记 C 为可选输入 |
3.8 验收标准
- RACI 矩阵包含至少 6 个核心活动（需求提交、价值评估、技术评估、优先级排序、变更审批、验收确认），每个活动有且仅有 1 个 A
- 签字权说明书明确列出所有 双签节点 及 单人签字节点，无模糊描述
- 变更审批节点在矩阵中以 特殊标记（如红色底纹或星号）区分，且变更后流程与原始流程无责任空缺
- 所有干系人（R/A/C/I）已收到邮件通知并确认矩阵内容，确认率达到 100%