1 RACI 基本概念
1.1 RACI 的定义与目的
RACI 是一种用于项目管理与组织协作的职责分配方法。它通过将工作或交付物拆解为可管理的任务，并为每个任务明确四类角色：负责执行的人员或团队、承担最终批准的人员或团队、需要被征询意见的相关方，以及需要被告知进展的相关方。 其目的在于减少“没人负责”“大家都负责导致无人交付”“沟通缺位导致反复”等常见协作问题，让责任边界更清晰、决策更可追踪，从而提升交付质量与效率。
1.2 四个角色的含义
RACI 的四个字母分别代表：
- Responsible（负责/操作者）：完成具体工作或产出交付物的人。
- Accountable（批准/最终责任者）：对结果负最终责任、对“是否通过/是否采用”做出确认的人。
- Consulted（被征询者）：在需要时提供专业意见、参与讨论或评审的对象。
- Informed（被通知者）：需要及时获知进展、结论或变更的人（通常不承担直接决策或产出责任）。
1.3 RACI 与职责边界的关系
在实践中，协作失败往往不是因为团队“不够努力”，而是因为职责边界不清：
- 任务执行时出现“该谁做不明确”，导致等待与推诿；
- 最终放行标准不清，出现多方都认为自己有权决定却又缺乏统一口径；
- 需要输入的角色没有在恰当阶段参与，导致后期返工；
- 相关方错过关键信息，造成重复沟通。
RACI 通过把责任映射到任务层级，把边界从“口头约定”转为“可视化规则”，从而减少争议空间并提升治理节奏。
1.4 RACI Matrix 的典型形式
RACI 通常以 RACI Matrix（职责矩阵）呈现。其常见形态为：
- 行：任务或交付物（如需求评审、测试通过、上线审批等）；
- 列：相关团队或角色（如产品、研发、测试、运维、合规等）；
- 单元格：填写 R / A / C / I 或空白；
- 配套说明：可增加“输入/输出”“完成标准”“触发时点”“例外处理”字段，以便落地执行。
2 角色（Responsible / Accountable / Consulted / Informed）
2.1 Responsible（执行者/操作者）
Responsible 对应“把事情做出来的人”。其关注点通常包括：
- 工作推进与交付物产出；
- 需要时协调同一任务内的同类执行者；
- 在计划与进度约束下，保障任务质量。
通常建议在同一任务上将 Responsible 控制在合理数量范围内，避免出现过度分摊导致责任弱化。
2.2 Accountable（最终责任/批准者）
Accountable 指“对结果拥有最终责任并作出批准”的角色。其关键特征在于：
- 对是否完成、是否通过、是否接受风险或例外承担最终确认责任；
- 需要在关键节点给出明确决策；
- 对可能的返工与质量结果承担源头责任。
在矩阵实践中，很多团队会倾向于让每个任务只有一个 Accountable，以降低“谁说了算”的不确定性；若确有多方共同批准，也需要用规则明确各自负责的子决策。
2.3 Consulted（被征询者）
Consulted 是“在决策或产出形成过程中需要被征求意见”的对象。其作用往往体现在：
被征询并不等同于拥有最终批准权；若把 C 写成事实上的放行权，往往会造成决策延迟或责任混淆。
2.4 Informed（被通知者）
Informed 代表“需要被告知”的相关方。常见情况包括：
- 负责跨团队协同、后续运维支持或资源调度的人；
- 受影响的业务线或客户代表；
- 需要在关键节点了解状态以完成自身工作安排的人员。
Informed 的价值在于减少信息断点，让后续活动能基于最新状态启动，而不是等到问题暴露后再追溯。
2.5 角色数量与常见规则
为了让矩阵可用而不是“贴满标签”的表格，通常会采用若干约束性做法：
- 每个任务尽量明确一个 Accountable：避免多方互相推诿或互相否决。
- Responsible 与 Consulted 分工清晰：能做事的是 R，提供意见的是 C；不负责产出也不负责放行的不要写成 R 或 A。
- Informed 不追求全覆盖：只通知真正需要信息以完成后续工作的对象。
- 同一组织内角色命名保持一致：减少“同一个职责却被写成不同叫法”的混乱。
3 适用场景与价值
3.1 跨部门项目管理
跨部门项目通常存在目标一致但路径不一致的问题。RACI 的价值体现在：把各部门在关键节点的角色写清楚，例如由谁发起、由谁负责产出、由谁最终确认、由谁提供专业输入以及谁需要同步进度，从而降低协作成本与返工率。
3.2 流程运营与流程变更
在运营流程中，“谁批准流程例外”“谁负责异常处理”“谁需要被告知下游影响”等问题很常见。引入 RACI 可以将流程规则固化到任务层级，让变更从提出到执行再到关闭具备一致的责任链条。
3.3 产品开发与交付协作
产品交付涉及研发、测试、运维、运营、合规等多方。RACI 能帮助团队把“交付就绪”的判断与“上线放行”的决策分开管理：研发可能是 Responsible，最终批准可能由指定角色承担；测试与合规则在关键门禁节点以 Consulted 的方式参与。
3.4 需求评审与里程碑验收
需求评审与里程碑验收往往出现“讨论很多但结论不落地”。RACI 可以明确：谁负责整理评审材料、谁对需求是否可实现与是否满足标准承担最终责任、谁需要提出约束条件、谁必须同步验收结果以便后续计划调整。
3.5 会议与沟通机制的“对齐”
RACI 不只是一张表，也可以作为会议设计的依据：关键决策节点由 Accountable 在场或明确替代机制；专业输入由 Consulted 角色提供；会议纪要与结果分发给 Informed。这样能把“谁要开会、谁要发言、谁要看结果”纳入同一治理框架。
4 编制与落地方法
4.1 任务拆解：从工作包到交付物
编制 RACI 的第一步是把范围拆成足够清晰、可验证的任务。实践中常见两种拆解粒度：
- 从工作包出发：将大阶段拆为若干可交付的子任务；
- 从交付物出发：以“输出物”为边界定义任务，如评审报告、测试报告、上线申请等。
目标是让每个任务都有明确的完成标准与可检查的结果，避免“讨论完成算完成”这类不可度量条目。
4.2 逐项分配：建立 RACI 表
当任务列表确定后，为每个任务逐项填写四类角色：
- 先识别 Accountable：找出对结果承担最终责任并能做决定的角色。
- 再确定 Responsible：标注实际执行与产出交付物的角色或团队。
- 接着安排 Consulted：补齐需要提供输入的专业方与评审方。
- 最后定义 Informed：列出需要被及时告知以开展后续工作的相关方。
填写完成后，最好进行一次“逐行核对”：看每个任务是否存在缺失（无 R 或无 A）、冲突（多人充当 A 且无规则）或含糊（写了但无法落到实际行动）。
4.3 避免常见误区：职责“漂移”
职责“漂移”通常表现为：
- 任务发生变化后矩阵不更新，导致角色按旧假设执行；
- Responsible 被动变成“等人给输入”，或变成“什么都做一点”；
- Accountable 只在最后出现，导致前期决策等待。
避免方法是建立更新节奏：在范围、标准或关键约束变化时同步调整矩阵，并记录变更原因。
4.4 与组织架构和权限对齐
矩阵中的角色应与组织的实际权限和流程对齐，例如：
- 谁拥有审批权、谁拥有发布权、谁拥有合规放行资格；
- 谁能够调配资源、谁能协调跨团队优先级；
- 谁是正式的接口负责人。
如果 RACI 写得很漂亮但与组织真实权限脱节，执行时仍会回到“找人拍板”，从而失去治理意义。
4.5 示例：从零到一的 RACI 填表流程
以一个“从零到一”的典型交付链路为例，可按以下节奏填表：
- 定义阶段：明确需求评审、方案评估、风险识别等任务，并先确定各任务的 Accountable。
- 执行阶段：标注开发、测试、文档与准备材料的 Responsible，同时补充被征询的专业角色。
- 门禁阶段：设置验收、放行、上线准备等任务，重点核对是否存在“缺少最终批准”。
- 收尾阶段：将关闭、复盘与交接纳入矩阵，并列出 Informed 的后续责任方。
完成后，通过一次“模拟执行”检验：从某个时间点开始，团队是否知道下一步该联系谁、谁来做决定、谁需要拿到哪些信息。
5 RACI 的常见实践与技巧
5.1 一个任务如何选定 Accountable
选定 Accountable 通常遵循“结果与决策归属一致”的原则：
- 能对结果负责并接受后果的角色；
- 有能力对争议做出裁决并推动达成一致的角色；
- 在流程中负责最终放行或最终验收的角色。
如果团队发现自己没有明确的 Accountable，需要回到权限与流程定义，而不是用“大家都能管”来替代。
5.2 多团队协作下的口径统一
多团队协作中常见问题是：不同团队对“完成”的含义不同。可通过以下方式统一口径：
- 为每个任务补充完成标准（验收条款或检查清单）；
- 在矩阵中明确输入输出关系（谁提供哪些资料、谁收到后如何处理）；
- 对同一类型任务使用一致的命名与粒度，避免出现“需求评审（A 版本）”“需求评审（B 版本）”这种隐性重复。
5.3 冲突处理：当职责重叠或缺失
当职责重叠时，通常有两类冲突：
- 决策权重叠：多方都写为 Accountable 或实质上都能否决；应通过拆分子决策、明确审批链或设定最终仲裁机制解决。
- 执行职责重叠：多个团队都写成 Responsible 但实际各做各的，可能造成浪费；应将产出拆分到更细任务或明确交付物边界。
当出现缺失（例如无 R 或无 C），则说明流程中缺少关键环节的执行/输入方，应回到任务链路把关键动作补齐。
5.4 迭代更新：版本管理与变更记录
RACI 不是一次性产物。建议对矩阵进行版本管理：
- 记录变更点与原因（范围变更、标准更新、人员调整等）；
- 在关键阶段进行小步更新并通知相关方；
- 将矩阵与计划、里程碑联动，避免“表更新了但实际未切换”。
这样能在项目推进中保持一致性，减少反复解释成本。
5.5 “RACI 写了但没用”的原因排查
若矩阵存在但执行效果不佳，常见原因包括：
- 任务粒度过粗：导致一格里包含多个不同动作、角色仍然不清楚；
- 缺少关键节点对应的决策节奏：写了 R/A/C/I，但会议与审批机制没跟上；
- 只在事后追责时使用：团队不把它当作协作规则，而是当作“甩锅表”；
- 缺少维护机制：任务变了但矩阵不变，最终被团队忽略。
排查时建议回到“最近一次卡点”逐行复盘，看是否存在角色缺失、标准不清或决策时点不匹配。
6 评估与改进
6.1 使用指标衡量协作效果
RACI 的效果评估可以从协作过程与结果两端入手，常见指标包括：
- 决策等待时间（卡在审批或确认上的时长）；
- 返工率（因需求理解偏差、标准不一致导致的重复工作比例）；
- 关键节点准时率（门禁前交付物到位情况）；
- 变更引起的沟通次数与澄清工时；
- 交付周期的稳定性（波动是否因责任链清晰而降低）。
这些指标用于判断职责映射是否真正减少摩擦。
6.2 复盘机制：从执行反馈更新 RACI
复盘时可按“问题—触发任务—职责映射—改进动作”结构梳理：
- 哪个环节出现不确定或争议；
- 对应的任务在矩阵中是否清楚标注了 R 与 A；
- 相关方是否在应当介入的时点被征询或被通知；
- 是否需要调整粒度、更新标准或新增任务。
通过把反馈落到矩阵条目，职责体系才能持续变得可执行。
6.3 与其他管理工具的组合
RACI 往往与其他工具协同使用，以形成完整治理闭环：
- 与甘特图/看板联动，让任务与责任可视；
- 与需求管理或变更流程联动，明确每次变更的批准链；
- 与质量门禁或评审清单联动，保证 Consulted 的输入可被追踪；
- 与会议纪要模板联动，确保 Informed 及时拿到结论与行动项。
组合的关键在于把“责任”嵌入日常运作，而不是只停留在文档层面。
6.4 持续改进：让职责可执行、可追踪
持续改进的重点是三个“可”：
- 可执行：角色知道自己在何时做什么；
- 可追踪：任务产出、批准记录、意见反馈能被查到；
- 可复用：同类项目积累经验后，矩阵可作为模板并根据差异调整。
当职责体系成为团队工作语言，协作自然会更稳定。
7 相关扩展与变体（概念对照）
7.1 RASCI / RACIQ 等变体概述
在不同组织中，RACI 常被扩展为包含更多角色维度的变体。例如：
- RASCI：在传统框架外增加额外的角色类型以覆盖“支持/协助”或更细的责任分工；
- RACIQ：在批准与被征询之间或在流程输入层面进一步细化，从而更贴近特定治理要求。
这些变体的核心仍是“责任可视化”，差异在于对协作环节的拆分方式与角色命名颗粒度。
7.2 RACI 与 DACI / DRACI 的区别
不同框架主要差异体现在字母所强调的环节：
- DACI：常见的侧重点是把责任分工与“审批/确认”的结构以另一种顺序呈现，更突出决策与执行之间的关系。
- DRACI：在 RACI 的基础上对“执行角色”或“直接责任”进行强调，通常用于更强调执行落地的场景。
选择哪种框架往往取决于组织的流程习惯、权限结构与协作痛点。
7.3 角色粒度的调整策略
调整策略通常围绕“信息成本”和“清晰度”做平衡：
- 若矩阵过于复杂导致难以使用，应减少角色数量、缩小差异化命名，并把细节转入任务说明或模板；
- 若矩阵过于粗糙无法落地，应增加任务拆解层级或补齐关键阶段（如门禁、放行、复盘）的责任链；
- 对重复性流程可采用模板化矩阵，并允许在项目差异处做局部更新。
目标是让职责映射在日常协作中保持“刚好足够”。
8 文化梗与团队沟通（可选轻量内容）
8.1 “RACI=谁负责谁批准”的口号化用法
在团队内部，RACI 常被简化成口号：“谁负责、谁批准。”这种说法容易快速对齐直觉：执行别只说“我也参与”，批准别含糊不清；但口号应当回到矩阵细节，避免把 C、I 也当成“顺便一提”。
8.2 用 RACI 降低甩锅与口头承诺的风险
当协作冲突出现时，团队往往会依赖“谁当时答应了”。引入 RACI 能把承诺从口头转为可追踪的责任链：
- 该谁负责的写清楚，减少“你不是我组的”；
- 最终批准是谁明确，减少“我以为你会通过”；
- 需要征询和通知的对象被列出，减少“信息没给到”。
因此，RACI 可以被视为一种“把话说在前面”的沟通工具。
8.3 会议纪要如何与 RACI 同步对齐
会议纪要可用“行动项—责任角色—预计时间—关联任务”方式与 RACI 同步：
- 每条行动项引用矩阵中的任务名称；
- 明确 Responsible 的执行方与 Accountable 的确认节点；
- 对 Consulted 记录输入来源与结论摘要；
- 对 Informed 标注发送范围与时间点。
这样即使会后人员流动，也能保持决策与责任的一致性，避免“会后又要重新讲一遍”。