职场工具箱之 RACI：为什么“谁负责”说了三遍还是会翻车？

本文大纲

• 一、有没有经历过这样的场景？
• 二、什么是 RACI？
• 三、没有 RACI 的世界，到底有多乱？
• 四、RACI 的四条铁律
• 五、手把手教你画一张 RACI 表
• 六、除了开会、找领导帮忙，还有什么方法？
• 七、一个完整案例：新功能上线
• 八、RACI 的三个常见翻车姿势
• 九、技术人特别容易踩的坑
• 十、总结：核心概念表 + Checklist + 金句
• 十一、明天就能做的 3 件事
• 十二、思维导图
• 十三、系列回顾
• 十四、延伸阅读

一、有没有经历过这样的场景？

周一开会，领导说：“这个事情大家一起推一下。”

你以为他在说你，旁边的同事也以为在说他，结果到了周五——

“这个事情到底谁在跟？”

（全场沉默）

更扎心的版本是这样的：事情倒是有人做了，但三个人各做了一半，方向还不一样。最后在客户面前拼出来的方案，像一件左袖是西装、右袖是冲锋衣的“混搭外套”。

领导发火：“上次不是说了你来负责吗？”

你委屈：“我以为我只是协助啊……”

这种翻车，不是因为没人负责，而是因为“负责”这个词太模糊了。 “一起推一下”“你来牵个头”“大家配合一下”——听起来像分工，其实是“分糊涂”。

我在外企工作多年，深知跨团队、跨部门合作的难处。公司越大、人越多，推动你的方案落地、让你负责的事真正落地就越难。你的高优先级，到了别的团队可能只是中低优先级；你要是普通工程师，推动事情最终完成的难度就更大。RACI 不能解决所有问题，但至少能把“谁负责”从一句模糊话变成一张可对齐的表。今天这篇，就来聊这个专治“责任模糊”的经典工具——RACI 模型。

二、什么是 RACI？

RACI 是四个英文单词的首字母缩写，代表一件事情中四种不同的角色：

听起来像废话？但它解决的问题一点都不简单。

RACI 最大的价值，不是告诉你“谁干活”，而是把“负责”这个大词拆成了四种完全不同的参与方式。

因为职场里绝大多数的协作翻车，根源就一个：

每个人都觉得自己在“负责”，但每个人理解的“负责”不是同一个意思。

三、没有 RACI 的世界，到底有多乱？

场景：一次线上故障的善后

某天凌晨，线上系统挂了 2 小时。修复之后，领导在群里说了一句：

“这个事情要复盘一下，后续出一个改进方案。”

然后……

• 小张（一线开发） 以为自己要出复盘报告，花了两天写了一份。
• 小李（架构师） 也以为自己要出，从架构层面写了一版方案。
• 小王（项目经理） 觉得这事应该自己来组织，但一直在等别人先出初稿。
• 领导 等了一周，什么都没收到，因为小王以为小张在写，小张以为小王在统筹，小李写完了不知道发给谁。

一周后开会：

领导：“方案呢？”

小王：“我以为小张在出……”

小张：“我出了啊，但我以为小李在整合……”

小李：“我写了架构部分，但没人告诉我还需要整合啊……”

三个人都在干活，但产出像三块拼不上的拼图。

如果用 RACI 来分，30 秒就能说清楚

一张表，谁干活、谁拍板、要问谁、通知谁——清清楚楚。关键是那个 A——小王是最终负责人。如果方案延迟了，领导只找小王，不会去追小张和小李。 这就是“问责唯一性”的力量。

四、RACI 的四条铁律

RACI 不是随便填一填就管用的。用好它，有四条原则必须遵守。

铁律一：每一行有且只有一个 A

A 不能有两个人。 这是 RACI 最核心的规则。如果一件事有两个“最终负责人”，就等于没有负责人。

我见过很多团队在表格里填两个 A：“张三和李四共同负责”。结果呢？出了问题张三说“我以为李四兜底”，李四说“我以为张三在管”。

记住：A 只能有一个人。不是一个部门，不是一个小组，是一个具体的人。 如果你真的觉得需要两个 A，那说明这个任务应该拆成两个。

铁律二：R 可以有多个，但 A 必须能指挥 R

R 是干活的人，一件事可以有多个 R。但 A 要有权限协调这些 R。如果 A 是一个实习生，R 是三个高级工程师——这个 RACI 就是摆设。A 不一定是职级最高的人，但一定是 “能调动资源、能拍板” 的人。

铁律三：C 要在事前，I 在事后

• C（被咨询者） 的意见要在决策之前收集。你不能方案都定了再去“咨询”架构师，那叫“通知”。
• I（被知会者） 是在结果出来后告知。不需要他同意，但需要他知道。

很多人把 C 和 I 搞混，结果要么该问的人没问、方案一出就被打回来（漏了 C），要么不该参与决策的人非要掺和、会议无限膨胀（把 I 当成了 C）。

铁律四：不是每个人都要出现在每一行

如果你的 RACI 表里，每一行每个人都有角色——说明你没有真正做分工，你只是在“雨露均沾”。没有角色，就是最好的角色。 意思是：这件事跟你无关，你不用操心，安心做你那一行的事。

