RACI责任分工矩阵不是把名字填满表格，而是让每项交付都有且只有一个最终负责者。R 负责执行，A 对结果负责并拍板，C 提供意见，I 在需要时获得同步。本文用一个产品上线任务贯穿填写、冲突处理和会后复核，适合产品、项目和运营团队直接套用。
先分清 R、A、C、I：四个角色解决四种协作问题
先把角色写成决策规则，而不是职位名称。R 是实际完成任务的人；A 是对结果承担责任、可以批准或拒绝的人；C 是在任务完成前必须被征询的专业角色；I 只需要知道结果，不参与审批。
| 角色 | 判断问题 | 常见误区 |
|---|---|---|
| R 负责执行 | 谁会交付可检查的产物？ | 把整个部门写成 R，导致无人到具体任务 |
| A 最终负责 | 谁能对范围、质量或上线做最终决策？ | 一行填多个 A，出现互相等待 |
| C 提供意见 | 谁的输入会改变方案或风险判断？ | 把所有相关人都列为 C，会议失去边界 |
| I 需要知会 | 谁只需要看到结果和时间点？ | 把 I 当作审批人，增加无效同步 |
如果一个任务没有 A，说明决策权缺失；如果有两个以上 A，先拆任务或确定唯一拍板人。
五步建立矩阵：先列交付物，再填角色
- 列任务：用可验收的交付物命名，例如“发布页埋点验收”，不要写“跟进数据”。
- 定粒度：一行任务只对应一个结果，跨两周以上的任务拆成阶段节点。
- 填 A：从最终决策倒推唯一批准人，再确认他具备相应权限。
- 填 R/C/I：用会议、评审和通知的真实动作检查是否必要。
- 补证据：给每行增加交付链接、截止时间和验收标准，避免矩阵停留在角色表。
用产品发布任务示例：矩阵要能指导下一次动作
以“新功能发布”为例，任务不是“产品上线”四个字，而是拆成需求冻结、原型验收、开发联调、埋点核验、公告发布和上线后观察。
| 任务 | R | A | C | I |
|---|---|---|---|---|
| 需求冻结 | 产品经理 | 产品负责人 | 研发、客服 | 销售 |
| 原型验收 | 产品经理 | 产品负责人 | 设计、研发 | 项目成员 |
| 埋点核验 | 数据分析 | 研发负责人 | 产品经理 | 运营 |
| 公告发布 | 运营 | 产品负责人 | 客服、法务 | 全员 |
这张表的价值在于，任何人看到“埋点核验”都能知道先找谁、谁拍板、哪些意见要在上线前收齐。
四类冲突怎么处理：多人负责、无人批准和角色过载
- 多人 R：把“参与”拆成主执行与协作执行，保留一个交付接口人。
- 多人 A：按决策范围拆行，或在会议纪要中明确唯一批准人。
- 没有 C：如果任务确实不需要外部输入，保留空白并写明判断依据。
- 一个人承担过多 R/A：按周检查负载，必要时把任务移交并记录交接条件。
不要为了让表格看起来完整而填满每个格子。空白本身也是信息：它提示团队确认是否真的需要参与者。
在 Boardmix 中复核：把矩阵变成可追踪画布
在 Boardmix 新建表格或白板，左侧放任务，顶部放角色，使用颜色区分 R/A/C/I，并在任务卡上附上原型、需求或验收链接。评审时只问三件事：每行是否有唯一 A、R 是否能交付、C 是否在截止前给出意见。会后把未解决的空白转成待办，下一次按状态筛选。
发布前检查：抽取三行关键任务，口头说出负责人、批准人和证据链接；如果任何人需要重新解释，说明矩阵还不够清晰。
常见问题
R 和 A 可以是同一个人吗？
可以，尤其是小团队，但要意识到执行与批准由同一个人承担，评审时要增加独立复核。
RACI 适合多大的项目？
适合跨角色协作且交付边界容易模糊的任务。两三个人的一次性小任务可以用简单的负责人字段替代。
下一步：把下一次评审或发布拆成 8—15 行交付物，再邀请相关角色在同一画布确认。
粤公网安备44030502008643