RACI 矩阵 · 责任分配工具 - 管理者学习平台

RACI 矩阵 · 责任分配工具

RACI 矩阵（也称为责任分配矩阵 / RACI 图）是一个用于明确"谁对什么负责"的经典管理工具。它通过一个二维矩阵，将任务/决策项与角色/人员交叉，并在每个交叉点标注 R/A/C/I 四种角色之一，从而将模糊的"大家一起做"转化为清晰的"谁做什么"。
RACI 解决的核心问题是管理中最常见的三大痛苦——责任真空（没有人负责）、责任重叠（多人同时负责同一事）、沟通错位（做的人不知道、知道的人不做）。一份高质量的 RACI 矩阵，就是团队协作的"交通规则"。

一、四个角色详解：R / A / C / I 各是什么

Responsible · 执行者

负责完成任务的人。执行实际工作，产出交付物。一个任务可以有多个 R（多人协作完成）。

关键词：做 / 执行 / 产出

Accountable · 负责人

对任务最终结果负责的人。拥有否决权，对成败承担最终责任。一条任务有且只有一个 A（这是 RACI 最重要的原则）。

关键词：拍板 / 负责 / 成败

Consulted · 咨询者

在决策或执行前需要被征求意见的人。通常是具备专业知识或掌握信息的人。沟通是双向的——C 给出意见后，执行者需要反馈。

关键词：咨询 / 专业意见 / 双向沟通

Informed · 知情者

需要被告知进展和结果的人。不需要征求他们的意见，他们也不参与决策，只需被通知。沟通是单向的。

关键词：通知 / 信息同步 / 单向沟通

二、RACI 的核心原则

每个任务有且只有一个 A（Accountable）：这是 RACI 最不可妥协的原则。没有 A 就意味着没有人最终负责，多个 A 就意味着相互推诿。
R 可以有多个，但建议控制在 2-3 个以内：一个任务可以多人协作执行，但过多 R 会导致协调成本飙升。如果超过 3 人，建议拆分成多个子任务。
C 和 I 不是"越多越好"：每个 C 都意味着沟通成本——需要召开会议、征求意见、等待反馈。每个 I 意味着信息通道。只放真的需要的人。
高层不要做 R，要做 A 或 C：如果你发现一个部门经理在矩阵中被标为很多 R，说明他没有有效授权。管理者应当是 A（对结果负责）或 C（提供咨询），而不是 R。
不是每个任务都需要全部四种角色：有的任务可能只有 R 和 A（简单任务），有的任务可能需要 R + A + C + I（涉及跨部门决策的复杂任务）。按需选择。

三、七步法：从零构建 RACI 矩阵

第一步 · 明确范围：这张矩阵是用来做什么的？是"新产品发布全流程"还是"日常运营决策"？范围不同，矩阵内容完全不同。
第二步 · 梳理所有关键任务：将范围内的所有关键任务（或决策点）列出来，建议 10-25 个（太多则难以使用，太少则过于粗）。可以与 WBS 工作包对齐。
第三步 · 梳理所有关键角色：将参与这些任务的角色/人员列出来，放在矩阵的顶部。建议用角色（如"产品经理"）而不是具体人名（如"张三"），以提升通用性。
第四步 · 为每个任务分配 R/A/C/I：从第一个任务开始，逐个讨论：谁是最终负责人（A）？谁来做具体工作（R）？需要咨询谁（C）？谁需要被告知（I）？建议组织团队共创会议完成。
第五步 · 检查"只有一个 A"原则：横向扫描每个任务，确保只有一个 A。如果发现有多个 A 或没有 A，立即讨论解决。
第六步 · 检查"角色分布合理性"：纵向扫描每个角色。某个角色是不是被标了太多 R？某个角色是不是没有任何 A？这些往往反映了组织或授权上的问题。
第七步 · 全员对齐并公开发布：将完成后的 RACI 矩阵在团队会议上逐条对齐确认，然后公开发布。它应当是"活文档"，定期（如季度）回顾更新。

四、完整案例：新产品发布的 RACI 矩阵

以下是一个典型场景：某公司"新产品 X 发布项目"的 RACI 矩阵。横向是 5 个关键角色，纵向是 10 个关键任务。注意观察每个任务的 A 是谁、R 是谁。