五、手把手教你画一张 RACI 表

1. 纵轴列任务——把事情拆细。不要写“完成项目”，要写：需求评审、技术方案设计、开发、测试、部署上线、上线后监控。细到什么程度？每一行都能对应到一个明确的交付物，就算够。
2. 横轴列人名——用人名不用部门。不要写“开发组”，要写“张三”。部门是一群人，一群人就意味着“不是我”。——咱们填表的时候，最容易偷懒写部门，一写就白写。
3. 每个格子填 R、A、C、I 或留空——问自己：谁来做？做砸了找谁？做之前要问谁？做完要告诉谁？跟这事无关就留空。
4. 检查三遍：每一行是否只有一个 A？是否至少一个 R？有没有人每一行都出现（过载）或全部是空（不该在这项目里）？

六、除了开会、找领导帮忙，还有什么方法？

很多人以为协作翻车只能靠“多开会”“找领导拍板”。这当然有用，但真到跨部门、跨团队的现场，你会发现：会开完了，事情还是可能卡住。 因为你的 P0，到别人那儿可能只是 P2；你喊“快点”，人家也未必有空理你。

我自己这些年踩下来，有几招比“喊一嗓子”更管用。

1）会前先把“表”填八成：让会议只剩“确认”

别等开会再讨论“谁负责”。你先把 RACI 表填个八成，拿着草稿去找关键的 A 和关键的 C 做 10 分钟对齐：
“我先按这个分了一版，你看哪里不对，我们现在改掉。会上我们只确认，不吵架。”

这样一来，会议从“扯皮现场”变成“确认现场”，效率差一大截。

2）把“我需要你帮忙”翻译成“你能得到什么 / 少背什么锅”

人微言轻的时候，别人不一定“听你”，但会“听利益、听风险、听省事”。

你别只说“请你们配合一下”，尽量说清三件事：

• 不做会怎样：会不会影响线上稳定？会不会影响交付节奏？会不会让对方背锅？
• 做了有什么好处：能少返工？能少被投诉？能让对方团队的指标更稳？
• 你能替对方扛多少：你把活干到什么程度，对方只要做最后一步？

一句话模板（能抄）：

“这件事对你们的影响是 X（风险/收益），我这边已经把 Y（准备工作）做完了，你们只需要做 Z（最小动作）。如果这周不做，最坏可能是……”

3）把协作做成“低成本”：先把脏活累活干掉

跨团队协作最怕的不是“别人不支持”，而是“支持一次要付出很大成本”。你能不能把成本砍到最低，往往决定别人愿不愿意跟你干。

比如你别让对方“从零开始”，你给：

• 一页纸的背景 + 目标 + 影响范围
• 预填好的 RACI 表（对方只要改几格）
• 已经跑通的 demo / PoC
• 你先写好的 PR / 配置草稿（对方只 review）

你把球传得越顺，对方越愿意接。

4）如何说服别人一起干：讲三件小故事

我不太爱用鸡汤，但有些老故事确实挺贴合“协作推进”这件事。

• 商鞅立木为信：先立一个小承诺，兑现它，再谈大事。跨团队协作也是一样——先把你说“我来搞定”的那一小段做实，信誉起来了，后面你再提要求，阻力会小很多。
• 三顾茅庐：想请关键的人出手，光在群里 @ 三次通常没用。真正有用的是“上门把问题讲清楚，把对方的顾虑拆掉”。说白了，就是把对方当人，不把人当资源。
• 富兰克林效应（Ben Franklin 的小故事）：先请对方帮一个小忙（比如“帮我看一眼这张表有没有坑”），往往比你直接求他“投入一周人力”更容易。小忙做成了，合作的门就开了。

RACI 是工具，上面这些是“让工具真正生效”的手艺。两者一起用，才更像在真实职场里打仗。

七、一个完整案例：新功能上线

假设你们团队要上线一个新功能，涉及：产品经理（PM）、前端（FE）、后端（BE）、测试（QA）、技术负责人（TL）。

几个值得注意的点：PM 在“需求文档”既是 R 又是 A（自己写自己担责）；TL 在“技术方案”和“上线发布”是 A（技术决策他负最终责任）；QA 在“联调测试”是 A、R 是前后端（验收归 QA，修归开发）。这张表的意义不在于表本身，而在于填表的过程——它逼着你把模糊的口头分工，变成清晰的书面共识。

八、RACI 的三个常见翻车姿势

翻车 1：A 太多——“三个和尚没水喝”
一行里出现两个甚至三个 A，每个 A 都以为另一个在兜底。药方：一行一个 A，没有例外。有争议就升级给上级决定。

这个典故我小时候就听过（有的版本说“没水喝”，有的说“没水吃”，意思都一样）：
一个和尚的时候，挑两桶水，累归累，但总归有人干；两个和尚的时候，抬一桶水，分工一明确，效率还挺高；三个和尚的时候就热闹了——甲说“你是大师兄你去”，乙说“你最年轻你去”，丙说“反正有人会去”，结果谁也不动，最后真就没水了。

