# 谁做、谁拍板、谁只要知道：用一张职责表把项目分工写清楚

RACI 四个角色的分界、为什么一行只能有一个 A，以及表建好后要补的两样东西

> 角色与职责 · 项目管理基础 · 任务拆解 · 约 7 分钟 · 10 月 28 日

## 本篇要点

1. R、A、C、I 四个角色的分界不在职位高低，而在这个人什么时候介入、介入是双向还是单向。
2. A 是承担后果、做出最终决定的人，一行只能有一个；R 可以有多人，两者分开的意义是保留复核这一环。
3. 判断 A 归谁，不看谁更懂，而看谁在最后一刻能推翻决定；老板说“你定”时，只要他会推翻，A 就还是他。
4. 区分 C 和 I 只需一问：告诉他之后，他会不会改变做法？会就是 C，不会就是 I。
5. 带否决权的签字方（安全、法务、财务）不等于普通 C，只能被满足或走更高层改规则，要在表上单独标出。
6. 职责表的行用 WBS 交付物加关键决定，列写具体人名；建完检查三种问题：整行缺 A、一行两个 A、C 和 I 泛滥。
7. 表之外还要两样东西：一句本项目对四个字母的行为定义，一条 A 缺席时向上找一级的备用规则。

---

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 把定好的范围，拆成能派出去的活](https://pangzhengboyin.com/articles/wbs-decompose-scope-into-work-packages-ae48b54e)）。再补几行并非具体工作、但需要人做决定的事项：要不要延期上线、砍哪个功能、验收谁签字。这类决定最容易在出事时没人认。

列写具体人名，不写部门。整张表一页纸、二十行以内。

沿用客服系统迁移项目的例子：

| 交付物或决定 | A 拍板 | R 执行 | C 必须问 | I 事后知道 |
| --- | --- | --- | --- | --- |
| 迁移脚本 | 周（项目经理） | 小李 | 供应商工程师 | 客服主管 |
| 培训材料与排课 | 客服主管 | 小陈 | 周 | 客服组长 |
| 试跑是否算通过 | 测试负责人 | 测试小吴 | 运维、周 | 部门总监 |
| 信息安全评审 | 安全部门评审人（具体到人） | 周（备材料） | — | 部门总监 |
| 是否按期上线 | 部门总监 | 周 | 客服主管、安全评审人 | 全体客服 |

![职责表示例：每一行都恰有一个蓝色高亮的 A，其余格子是 R、C、I](https://wepushers.com/_astro/one-accountable.Dy4ljBJq_1xvxQJ.webp)

填完先检查三种常见问题：

- **整行没有 A**：出事时互相等，就是开头那个场景。
- **一行两个 A**：谁都能定，等于谁都不能定。
- **C 列五六个、I 列快把全公司写进去**：判断会被意见淹没，通知也会被忽略。

## 五、表上面加一句定义，表后面加一条备用规则

表只写“谁”，不写“怎么算”，所以表头上面要加一句本项目自己的定义，把字母写成人能执行的行为：“本项目的 A，是两个方案争不出结果时说话的那一个，也是延期时去向上级解释的那一个。”

这句话不多余。同一个词在不同公司、甚至不同语言里意思会反过来：法文版 RACI 里 R 是“对结果负责”、A 是“具体执行”，和英文正好颠倒 [1][3]。有咨询顾问讲过一个例子：一家用了多年 RACI 的公司，让三十个合伙人投票“谁最终拍板”，一半说 A，一半说 R [6]。不先明确词义，表越规范，误会越深。

最后留一条备用规则：表上那个 A 出差、离职、或者装不知道时怎么办。可以预先定下一条规则——先找表上那个人的上一级，两个工作日内必须给答复，并把结论记进周会记录。没有这条，职责表就只是纸。

表的价值不在分工那一刻，而在冲突那一刻：有人能说“这件事的 A 是我，我定了”，也有人能说“这件事的 A 不是你，你去问他”。

## 思维导图

```mermaid
flowchart LR
  A["职责表：谁做、谁定、谁问、谁知道"] --> B["四个角色按介入时机分，不按级别分"]
  B --> C["R 执行：手在活上，可多人"]
  B --> D["A 拍板：承担后果、最终决定，一行一个"]
  B --> E["C 被咨询：事前、双向，意见能改方案"]
  B --> F["I 被告知：事后、单向，只为安排自己的事"]
  D --> G["R 与 A 分开＝保留复核"]
  D --> H["判据：谁能最后一刻推翻，A 就是他"]
  E --> I["边界：带否决权的签字方不是普通 C"]
  F --> J["失败：抄送当知情，等于没人真知道"]
  A --> K["表的做法：行＝WBS 交付物＋关键决定，列＝人名"]
  K --> L["三查：空 A、双 A、C 与 I 泛滥"]
  K --> M["配套：一句字母定义＋A 缺席时向上一级"]
```

## 术语表

- RACI：行是交付物或决定、格是参与方式的职责表，用来回答“谁做、谁定、问谁、告诉谁”。
- A（Accountable，拍板人）：为结果向外承担、在方案冲突时做出最终选择的那一个人，一行只能有一个。
- R（Responsible，执行人）：具体完成某项交付物、对质量负责的人，可以有多人。
- C 与 I：C 是做事之前必须问、意见能改动方案的人（双向）；I 是事后通知、只用来安排自己事情的人（单向）。
- 否决权角色（Agree）：签字同意才能继续的评审方，看着像只给意见的 C，实际能否决，处理方式不同。

## 来源

1. [Perfony：RACI Matrix — History of a Managerial Invention（四个字母的定义，法语版本中 R 与 A 含义颠倒）](https://www.perfony.com/en/raci-matrix-history-of-a-managerial-invention/)
2. [Atlassian：RACI Chart 用法说明（职责分配矩阵，每项任务只能有一个 A，C、I 过多的问题）](https://www.atlassian.com/work-management/project-management/raci-chart)
3. [Cornell University：RACI and RASCI Definitions（一行只能有一个 A，多个 R 要慎用）](https://it.cornell.edu/it-service-management/raci-and-rasci-definitions)
4. [Bain & Company：RAPID Decision Making（Agree 的否决权与 Decide 的单一决策人）](https://www.bain.com/insights/rapid-decision-making/)
5. [Pushers：RACI Matrix 指南（角色按介入时机而非层级区分，每行恰好一个 A 的图示）](https://wepushers.com/frameworks/raci-matrix/)
6. [AAPL：What Companies Get Wrong About Decision Rights（三十位合伙人投票“谁拍板”，一半说 A 一半说 R）](https://www.physicianleaders.org/articles/what-companies-get-wrong-about-decision-rights)

---

原文：https://pangzhengboyin.com/articles/raci-responsibility-table-one-accountable-2711b0e7

> **庞征博引** · 想学的，慢慢都会
>
> 庞征博引是把想学的东西写成连载的 AI 学习工具：每篇 5–10 分钟，边读边问，接下来学什么跟着你走。这篇就是这样写出来的。
>
> 开始你自己的连载 → https://pangzhengboyin.com