RACI矩阵是一种把任务或交付物与参与角色对应起来的职责分工表：R负责动手完成，A对结果负最终责任且每项任务只设一个，C在决策或产出前提供意见，I在结果或进展确定后接收通知。本文说明四个字母的准确含义、矩阵的适用范围与边界、行列结构和填写规则，并用一个演示示例指出常见误用。
要点总览（TL;DR）
- RACI矩阵把任务或交付物与参与角色对应起来：R负责动手完成，A对结果负最终责任，C在决策前提供意见，I在结果确定后接收通知。
- A的唯一性是矩阵的核心规则：每项任务有且仅有一个最终负责人，否则分歧出现时无人拍板；R可以多人分担，也可以与A由同一人担任。
- 矩阵的行是任务或交付物，列是角色或岗位，交叉格填R、A、C、I或留空；每行至少一个R、有且仅有一个A，空格表示该角色与任务无职责关系。
- RACI管的是角色之间的职责关系，不管人员能力配置、单任务负责人的分配流程，也不替代进度计划与考核制度。
- 与任务分配表相比，RACI多出A、C、I三个维度；与RAPID、DACI相比，它覆盖执行、决策与沟通，但对决策内部细分较少。
RACI矩阵的定义与四个字母含义
RACI矩阵的中文常译为“责任分配矩阵”或“职责矩阵”，英文全称为Responsible、Accountable、Consulted、Informed。它以二维表格的形式，把一组任务或交付物放在行上，把参与其中的角色或岗位放在列上，在交叉格中标注该角色对这项工作的参与方式。矩阵回答的核心问题是：这件事谁来做、谁最终拍板、决策前该听谁的意见、结果出来后该通知谁。
四个字母对应四种不同的职责动作，差异集中在“是否动手”和“是否承担最终责任”两个维度上。
| 字母 | 英文全称 | 中文含义 | 核心动作 | 数量规则 |
|---|---|---|---|---|
| R | Responsible | 执行者 | 实际动手完成任务、产出交付物 | 每项任务至少一个，可以多人分担 |
| A | Accountable | 最终负责人 | 对结果负最终责任，做最终决策与验收 | 每项任务有且仅有一个 |
| C | Consulted | 被咨询者 | 在决策或产出定稿前提供专业意见，双向沟通 | 按需要设置，宜少不宜多 |
| I | Informed | 被告知者 | 在结果或关键进展确定后接收通知，单向传递 | 按需要设置 |
A的唯一性规则是RACI最需要强调的一条。一项任务如果出现两个A，遇到分歧时就没人能最终拍板，责任在两人之间来回转移；反过来，一项任务完全没有A，则意味着结果无人兜底，出问题时容易演变成集体负责、实际无人负责。R与A可以由同一人担任，尤其在任务规模较小、执行与决策不必分离的场景下；但当任务涉及跨部门资源或较高风险时，把R和A分开，让执行者专注交付、负责人专注判断，通常更清晰。
C与I的区别在于介入时点和沟通方向。C在结论形成之前介入，其意见可能改变方案；I在结论形成之后接收信息，主要作用是知情而非影响决策。把本该在事前征求意见的人放到I，容易在方案定稿后遭遇返工；把只需知情的人放进C，则会拉长决策周期。
RACI矩阵的边界：它管什么、不管什么
RACI矩阵覆盖的是角色之间的职责关系：针对一项具体工作，哪些角色以何种方式参与。它是一张关系视图，不描述人的能力，也不规定工作按什么顺序推进。理解这条边界，能避免把矩阵当成万能表来用。
RACI不负责人员能力配置。矩阵的列写的是角色或岗位，比如“产品经理”“测试负责人”“法务”，而不是某个具体员工的能力标签。谁适合担任这个角色、当前是否具备相应技能、工作量是否饱和，属于资源与技能管理的范畴。矩阵确定“这个角色要参与”，资源管理解决“由谁来做、做不做得过来”。
RACI不替代单任务负责人的分配流程。矩阵标出某行有一个A，但A由谁担任、通过什么流程确认、失职如何追究，属于任务分配与责任管理的工作。矩阵提供的是分配时的参照依据，分配动作本身发生在矩阵之外。
RACI也不替代进度计划与考核制度。它不回答任务何时开始、依赖哪项前置工作、工期多长，这些由项目计划与排期承担；它同样不设定绩效指标和评分标准，把矩阵中的角色直接换算成绩效权重，是对这张表的误用。矩阵的价值在于事前把职责谈清楚，减少执行中的推诿和重复沟通，这一作用需要通过团队共识和后续跟踪来兑现。
RACI矩阵怎么构成：行列设计与填写规则
一张可用的RACI矩阵由三个要素构成：行、列和交叉格。行列出需要明确职责的任务或交付物，粒度以“能独立判断完成与否”为宜，过粗会让职责模糊，过细则维护成本高。列列出参与这项工作的角色或岗位，通常来自项目涉及的关键职能，而非组织里的全部岗位。交叉格填写R、A、C、I四个字母之一，或留空。
填写时遵循以下规则：
- 每行至少有一个R，否则这项任务没有实际执行人。
- 每行有且仅有一个A，确保最终责任唯一。
- 同一角色在一行中原则上只填一个字母；若确实既执行又拍板，可标为“R/A”，但需在表下注明。
- 控制同一人承担的角色数量。一个人在同一行同时是R、A、C、I，说明这项任务的职责设计没有起到分工作用。
- 空格表示该角色与这项任务没有职责关系，是合法且常见的信息，不必为了填满而强行标注。
- C的数量应明显少于I。需要事前征求意见的角色通常有限，知情范围可以更广。
矩阵填完后建议做一次横向检查：逐行确认A是否唯一、R是否存在；再纵向检查每个角色是否承担了过多A，导致决策集中在少数人身上。这张表在项目启动或制度评审前完成初稿，在执行中随任务调整更新，比一次性填完就归档更有实际作用。
RACI与相关职责工具的区别
RACI容易与几类相邻工具混淆，区别主要在回答的问题不同。
| 工具 | 主要回答的问题 | 与RACI的差异方向 |
|---|---|---|
| 简单任务分配表 | 这项任务派给谁、截止到什么时候 | 只记录执行人与时间，不区分最终责任、咨询与知会 |
| RAPID | 一项决策由谁提议、谁同意、谁输入、谁决定、谁执行 | 聚焦决策环节的五种角色，颗粒度落在“做决定”上 |
| DACI | 决策的驱动者、批准者、贡献者、知情者分别是谁 | 同样面向决策，强调推动决策前进的驱动者角色 |
| 组织架构图 | 部门与岗位的汇报关系和管理层级 | 描述静态组织关系，不针对具体任务分配职责 |
| 岗位说明书 | 一个岗位的职责范围、任职要求 | 面向岗位的长期职责，不落到单项任务的参与方式 |
与任务分配表相比，RACI多出了A、C、I三个维度，能表达“谁拍板、谁提意见、谁只需要知道”，适合职责交叉较多的跨职能工作。RAPID和DACI把注意力集中在决策本身，适合需要明确决策路径的场合；RACI覆盖范围更宽，既管执行也管决策与沟通，但对决策内部的细分不如前两者。组织架构图和岗位说明书回答的是“组织如何设置”，RACI回答的是“这件事上各角色如何参与”，前者相对稳定，后者随任务变化。实际工作中，这几类工具可以并存：架构图定岗位，岗位说明书定长期职责，RACI定具体任务的参与方式。
一个具体例子与常见误解
以下为演示情景，用于说明填写过程，不代表任何真实项目。假设某团队要完成一次版本发布，涉及产品、研发、测试、运维和市场五个角色。可以先列出关键任务，再逐行标注职责。
| 任务 | 产品经理 | 研发负责人 | 测试负责人 | 运维 | 市场 |
|---|---|---|---|---|---|
| 确定发布范围与优先级 | A/R | C | C | I | I |
| 完成功能开发与自测 | C | A/R | I | ||
| 执行回归测试并出具报告 | I | C | A/R | I | |
| 制定上线与回滚方案 | C | C | C | A/R | I |
| 对外发布说明与公告 | C | I | I | C | A/R |
这张表里，每行只有一个A，R与A在多数任务中由同一角色承担，符合小团队的实际。市场角色只在发布范围阶段被知会、在公告环节负责，其余任务留空，说明其与开发测试环节没有直接职责关系。若换到制度评审场景，行可以改为“起草制度草案”“合规审查”“管理层审批”“全员宣贯”，列改为起草部门、法务、管理层和人力资源，填写逻辑相同。
实际使用中，三类误解最常见。第一类是允许一行出现多个A，理由是“两个部门共同负责”。后果是分歧出现时无人拍板，决策被反复上推，任务在部门之间停留。第二类是把C和I混用，把只需知情的人标成C，导致每次方案讨论都要拉上大量人员，决策周期被拉长；或者把本该事前征求意见的人标成I，方案定稿后才收到反馈，造成返工。第三类是把RACI当成考核表，按字母给角色打权重、算绩效。矩阵记录的是职责关系，不是贡献大小，用它做考核会诱导成员争抢A、回避R，反而破坏分工。
矩阵填好之后，职责关系还需要落到日常协作中才能持续生效。任务的状态、当前执行人、待确认事项和通知对象，如果只停留在表格里，更新滞后就会让矩阵失效。在ONES这类研发协作平台中，可以把任务与对应角色关联起来，让执行进度、评审节点和知会记录随工作项流转，矩阵作为职责约定的依据，协作工具承载具体的状态与交接，两者配合能减少“表上写了、实际没人跟”的情况。团队规模、项目复杂度和现有工具链不同，落地方式可以相应调整，不必强求统一形式。
常见问题
RACI矩阵里，R和A可以由同一个人担任吗？
可以。R与A由同一人担任在任务规模较小、执行与决策不必分离的场景下很常见，示例中的小团队版本发布就采用了“A/R”的标注方式。当任务涉及跨部门资源、较高风险或需要独立验收时，把R和A分开通常更清晰：执行者专注交付，负责人专注判断与验收。无论是否合并，每行有且仅有一个A这条规则不变。
矩阵填完后，任务调整了怎么办？
RACI矩阵是随任务变化的职责约定，任务范围、参与角色或决策路径发生调整时，矩阵应同步更新。建议在项目启动或制度评审前完成初稿，在执行中按变更节点复核，重点检查新增任务是否补了R和A、角色调整后A是否仍然唯一。矩阵长期不更新，表上的职责与实际参与就会脱节，成员会逐渐回到口头确认的方式。
跨部门任务里，A应该放在哪个部门？
A应放在对这项任务结果承担最终责任、并且有能力做最终决策的角色上，与部门归属没有固定对应关系。判断依据是：出现分歧时由谁拍板、交付验收由谁确认。如果两个部门都主张最终责任，说明任务本身可能需要拆分成两项分别设A，或者需要在上层明确一个裁决角色。把A简单按部门级别高低来放，容易造成责任与决策权不匹配。
C和I的边界在实际沟通中怎么把握？
看介入时点和意见是否可能改变结论。C在方案定稿前介入，其意见可能影响方案内容，沟通是双向的；I在结论或关键进展确定后接收信息，主要作用是知情。判断一个人该放C还是I，可以问：如果现在不征求他的意见，方案定稿后是否可能因此返工？会返工则放C，只需知道则放I。C的数量应明显少于I，否则决策周期会被拉长。
小团队也需要正式填一张RACI矩阵吗？
不一定需要完整表格，但职责约定本身仍然有价值。小团队人数少、沟通频繁，可以用简化形式，比如在任务说明中写清执行人、拍板人和需要知会的对象。当任务开始跨职能、参与角色增多，或者反复出现推诿和重复沟通时，再升级为正式的矩阵表更合适。形式可以随团队规模调整，每项任务有明确执行人和唯一拍板人这条原则不因团队大小而改变。
