RACI是一种用四个字母标注角色职责的矩阵方法：R（Responsible，执行者）负责动手完成工作，A（Accountable，问责者）对结果负最终责任且每项工作只设一个，C（Consulted，被咨询者）在决策前提供意见，I（Informed，被告知者）在结果确定后获得通知。它回答的是“谁对这件事承担什么角色”，用于澄清跨角色协作中的职责归属。
要点总览（TL;DR）
- RACI用四个字母标注角色职责：R执行、A最终问责、C事前被咨询、I事后被告知。
- 每项工作恰好一个A是核心规则，A与R可以合并也可以分离，取决于任务复杂度与风险。
- 一张RACI矩阵以活动为行、角色为列，每行至少一个R、恰好一个A，留空是正常状态。
- RACI只回答角色职责归属，任务派发与进度跟踪、人员技能与岗位匹配属于其他管理范畴。
- 常见误解包括把C写成A、一行出现两个A、把I当成可有可无，以及机械地合并或分离R与A。
RACI四个字母分别代表什么
RACI的四个字母对应四类职责角色，每个角色承担不同的动作，也有各自的数量约束。理解这套定义的关键，是把“动手做”“最终负责”“事前给意见”“事后被通知”这四件事分开看待。
| 字母 | 英文全称 | 中文译名 | 核心动作 | 数量约束 |
|---|---|---|---|---|
| R | Responsible | 执行者 | 实际动手完成工作、产出交付物 | 一项工作可以有一个或多个R |
| A | Accountable | 问责者 | 对结果负最终责任，拥有确认与拍板权 | 每项工作恰好一个A |
| C | Consulted | 被咨询者 | 在决策或产出定稿前提供专业意见 | 按需设置，可为多个 |
| I | Informed | 被告知者 | 在结果确定后获得通知，了解进展或结论 | 按需设置，可为多个 |
R是真正把工作做出来的人。一项工作可以由多人共同执行，比如两位工程师一起完成一个模块，此时两人都是R。R关注的是“谁动手”，与职位高低没有必然关系。
A是问责者，对这项工作的结果负最终责任。A不一定亲自执行，但要在关键节点确认方向、验收结果，并在出问题时承担说明责任。A的唯一性是RACI最重要的规则：一项工作只设一个A，避免出现“人人有责、无人负责”的局面。当两个人都声称对同一件事负最终责任时，决策会陷入僵持，责任也无法追溯。
R与A可以由同一人担任，也可以分离。在小团队或简单任务中，执行者往往就是对自己工作负最终责任的人，此时R和A合并为一人。在跨部门协作或风险较高的活动中，通常把A交给对结果承担管理责任的角色，把R交给具体执行的角色，形成执行与问责的分离。选择合并还是分离，取决于任务的复杂度和风险程度，没有统一要求。
C是在决策前需要征求意见的人。C的价值在于把专业判断提前引入，减少返工。C的数量需要控制，被咨询者过多会拖慢决策节奏。I是结果确定后需要知情的人，通知方式可以是一次同步、一封邮件或一条工作项更新，重点在于信息触达，不要求对方参与决策。
RACI的边界：它管什么、不管什么
RACI回答的是角色职责归属问题：在一项活动、交付物或决策点上，谁执行、谁最终负责、谁事前被咨询、谁事后被告知。它是一张职责标注表，帮助团队在协作开始前把角色说清楚，在出现分歧时有一个共同的参照。
RACI不涉及单个任务的派发与进度跟踪。把某项工作标为R，说明这个人承担执行角色，至于任务何时开始、拆成几个子任务、当前完成到什么程度，属于任务管理和进度管理的范畴。RACI也不涉及人员技能评估与岗位匹配，它标注的是角色，不判断某个人是否具备胜任该角色的能力，人员如何配置需要结合技能、负载和发展需要另行考虑。
| 维度 | RACI覆盖 | RACI不覆盖 |
|---|---|---|
| 回答的问题 | 谁对这件事承担什么角色 | 任务怎么派、进度怎么跟 |
| 作用对象 | 活动、交付物、决策点的职责归属 | 人员技能、岗位匹配、资源调配 |
| 产出形式 | 角色与活动的交叉标注 | 项目计划、组织架构图 |
| 使用时机 | 协作启动前澄清职责、执行中对照 | 日常任务分派与状态更新 |
与项目计划相比，项目计划描述的是时间、里程碑和任务依赖，RACI描述的是角色关系，两者可以配合使用：计划回答“什么时候做什么”，RACI回答“这件事谁担什么角色”。与组织架构图相比，架构图呈现的是汇报关系和部门归属，属于相对稳定的结构信息；RACI针对具体活动临时标注，随项目或阶段变化。一个人可能在组织架构中属于某个部门，却在某个活动里担任C或I，这正是RACI补充结构信息的地方。
RACI矩阵怎么构成：行列与填写规则
一张RACI矩阵由行和列交叉构成。行通常列出需要澄清职责的活动、交付物或决策点，列通常列出参与协作的角色或岗位。行列交叉的每个格子填写R、A、C、I中的一个字母，也可以留空，表示该角色与这项活动没有直接职责关系。
填写时遵循以下规则：
- 每行至少有一个R，确保每项活动都有明确的执行者。
- 每行恰好有一个A，保证最终责任唯一。
- 每个格子只填一个字母，同一角色对同一活动承担多重角色时，按主要职责标注并在备注中说明。
- 留空是正常状态，不必为了填满而给每个角色都分配字母。
- 列方向可以观察角色负载：某一列字母密集，说明该角色参与的活动过多，需要评估是否负担过重或职责过于集中。
常见的填写顺序分三步。第一步定活动清单，把需要澄清职责的活动、交付物或决策点逐条列出，粒度以“可以独立判断谁负责”为准，过粗会失去澄清作用，过细会增加维护成本。第二步定角色清单，列出参与协作的角色或岗位，按实际参与情况取舍，不把无关角色列入。第三步逐格标注，先确定每行的A，再确定R，然后判断哪些角色需要在事前被咨询、哪些在事后被告知。先定A有助于避免责任分散，因为A一旦确定，R和C的讨论就有了责任归属的参照。
矩阵完成后，建议做一次横向和纵向检查：横向看每行是否满足“至少一个R、恰好一个A”，纵向看是否有角色承担了过多A或R。检查发现的问题往往正是协作中最容易产生分歧的地方。
RACI与相关职责概念的区别
RACI有几个容易混淆的相邻概念，区分它们有助于准确使用这套方法。
| 概念 | 核心关注 | 与RACI的关系 |
|---|---|---|
| RASCI等扩展变体 | 在RACI基础上增加角色，如S（Support，支持者） | 同一思路的扩展，增加了支持类角色，规则框架一致 |
| 任务负责人（单一任务指派） | 某个具体任务由谁承接、何时完成 | 关注任务层面的指派与跟踪，RACI关注角色层面的职责归属 |
| 岗位职责说明书 | 岗位长期承担的职责范围 | 相对稳定、面向岗位；RACI面向具体活动，随项目变化 |
| 组织架构图 | 汇报关系与部门归属 | 呈现结构信息；RACI补充活动层面的角色关系 |
| 决策权模型（如谁拍板） | 决策由谁做出、按什么规则做出 | RACI中的A包含拍板含义，但决策权模型通常更细致地规定决策层级与授权规则 |
RASCI等扩展变体在四个字母之外增加了支持者等角色，适用于需要区分“协助执行”和“主责执行”的场景。选择基础版还是扩展版，取决于团队是否需要更细的角色区分，扩展字母越多，填写和维护成本越高。
任务负责人是任务管理中的概念，指向某个具体任务的承接人，关注任务是否按时完成。RACI中的R与任务负责人有交集，但RACI还包含A、C、I三类角色，回答的是更完整的职责结构。岗位职责说明书描述岗位长期承担的工作范围，相对稳定；RACI针对具体活动标注，随项目阶段调整。组织架构图呈现汇报线和部门归属，是结构性信息；RACI是在结构之上补充活动层面的角色关系。决策权模型侧重“谁有权拍板、按什么层级授权”，RACI中的A虽然包含最终确认的含义，但通常不展开授权层级和决策流程的细节，需要更细的决策规则时应另行定义。
一个具体例子：上线评审中的RACI标注
以下用一个演示场景说明RACI如何落到具体活动上。某团队准备进行一次版本上线评审，参与角色包括产品经理、研发负责人、测试负责人和运维负责人。团队把评审拆成四项活动：评审材料准备、技术风险评估、上线决策、上线通知。
| 活动 | 产品经理 | 研发负责人 | 测试负责人 | 运维负责人 |
|---|---|---|---|---|
| 评审材料准备 | R | C | C | I |
| 技术风险评估 | I | A/R | C | C |
| 上线决策 | A | R | C | C |
| 上线通知 | I | R | I | I |
逐项说明标注理由。评审材料准备由产品经理执行，研发和测试在材料定稿前提供意见，因此标为C，运维只需在材料完成后知晓，标为I。技术风险评估由研发负责人执行并负最终责任，R与A合并为一人，测试和运维在评估过程中提供专业意见，产品经理在结果确定后知情。上线决策由产品经理担任A，对是否上线负最终责任，研发负责人作为R准备决策所需的技术信息，测试和运维在决策前提供意见。上线通知由研发负责人执行，其余角色作为被告知者接收通知。
这个例子中有几个常见误解值得注意。第一，把C写成A。被咨询者提供意见，但不承担最终责任；如果给每个提供意见的人都标A，一项活动就会出现多个A，责任重新变得模糊。第二，一行出现两个A。上线决策如果同时标产品经理和研发负责人为A，一旦双方意见不一致，就缺少明确的最终责任人。第三，把I当成可有可无。I虽然不参与决策，但信息未触达会导致后续协作脱节，比如运维未被告知上线时间而无法安排值守。第四，把R和A机械地合并或分离。本例中技术风险评估合并了R和A，上线决策则分离，判断依据是活动本身的风险和责任结构。
标注完成后，矩阵可以作为协作沟通的共同参照：在评审启动会上逐行确认角色，在执行中遇到分歧时回到矩阵核对，在活动结束后复盘标注是否与实际相符。当团队把这类角色标注与工作项管理结合时，可以把每项活动的A对应到工作项的负责人，把C和I对应到协作人与关注者，让评审流转和通知有明确的承载位置。ONES支持在工作项中设置负责人和协作人，并通过状态流转记录评审过程，适合把RACI标注落到具体的活动记录上，便于执行中对照和事后追溯。
需要说明的是，RACI矩阵的粒度应与团队协作复杂度匹配。活动数量过多会增加维护负担，过少则难以澄清职责。建议从争议最多、跨角色最多的活动开始标注，逐步扩展，让矩阵真正服务于职责澄清，而非成为一份填完就搁置的文档。
常见问题
RACI中的A可以由多人共同担任吗？
不建议。A代表对结果负最终责任，每项工作只设一个A，是这套方法能够澄清职责的前提。如果同一项活动标注两个A，一旦双方判断不一致，就缺少明确的最终责任人，责任追溯也会变得困难。遇到确实需要多方共同确认的情况，可以指定其中一人为A，其他人标为C，在决策前提供意见。
小团队也需要专门做一张RACI矩阵吗？
不一定需要完整矩阵。团队规模小、角色重叠多时，R和A往往由同一人担任，逐格标注的收益有限。更实用的做法是从争议最多、跨角色最多的活动开始，只对这几项活动标注R、A、C、I，确认职责无歧义后再决定是否扩展。矩阵的价值在于澄清职责，不在于表格本身的完整程度。
RACI矩阵做完之后，怎么保证执行中真的按它来？
关键是让矩阵进入日常协作动作，而不是停留在文档里。可以在活动启动时逐行确认角色，把每项活动的A对应到工作项负责人、C和I对应到协作人与关注者，让通知和评审流转有明确的承载位置。执行中出现分歧时回到矩阵核对，活动结束后复盘标注与实际是否相符，逐步修正。
RACI和RASCI应该选哪一个？
取决于团队是否需要区分“主责执行”和“协助执行”。RASCI在四个字母之外增加了S（支持者），适合执行环节参与方较多、需要区分主次贡献的场景。扩展字母越多，填写和维护成本越高，角色边界也越容易模糊。多数跨角色协作场景用基础版RACI即可，确有需要时再增加字母。
一项活动既没有R也没有A，说明什么？
说明这项活动的职责尚未落实。没有R意味着没有人实际动手完成，没有A意味着没有人对结果负最终责任，两种情况都会导致活动推进停滞或出问题后无人说明。填写检查时，横向逐行确认“至少一个R、恰好一个A”，发现空缺就回到活动清单，判断是活动本身不必要，还是角色尚未指定。
