我以前总天真地以为，大家都是成年人了，工作任务分配下去，大家自然知道该干嘛、该找谁汇报。直到2019年那次惨痛的“全员推送事故”，狠狠给了我一巴掌。
当时我们要做一个活动上线通知，运营觉得技术会配置自动发送，技术觉得运营会手动操作后台。结果就是：活动上线了，用户端静悄悄，全公司大眼瞪小眼。
事后复盘，两边都在扯皮，且听起来都有道理。那时候我才明白：团队里最可怕的不是坏人，而是模糊的“默认共识”。
这几年带项目，踩过不少坑，也填过不少坑。我发现解决这种“谁该干啥、谁该背锅、谁该知情”的问题，最好用的工具还是 RACI 模型。别被这个洋名字吓到，今天咱们不聊枯燥的理论，我就聊聊怎么用它解决真实的协作痛点。
一、 R和A不分：当所有人都在负责，就是没人负责
这是我见过最典型的“大坑”。很多项目表里，负责人那一栏填满了名字：产品经理、后端组长、前端组长… 看起来阵容豪华，一旦出事，所有人都在互相指责。
这里必须通过 RACI 厘清两个概念：
- R (Responsible 也就是“执行人”)：谁在干活？谁在写代码、画图、写文档？
- A (Accountable 也就是“负责人”)：谁对结果有最终决定权？谁对失败负全责？
真实案例： 两年前做个数据迁移项目，涉及到老数据清洗。当时的表格里，把开发小李（R）和产品经理 Sarah（A）都标成了“负责人”。
结果出了个 Bug，部分VIP用户数据字段错位。 小李说：“我是按文档写的逻辑跑的脚本，文档没定义这个边界情况。” Sarah说：“脚本是你写的，上线前你不自测吗？”
这事儿卡了两天，直到我介入强行定了规矩：R可以有很多个，但A（拍板的人）只能有一个。
在这个案例里，Sarah 作为 A，她必须在脚本跑之前 Review 逻辑，如果她没发现文档漏洞，那就是她的责任，不能怪执行层的小李。
我的避坑心得： 如果一个任务后面标了两个 A，那约等于没有 A。也就是俗话说的“一个和尚挑水喝，两个和尚没水喝”。
二、 C和I混淆：“被通知”不等于“被尊重”
跨部门协作里，还有一种常见的架是这么吵的：“改这个功能为什么不提前告诉我？”
这就是搞混了 C (Consult 咨询) 和 I (Inform 通知)。
- C (咨询)：是在做决定之前，需要听取意见的人。比如双向沟通。
- I (通知)：是决定做完之后，单向告知结果的人。
真实案例： 去年双十一前夕，我们的UI设计师觉得原来的结算按钮颜色太土，把“橙色”改成了“红色”。他把这事告诉了前端开发（这是I），觉得完事了。
结果上线后，客服部门炸了。因为客服所有的帮助文档截图、给用户的指引话术里，写的都是“点击橙色按钮”。客服主管直接冲到产品组拍桌子。
复盘来看，设计师犯了个大忌： 对于前端开发，这是个样式修改，只要 I（通知）到位就行； 但对于客服部门，这涉及到服务流程的变更，他们应该是 C（咨询对象）。如果在改版前问一句客服，他们可能会说：“改颜色可以，但要给我们留2天时间更新知识库。”
从那以后，我在项目启动会上都会强制画一张表：
| 任务节点 | 谁干活(R) | 谁拍板(A) | 问谁意见(C) | 邮件抄送谁(I) |
|---------------|----------|----------|------------|--------------|
| UI视觉改版 | 设计师 | 设计总监 | 客服/前端 | 全员 |
分清楚 C 和 I，能帮你省掉80%的“情绪型”撕逼。
三、 拒绝RACI膨胀：别把大家都拉进会议室
很多朋友用了 RACI 后，发现效率反而低了。为啥？因为他把太严谨，把所有人都卷进来了。
我以前也犯过这个毛病，为了显得“民主”和“严谨”，把一个API接口的变动，设置了5个 C（咨询对象）。结果就是，原本半小时能定下的技术方案，因为要等这5个人发表意见（有的还是跨时区的），硬生生拖了一周。
这里有个反直觉的经验：RACI 是用来做减法的。
如果你发现一个任务的 C（咨询）这一栏超过了 3 个人，大概率是你的流程有问题。要么是职权划分不清，要么就是你在试图通过“拉人头”来分摊风险。
我个人的实操习惯： 每周五下午，我会花15分钟梳理下周的重点项目。我会特别关注那些 C 角色过多的人。我会直接私聊问他：“这个改动，如果你不知道细节，会死人吗？” 如果他说“不会”，那我立马把他从 C 降级为 I。
降级的好处显而易见：
- 他不用参加冗长的评审会了（他爽）。
- 我们不用等他的反馈就能推进了（我也爽）。
结尾与行动建议
RACI 不是一张冷冰冰的表格，它本质上是一种**“把丑话说在前面”**的沟通契约。它不保证项目一定成功，但它能保证项目失败时，大家知道怎么死得明明白白，下次好改进。
那么，回到你的实际工作中： 你觉得 R、A、C、I 这四个角色里，哪一个在你的团队里最容易缺位或者错位？
- A：没人敢拍板？
- C：改了东西不告诉相关方？
欢迎在评论区告诉我你的痛点。
最后，给到3个明天上班就能用的落地建议：
- 只对“模糊地带”用 RACI：别连“谁负责订盒饭”都搞个矩阵，那叫没事找事。只针对那些跨部门、容易扯皮的关键节点画表。
- 寻找唯一的 A：检查你手头项目的任务表，任何一行如果有两个 A，请立刻找这两个人开会，砍掉一个，或者拆分任务。
- 定期清洗 I 名单：不要把邮件抄送全公司。信息噪音也是一种协作阻碍，把那些根本不看邮件的人，从 I 里踢出去。
协作不易，希望咱们都能少一点“我以为”，多一点“按规矩”。