3 月 18 日要上线，3 月 11 日才发现迁移脚本没人写。问小李，小李说“我以为周哥会安排”；问周哥，周哥说“这不是供应商的活吗”。三个人都不算懒，问题在于“负责”这个词在三个人心里指的不是同一件事。
这类事故很少来自能力问题，多来自责任分配没有明确下来。下面把四种参与方式拆开，再讲怎么把它们写成一张能用的表。
一、四个词分的是两件事，不是四个级别
项目管理里常见的一套写法叫 RACI，PMBOK 把它归入职责分配矩阵（responsibility assignment matrix）这一类工具 2，四个字母对应四种参与方式：
- R（Responsible，执行）：负责具体执行，并对这件活做得对不对负责。可以有好几个人。
- A（Accountable，拍板）：为结果向外承担、能做出最终决定的那个人。同一行只能有一个。
- C（Consulted，被咨询）：做事之前必须问的人，双向沟通，他的意见可能改动方案。
- I（Informed，被告知）：事后必须知道的人，单向通知，他知道了也不会改变做法。
关键在于：这四种角色不是按职位高低划分的，而是按“这个人什么时候参与这件事、参与时是双向还是单向”划分的 5。总监可以是某行的 I，一线运维可以是另一行的 A。想不通一个人该填哪个字母时，只问两句：他是在做、在定，还是在被问、被告知？他是在事前介入，还是事后？
二、第一组容易混的：干活的人与拍板的人
R 和 A 最容易被当成同义词，现实里也经常由同一个人担任。区别在两点：出了事谁去解释，以及谁能在最后一刻推翻。
A 为什么只能有一个：它的实质是承担后果——延期了要向上解释，方案失败要写复盘，而后果只会落到一个名字上。更实际的原因是决策：两个 A 等于给冲突留了两个出口，事情会在“要不要再找他确认一下”里耗掉一两周。业界指南里“一行只能有一个 A”这条规则 3，管的就是这个。
R 和 A 为什么要分开：定的人和做的人是同一个，等于自己给自己签字，复核这一环就消失了。这也是“这个项目你负责”这句交代不完整的地方——它没说清你说的是执行还是拍板。
不过要如实说明有重叠：小项目里 R 和 A 常常就是同一人，这没有问题，但要在表上写明是 R/A，并清楚这时候缺的是什么——缺一个能推翻你的复核人。补法两条：指定一个必须问的 C（他不同意你得给出理由），或者把 A 上移到部门负责人，你只做 R。
有一个场景最能检验有没有真懂：老板说“这块你最熟，你定”。听起来 A 给了你，其实未必。判断方法只有一句：如果你定完，他会不会推翻？会，那 A 还是他，你只是 R 加 C。填表时顺手问一句“如果我的方案和你想的不一样，是我定还是你定”，比事后争执更省事。
反过来也有个常见错误：A 那一格填“客服部”“运维团队”。不行，A 要落到具体的人，因为出事时“我们部门讨论过了”不是一句可追问的话。
三、第二组更容易混的：被咨询与被告知
这两格只差两点：事前还是事后，双向还是单向。C 是在方案定型前问的人，他的回答会改动方案；I 是定型后通知的人，通知只是让他能安排自己的事。
判断可以用一句话：告诉他之后，他会不会改变做法？会，就是 C；不会，就是 I。
I 泛滥是最常见的失败：把抄送当知情，三十个人在通知列表里，出事时没有一个真正知道。I 的判断依据是“他不知道会耽误他自己的活”，而非“他关心”。财务要知道上线日期，因为他得排付款，排不上会卡住迁移——这个 I 必须留。隔壁组同事说“也让我知道一下”，可以拒绝。
C 的边界方向相反：C 太多，等于谁都能提要求，但没人为工期负责。C 是“必须问”，不能理解为“可以问”，可以问的人不进表。
还有第三种人，看似 C，实际不是：安全评审、法务、财务合规这类签字环节。他平时只是“给意见”，但他说不行就是不行。Bain 的 RAPID 框架把这种角色单独拆出来叫 Agree，也就是带否决权的正式同意 4。不要把它混进 C：C 的意见可以被权衡后不采纳，Agree 的意见只能被满足，或者拿到更高一层去改规则。在表上用一个记号标出来，能省掉很多“我早就说过有风险”的争论。
四、把表建出来：行用交付物，列写人名
行不按具体动作逐项列出，而是按交付物和“要拍板的岔路”来。交付物直接从 WBS 里抄——上一篇讲过，WBS 一直拆到能派出去为止（用 WBS 把定好的范围，拆成能派出去的活）。再补几行并非具体工作、但需要人做决定的事项：要不要延期上线、砍哪个功能、验收谁签字。这类决定最容易在出事时没人认。
列写具体人名，不写部门。整张表一页纸、二十行以内。
沿用客服系统迁移项目的例子：
| 交付物或决定 | A 拍板 | R 执行 | C 必须问 | I 事后知道 |
|---|---|---|---|---|
| 迁移脚本 | 周（项目经理） | 小李 | 供应商工程师 | 客服主管 |
| 培训材料与排课 | 客服主管 | 小陈 | 周 | 客服组长 |
| 试跑是否算通过 | 测试负责人 | 测试小吴 | 运维、周 | 部门总监 |
| 信息安全评审 | 安全部门评审人（具体到人） | 周（备材料） | — | 部门总监 |
| 是否按期上线 | 部门总监 | 周 | 客服主管、安全评审人 | 全体客服 |
填完先检查三种常见问题：
- 整行没有 A：出事时互相等，就是开头那个场景。
- 一行两个 A：谁都能定，等于谁都不能定。
- C 列五六个、I 列快把全公司写进去：判断会被意见淹没，通知也会被忽略。
五、表上面加一句定义，表后面加一条备用规则
表只写“谁”，不写“怎么算”，所以表头上面要加一句本项目自己的定义，把字母写成人能执行的行为：“本项目的 A，是两个方案争不出结果时说话的那一个，也是延期时去向上级解释的那一个。”
这句话不多余。同一个词在不同公司、甚至不同语言里意思会反过来：法文版 RACI 里 R 是“对结果负责”、A 是“具体执行”，和英文正好颠倒 13。有咨询顾问讲过一个例子：一家用了多年 RACI 的公司，让三十个合伙人投票“谁最终拍板”，一半说 A，一半说 R 6。不先明确词义，表越规范，误会越深。
最后留一条备用规则：表上那个 A 出差、离职、或者装不知道时怎么办。可以预先定下一条规则——先找表上那个人的上一级，两个工作日内必须给答复，并把结论记进周会记录。没有这条，职责表就只是纸。
表的价值不在分工那一刻，而在冲突那一刻：有人能说“这件事的 A 是我，我定了”，也有人能说“这件事的 A 不是你，你去问他”。