关键任务 / 决策项	产品总监	技术负责人	市场经理	销售总监	客户成功
1. 产品愿景与路线图制定	A	C	C	C	I
2. 产品需求定义与 PRD 撰写	A	R	C	I	C
3. 技术架构方案设计	C	A	I	I	I
4. 开发与测试执行	C	A	I	I	I
5. 市场推广策略与预算制定	C	I	A	C	I
6. 品牌与内容素材制作	C	I	A / R	I	I
7. 销售培训与话术准备	C	C	R	A	C
8. 正式发布日期决策	A	C	C	C	I
9. 首批客户上线与支持	C	R	I	R	A
10. 发布后数据复盘	A	R	R	R	R

案例解读：观察这个矩阵，可以得到以下管理洞察：① 产品总监是项目总负责人（最多 A），这符合"产品驱动"的组织；② 技术负责人承担了大量 R 和 C，说明他是执行的核心力量；③ 销售总监主要参与销售相关环节，这是合理的——他对产品开发没有决策权，但对销售培训是 A；④ 客户成功是"首批客户上线与支持"的 A，这确保了客户体验的最终责任有人担；⑤ "发布日期决策"这个任务特别重要——产品总监是唯一的 A，但所有人都是 C，这体现了"听大家的意见，由一个人做最终决策"的健康模式。

五、适用场景：什么时候用 RACI

场景	描述	典型痛点 / 使用时机
跨部门项目	多个部门协作完成一个项目，如"新产品发布""年度品牌活动"	典型痛点："这个事应该谁管？""我以为他们会做"——RACI 一次性解决所有模糊地带
流程优化/再造	梳理某条关键业务流程（如"客户投诉处理""合同审批流程"）	典型痛点：流程反复卡住、不知道谁该做什么——RACI 让每个节点有明确负责人
角色澄清	新团队组建或组织架构调整后，明确每个人的职责边界	典型痛点：新团队成员"什么都做、什么都不担责"——RACI 作为团队的"职责契约"
关键决策事项	对公司重要决策事项，明确谁提供信息、谁提出方案、谁拍板	典型痛点：决策缓慢、人人都有意见但没人拍板——RACI 明确 A 是谁
新管理者上任	管理者新接手一个团队，需要快速理清职责边界	典型痛点：对现有团队职责不了解，要么过度干预要么放任——RACI 作为上任第一工具

六、常见错误与误区

❌ 错误 1：每个任务都把所有人标上 C 或 I

"先把所有人都放进去，至少信息同步到了"——这是最常见的偷懒式做法。结果是：没有人读、没有人信、沟通成本反而增加。C 和 I 的数量应当显著少于 R 和 A。

❌ 错误 2：一个任务有多个 A（或者没有 A）

没有 A = 没有人最终负责；多个 A = 人人有责等于人人无责。这是必须严格遵守的原则——如果讨论中发现多个 A，就要继续讨论，直到选出一个。

❌ 错误 3：管理者一个人"填"出矩阵，不与团队讨论

RACI 的价值不在"写出来"而在"讨论出来"——讨论过程中大家对职责的理解会自然对齐。跳过讨论环节直接发布，结果就是没人遵守。

❌ 错误 4：经理被标了太多 R

纵向扫一眼矩阵，如果一个部门经理被标了 10 个 R，说明他没有授权，团队在"等他来做"。管理者应当是 A（对结果负责），R 要交给团队成员。

❌ 错误 5：做完一次就束之高阁

RACI 是"活文档"。组织架构调整、项目阶段变化、人员变动都需要更新矩阵。建议季度回顾一次。

📝 实操练习：为你最痛的那个跨部门协作场景做 RACI

请回想最近 1 个月内，你团队经历过的一次最"痛"的跨部门协作事件（可能是项目延期、责任推诿、沟通混乱）。按以下步骤完成：

写清范围：用一句话描述"这次 RACI 是解决什么场景的职责问题"。
列出任务：在这个范围内，有哪些关键任务/决策项？建议 8-15 个。
列出角色：有哪些部门/角色参与其中？建议 4-6 个。
画矩阵并填充：画一个二维表格，逐条为每个任务分配 R/A/C/I。严格遵守"每个任务一个 A"原则。
横向 + 纵向检查：横向检查每个任务的 A 是不是唯一？纵向检查每个角色的分布是不是合理？
与关键人对齐：找到 2-3 个核心相关角色，和他们过一遍矩阵。讨论中一定会有"原来你也以为我在做这件事"的发现——这正是 RACI 的价值。

建议时间：60-90 分钟。完成后你会发现——仅仅通过"明确谁管什么"，就能消除 50% 的协作摩擦。