放回 RACI 里就一句话：A 一旦变成“大家都负责”，就等于“没人负责”。

翻车 2：把 RACI 当“挡箭牌”
有人拿着表说“这不是我负责的”，然后眼睁睁看着事情掉地上。药方：RACI 是“底线”不是“上限”。你的 R 是你必须做的，但不代表你不能帮别人。看到事要掉了，先接住，再回来对齐 RACI。

翻车 3：填完就忘——形式主义 RACI
项目启动时填了一张表，之后就没人打开过。人员、任务变了，RACI 没更新。药方：RACI 是活文档。项目有变更就花 5 分钟更新，放在项目文档最显眼位置，不是附录是首页。

九、技术人特别容易踩的坑

• 只认“我这一块 R”，不认“整体交付”：接口你写、前端他写，联调出问题都说不是自己的 R。RACI 解决的是“谁担责”，不是“谁可以甩锅”。A 只有一个，但 R 之间要协作，掉链子时先补位再论责。
• 把 C 和 I 混成一锅粥：该事前问架构师的没问（漏 C），不该拉进决策的人拉进每个会（把 I 当 C）。结果要么方案被打回，要么会议永远开不完。记住：C 是决策前征求意见，I 是结果后知会。
• RACI 表里全是部门名：“开发组”“测试组”一写，等于没写——谁代表开发组？写具体人名，责任才能落到人。

十、总结：核心概念表 + Checklist + 金句

一句话记住 RACI： 谁做（R）、谁扛（A）、谁问（C）、谁知（I）——四个字治好“我以为有人在管”。

自检 Checklist：

• [ ] 每一行有且只有一个 A
• [ ] 每一行至少有一个 R
• [ ] A 能指挥得了 R（权限/职级合理）
• [ ] C 在事前、I 在事后，没搞反
• [ ] 用人名不用部门名
• [ ] 项目有变更时更新了 RACI

适用边界：RACI 适合跨角色、跨部门、任务一多就扯皮的项目或迭代。固然好用，可是两三个人、任务极简单时，口头说清就行，不必强行上表。代价是填表和维护要花点时间，但能避免“说了三遍谁负责还是翻车”的更大代价。

很多项目不是死在技术上的，是死在“我以为你在管”上的。下次启动一个项目、接手一个任务、开始一段跨部门协作——别急着干活，先花 10 分钟画一张 RACI 表。把“谁负责”从一句模糊的口号，变成四个清晰的角色。 翻车的概率，至少降一半。

十一、明天就能做的 3 件事

1. 挑一个正在进行的多角色任务，画一张 RACI 表（10 分钟）

2. 怎么算做得好：纵轴是具体任务/交付物，横轴是人名，每行只有一个 A，和团队对齐过。

3. 把“RACI 检查”写进下一次项目启动或复盘会议（5 分钟）

4. 怎么算做得好：会议里有一项“谁 R 谁 A 谁 C 谁 I”，有人负责更新到项目文档显眼位置。

5. 遇到“这事谁在跟”的糊涂账时，用 RACI 反推（5 分钟）

6. 怎么算做得好：能指出缺的是 R 还是 A，并提议补上一张表再继续。

十二、思维导图

@startmindmap
<style>
mindmapDiagram {
  node { BackgroundColor #F8F9FA; RoundCorner 8; Padding 8; FontSize 13 }
  :depth(0) { BackgroundColor #2C3E50; FontColor white; FontSize 16; FontStyle bold }
  :depth(1) { FontSize 14; FontStyle bold }
  :depth(2) { FontSize 13 }
}
</style>

* RACI 责任矩阵
** R 执行者
*** 动手干活的人
** A 问责者
*** 拍板担责 唯一
*** 一行一个 A
** C 被咨询者
*** 事前征求意见
** I 被知会者
*** 事后告知
** 四条铁律
*** 每行只有一个 A
*** A 要能指挥 R
*** C 事前 I 事后
*** 不必每行都有每个人
** 画表四步
*** 纵轴任务 横轴人名
*** 填 R/A/C/I 或留空
*** 检查 A 唯一、有 R
** 推动落地（人微言轻也能推）
*** 会前预对齐（先找 A / C）
*** 把请求翻译成收益/风险/省事
*** 降低协作成本（草稿/PR/demo）
*** 小承诺换信用（先兑现再谈大）
** 常见翻车
*** A 太多
*** RACI 当挡箭牌
*** 填完就忘
@endmindmap

十三、系列回顾

职场工具箱系列已发文章（节选）：

• 4D 总结法
• 黄金圈法则
• TNB 表达模型
• 第一性原理
• RACI 责任矩阵（本篇）

下一篇预告：三点法（上中下三策 / 三要点 / 三 W 法）——把复杂决策收束成三个选项，让领导和同事听得懂、记得住。

十四、延伸阅读

• 金字塔原理 — 结构化表达
• 非暴力沟通 — 协作与反馈

你在工作中有没有遇到过 “三个人都以为对方在负责” 的翻车故事？用 RACI 复个盘，你会怎么填那张表？

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。