RACI 矩阵简介
RACI（Responsible, Accountable, Consulted, Informed）是一种 职责分配矩阵（Responsibility Assignment Matrix），通过在项目组织结构与工作分解结构（WBS）的交叉点上标注四种角色，帮助项目团队明确 谁负责、谁批准、谁需要咨询、谁需要了解。
| 符号 | 中文含义 | 英文全称 | 关键点 |
|---|---|---|---|
| R | 负责执行（Responsible） | Doer | 实际完成任务的执行者，可多于一人。 |
| A | 负责人（Accountable） | Owner | 决策者或最终批准者，只能是单一角色；负责对结果负责。 |
| C | 咨询（Consulted） | Advisor | 在任务执行前后提供意见、建议或输入，通常是双向沟通。 |
| I | 知情（Informed） | Notified | 需要被告知进展或结果的利益相关方，是单向沟通，不直接参与执行。 |
核心原则
- 每项任务必须至少有一个 R 和一个 A（但可以有多个 C、I）。
- 同一职责角色在同一任务中只能出现一次（避免冲突或混淆）。
- R 和 A 可以是同一个人（如果执行者同时拥有决策权），但大多数情况下 R ≠ A，以形成清晰的上下链。
1. 为什么要使用 RACI
| 目的 | 价值 | 实际效果 |
|---|---|---|
| 明确职责 | 防止角色重叠或空白 | 任务不再“谁也不负责” |
| 提升沟通效率 | 明确信息流向 | 只给需要的人发送信息，避免信息过载 |
| 加速决策 | 谁拥有批准权 (A) | 关键点快速得到决策，降低拖延 |
| 增强责任感 | 每个角色有明确的价值 | 团队成员对交付结果更负责 |
| 便于审计、审查 | 可追溯每项工作的背后负责人 | 审计/合规时可快速定位责任 |
2. 构建 RACI 矩阵的步骤
列出所有交付物 / 工作包（Work Packages）
- 从 WBS（工作分解结构）或项目里程碑中提取。
- 建议粒度在 “可独立交付、可独立评估” 的层级。
列出所有关键角色/资源
- 项目发起人、赞助人、项目经理、业务分析师、开发/实现团队、测试、运维、客户代表等。
- 每个角色可以对应 实际人，也可以对应 团队/职能。
为每个任务填写角色的 R/A/C/I 标记
- 按“至少 1A + 至少 1R” 的原则填写。
- 注意 不出现多个 A（除非特殊情形），冲突时需要协商重新分配。
审查并调整
- 与项目团队、业务负责人、PMO 进行讨论，确认 每个人对自己职责的认知一致。
- 确保 没有遗漏关键利益相关方（I），尤其是外部客户或合规审查者。
发布并维护
- 将 RACI 矩阵放在项目计划、项目管理工具（如 MS Project、Jira、Confluence）或项目审查文档中。
- 在项目变更、人员调整或需求演进时及时更新。
3. 详细示例
项目：公司门户网站改版（简化版）
| 任务/交付物 | 项目发起人 (Sponsor) | 项目经理 (PM) | 业务分析师 (BA) | UI/UX 设计师 | 开发团队 | 测试团队 | 运维/支持 |
|---|---|---|---|---|---|---|---|
| 1. 需求收集 | A | I | R | C | I | I | I |
| 2. 需求评审 | I | I | A | C | I | I | I |
| 3. 原型设计 | I | C | C | R | I | I | I |
| 4. 前端开发 | I | C | I | C | R | I | I |
| 5. 后端开发 | I | C | I | I | R | I | I |
| 6. 集成测试 | I | I | I | I | C | R / A (取决于组织) | C |
| 7. 上线准备 | I | A | C | C | C | C | R |
| 8. 上线后监控 | I | C | I | I | I | I | R |
说明
- R：实际负责完成该工作包的角色。
- A：对工作包最终结果负责（批准/交付）。在上面例子中，项目经理 对需求评审、上线准备负责（A），而 业务分析师、UI/UX 设计师、开发团队等负责执行（R）。
- C：需提供意见或输入的角色。
- I：需要被告知进展或结果的角色。
4. 常见的 RACI 变体
| 变体 | 适用情境 | 示例 |
|---|---|---|
| RASCI | 在需要 “支持” 或 “提供资源” 的环节加入 S（Support / 协助） | 采购任务中，财务部可能是 S。 |
| PACI | 用 P（Participant）替代或补充 R/C，用于更细粒度的参与者划分 | 大型多层级项目中区分“直接参与”与“间接参与”。 |
| RACI‑D | 加入 D（Decision‑maker）强调 最终决定者，常用于 审批链 | 合规审查、风险评审等。 |
| RACI-C、RACI-4 | 细分为 C1（提供输入）和 C2（审查/批准）等，帮助细化咨询层级 | 大型技术评审需要区分“提供意见”和“批准”。 |
这些变体可以在特定行业（如医药、金融、航空）中使用，帮助解决原始四角色不足的场景。
5. 常见误区与陷阱
| 误区 | 症状 | 解决办法 |
|---|---|---|
| 多个 A | 决策冲突、审批滞后 | 确保每项任务只能有 一个明确的 A，如出现冲突，需要重新审议角色分配。 |
| 只标 A、R，忽略 C、I | 关键利益相关方被遗漏，信息不对称 | 在任务列表中加入所有涉及的 C、I，尤其是外部合作伙伴或客户。 |
| 把 R 当作“唯一负责人” | 实际执行者不止一人，导致工作重叠或空白 | 允许多名 R，但在矩阵中标明每位 R，并在项目计划中分配资源。 |
| 角色标记固定不变 | 项目变化后仍使用旧矩阵 | 将 RACI 视为 动态文档，每次里程碑结束后检查并更新。 |
| 把 RACI 当作完整的沟通计划 | 没有对应的沟通频率、渠道 | 将 RACI 与 沟通计划、风险登记、里程碑计划 结合使用，确保信息流向（I）得到恰当执行。 |
6. RACI 与其他项目文档的关系
| 文档 | 与 RACI 的关联 | 合作方式 |
|---|---|---|
| WBS（工作分解结构） | WBS 产生的 工作包 正是 RACI 矩阵的行/列基础 | 用同一级别的工作包来填充 RACI。 |
| 组织结构图（Org Chart） | 角色的层级和职能在这里定义 | 通过 Org Chart 明确每位角色对应的职责范围。 |
| 项目计划（Schedule） | 各任务的 里程碑、关键路径 必须对应到 RACI 中的 R/A 项 | 在甘特图或网络图中使用 RACI 标记关键节点。 |
| 风险登记册 | 责任人（A）往往是 风险所有者 | 把风险的 RACI 标注进去，明确谁负责监控/缓解。 |
| 质量计划 | 质量审查（C）与批准（A）的角色在 RACI 中明确 | 质量审查的 C 角色与 A 角色来源于 RACI。 |
| 变更控制（Change Control） | 变更的 审批 步骤对应 A，实施者对应 R | 在变更单上直接引用 RACI 矩阵的角色。 |
7. 实战小技巧 & 常见模板
7.1 快速生成 RACI 矩阵的模板（Excel / Google Sheet）
| 交付物 / 任务 | 角色1 | 角色2 | 角色3 | … |
|---|---|---|---|---|
| 项目章程 | A | R | C | … |
| 需求文档 | … | … | … | … |
- 在 Excel 中可使用数据验证（Data Validation）列出
R,A,C,I选项，避免手敲错误。 - 使用 条件格式：
A设为红色填充，R设为蓝色，C设为黄色，I设为淡灰。- 这样一眼能看出关键角色与普通角色的分布。
7.2 常用“角色列表”参考
| 典型项目角色 | 适用场景 |
|---|---|
| 发起人 / 赞助人 (Sponsor) | 决策、资源批准、愿景提供 |
| 项目经理 (PM) | 计划、进度、风险、沟通协调 |
| 业务分析师 (BA) | 需求收集、分析、文档编制 |
| 产品经理 (Product Owner) | 产品愿景、优先级排序、A（在敏捷项目） |
| 开发/实现团队 | R（执行） |
| 测试/质量保证 (QA) | R / C / A（取决于组织） |
| UI/UX 设计师 | R / C |
| 运维/支持 (Ops) | I / R / A（上线后） |
| 客户/最终用户代表 | I / C（提供需求/验收） |
| 合规/法务 (Compliance) | C / A（审批） |
8. 如何在特定项目管理方法中使用 RACI
| 方法 | RACI 适配方式 |
|---|---|
| 瀑布（Waterfall） | 完全兼容，可在需求、设计、实现、测试、部署各阶段使用。 |
| 敏捷（Scrum / Kanban） | 替代传统的“角色划分”，更多使用 Product Owner (A)、Scrum Master (C/R)、Development Team (R)。但仍可在 Sprint Planning、Release Planning 中使用 RACI 细化职责。 |
| PRINCE2 | PRINCE2 本身就通过 Roles & Responsibilities 推荐使用 RACI，四个角色对应：Responsible（Carrying out the work），Accountable（Project Board），Consulted（Stakeholders），Informed（Reporting）。 |
| PMBOK | PMBOK 图文指南中提供了 Responsibility Matrix（即 RACI）的示例，建议在 Stakeholder Management 与 Resource Management 章节使用。 |
9. 小结：在项目管理中的价值
- 明确“谁负责做什么” —— 消除模糊性、降低冲突。
- 构建可视化的沟通链 —— 谁需要知道、谁需要决策、谁必须提供输入。
- 为变更与审计提供清晰的责任链 —— 当需求变更或合规要求时，可快速定位对应的 A/R 角色。
- 提升团队的责任感与透明度 —— 成员知道自己对项目成功的具体贡献。
一句话概括：RACI 把“谁做、谁决定、谁提供建议、谁被通知”这四个关键信息点系统化，帮助项目组织在复杂的工作流中保持 清晰、可追溯、可执行。