RACI 责任矩阵的作用只有一个：让每件事都有明确的负责人和决策人。它解决的是那种典型的困境——项目卡住了，你不知道该找谁推进；出了问题，几个人都说"这不是我这边定的"。
但很多团队填完 RACI 之后情况没有改善，原因通常是同一个：一行里标了两三个 A。有三个人有最终决定权，等于没人有决定权。
一、四种角色的准确含义
| 字母 | 全称 | 含义 | 数量要求 |
|---|---|---|---|
| R | Responsible | 实际执行这件事的人 | 至少 1 个，可多个 |
| A | Accountable | 对结果负最终责任、有决策权 | 有且只有 1 个 |
| C | Consulted | 决策前必须征询意见的人 | 0 到若干 |
| I | Informed | 结果出来后需要被告知的人 | 0 到若干 |
R 和 A 的区别是最常被搞混的。 R 是干活的人，A 是拍板并承担后果的人。两者可以是同一个人，但职责性质不同：
- 事情没做完，找 R
- 事情做错了方向，找 A
- 方案要改，A 说了算
C 和 I 的区别在于时机。 C 是决策前要问的，他的意见会影响决定；I 是决策后要告知的，他不参与决策但需要知道结果。
把应该是 C 的人标成 I，后果是他事后跳出来反对，事情返工；把应该是 I 的人标成 C，后果是决策链条变长，什么事都推不动。
二、每行只有一个 A
这是 RACI 最核心也最容易被违反的规则。
为什么必须只有一个：A 代表最终决策权和责任归属。两个人同时有决策权，遇到分歧时就会僵住，或者互相推诿。"共同负责"在实践中通常等于"没人负责"。
常见的破例冲动：
- "这件事产品和技术都要拍板" → 拆成两行。技术方案选型 A 是技术负责人，功能范围 A 是产品负责人
- "这是我们两个部门一起的事" → 找到共同上级，或者拆成两个可分离的子任务
- "老板才是最终决策人" → 那 A 就是老板，但要确认他真的会看、会拍板。挂个名不参与的 A 比没有 A 更糟
如果实在拆不开、也找不到唯一的 A，说明这件事的权责设计本身有问题，应该先解决这个问题，而不是在表格里含糊过去。
三、填写顺序
不要横着一行行填，按这个顺序效率更高：
第一步：列任务清单（行）。 粒度以"能被独立分配和验收"为准。太粗（"完成项目"）没有意义，太细（"发一封邮件"）会让表格失控。一个中型项目通常 15–30 行合适。
第二步：列角色（列）。 建议写岗位不写人名——人会变动，岗位相对稳定。人员对应关系单独维护。
第三步：先把所有 A 填完。 一行一个，全部填完再往下走。这一步会暴露最多问题：某些行找不到唯一的 A，某个人被填成十几行的 A（超载了）。
第四步：填 R。 A 已定的前提下，R 通常很清楚。
第五步：填 C 和 I。 这一步要克制。C 越多决策越慢，每加一个 C 都要问"不问他会出什么问题"。
四、填完之后的三个检查
横向检查（每行）：
- 有且仅有一个 A 吗？
- 至少有一个 R 吗？没有 R 说明这件事没人干
- C 是不是超过 3 个？超过就要精简
纵向检查（每列）：
- 某个人是不是 A 的行特别多？可能超载，考虑下放
- 某个人是不是全列都是 I？他可能不需要出现在这张表里
- 某个人是不是全列都是 C？说明他成了瓶颈，所有事都要问他
整体检查：
- 有没有全是 I 没有 R 的行？那件事实际上没人做
- 有没有一个人既是 R 又是 A 又占了大半行？团队可能过度依赖单点
五、什么时候需要 RACI，什么时候不需要
RACI 有维护成本，不是所有场景都值得用。
适合用的：
- 跨部门项目，责任边界本来就不清
- 参与方超过 5 人
- 有明确的交付物和验收环节
- 出过"没人做"或"重复做"的问题
不必用的：
- 3 人以内的小团队，直接说清楚更快
- 常规重复性工作，责任早已固化
- 探索期项目，分工每周都在变
判断标准：有没有出现过"这事谁负责"的争议？ 出现过就值得填；没出现过，填了也只是一份没人看的表格。
六、和泳道图配合使用
RACI 和泳道图解决的是同一类问题的两个侧面：
| RACI | 泳道图 | |
|---|---|---|
| 表达 | 谁对什么负责 | 事情怎么流转 |
| 形态 | 矩阵 | 流程图 |
| 强项 | 决策权归属清晰 | 交接顺序和条件清晰 |
| 弱项 | 看不出先后顺序 | 看不出谁有决策权 |
推荐组合用法：先画泳道图理清流程和交接点，再对着流程里的关键环节填 RACI 明确决策权。两者对照时会发现问题——比如泳道图上某个环节只由一个部门执行，但 RACI 里这件事的 A 在另一个部门，这个错位就是潜在的卡点。
在同一块画布上把泳道图和 RACI 表并排放，对照检查会顺手得多。英飞·思想家支持表格、图形等多种组件同屏组合，多人实时协作，各方可以在自己负责的行上直接批注确认。
七、RACI 的几种变体
标准 RACI 之外，实践中常见几种扩展，按需选用：
- RASCI——多一个 S（Support），区分"执行"和"提供支持"。适合有共享服务团队的组织
- RACI-VS——多 V（Verify）验证和 S（Sign-off）签署。适合合规要求高的行业
- DACI——用于决策场景：Driver 推动者、Approver 批准者、Contributor 贡献者、Informed 知会者
不建议一上来就用复杂变体。 标准 RACI 已经能解决八成问题，变体增加的准确度往往抵不过增加的维护成本。
八、维护与更新
RACI 最常见的死法是填完就没再看过。三条建议：
放在项目材料所在的地方。 和排期、需求文档、流程图放在同一块画布上，讨论时随手可查。存成单独的 Excel 塞进网盘，基本等于不存在。
人员变动时立刻更新。 这是最高频的失效原因——某个 A 离职或转岗，表格没改，事情就悬空了。
每个里程碑复核一次。 项目推进过程中职责会自然演化，定期对照实际情况修正。
常见问题
R 和 A 有什么区别？
R 是实际干活的人，A 是拍板并对结果负最终责任的人。可以是同一个人，但性质不同：事情没做完找 R，方向错了找 A。
为什么每行只能有一个 A？
A 代表最终决策权。两个人同时有决策权，遇到分歧会僵住或互相推诿。"共同负责"在实践中通常等于没人负责。
C 和 I 怎么区分？
C 是决策前必须征询的，意见会影响决定；I 是决策后需要告知的，不参与决策。搞混会导致事后返工或决策链条过长。
多大的项目才需要 RACI？
参与方超过 5 人、跨部门、或出现过"这事谁负责"的争议时值得填。3 人以内的团队直接沟通更快。
填完之后怎么维护？
放在项目材料所在的地方随手可查，人员变动时立刻更新，每个里程碑复核一次。
结语
RACI 的全部价值集中在一条规则上：每行有且只有一个 A。这一条守住，权责就清楚了；守不住，填得再全也解决不了"这事谁定"的问题。
填写时先把所有 A 填完再往下走，C 的数量要克制。配合泳道图一起用，流程和权责能互相校验。