raci-matrix

RACI 矩阵技能

此技能可为项目、产品发布或持续性流程生成完整的 RACI（负责、批准、咨询、知会）矩阵。输出可直接分享给团队，以明确职责归属、减少决策瓶颈并消除重复工作。

必需输入

根据已提供的信息开展工作。如果缺少以下任何信息，仍需生成完整输出：为每处空缺填写合理的假设，并标注 (假设，需确认)，然后在末尾列出这些假设。仅当核心主题本身缺失（没有任何内容可供撰写）时，才先提问。

• 项目或流程名称
• 需要梳理的关键活动或决策（用户也可以描述项目，由此技能推导）
• 涉及的团队或角色（列出团队名称；如有帮助，也可列出关键成员）
• 主要目的——明确发布职责归属 / 帮助新团队入职 / 减少瓶颈 / 治理文档
• RACI 变体——标准 RACI、RASCI（增加支持角色）还是 DACI（推动者、批准者、贡献者、知会者）？

输出结构

---

RACI 矩阵：[项目 / 流程名称]

版本： [1.0] 负责人： [项目负责人 / PM] 日期： [日期] 涉及团队： [团队列表]

---

1. 角色定义

查看矩阵前，请先就本项目中每个字母的含义达成一致：

字母	角色	定义	规则
R	负责	执行工作。由一个或多个人实际完成任务。	可以有多个 R，但如果人数较多，请考虑拆分任务
A	批准	对结果负责。批准决策。出现问题时承担责任。	每一行必须且只能有一个 A。 不能有两个，也不能没有。
C	咨询	在开展工作前提供专业知识或意见。双向沟通。	必须主动征询咨询方，而不只是让其随时待命。每行最多列 3 个，否则会造成干扰
I	知会	接收进度或结果通知。单向沟通。	仅知会，不参与审核或批准

黄金规则：

• 每一行必须且只能有一个 A
• 同一人员或团队不应在超过 [X] 行中担任 A——否则会让责任过于分散
• C 的成本较高——咨询某人意味着需要对方回应。请有选择地使用
• 同一任务中，如果某人是 R，就不能同时担任 A，除非此人是决策者（小团队中很常见）

---

2. RACI 矩阵

列 = 团队或角色。行 = 活动或决策。

活动 / 决策	[角色 1]	[角色 2]	[角色 3]	[角色 4]	[角色 5]	备注
[阶段 1：探索]
定义项目范围和目标	A/R	C	I	I	—	PM 牵头；就技术可行性征询工程团队意见
开展用户研究	R	A	C	I	—	UX 研究员负责执行；PM 承担最终责任
批准探索阶段结论	C	A	I	R	—
[阶段 2：设计]
确定解决方案	A	R	C	I	I
设计系统 / UI 设计	C	A/R	I	I	—
设计评审与签字批准	C	R	A	I	—
无障碍审查	I	R	A	C	—
[阶段 3：构建]
技术架构决策	C	C	A/R	I	—
Sprint 规划	A	C	R	I	I
代码审查与合并	I	C	R	A	—
安全审查	I	C	C	A/R	—
[阶段 4：发布]
发布与否决策	A	C	C	R	I	PM 拥有最终决定权
发布到生产环境	C	I	A/R	I	—
客户沟通	A/R	I	I	I	C
发布后监控	C	I	R	A	—
[持续 / 日常运营]
事件响应	I	C	R	A	—
功能优先级排序	A/R	C	C	I	I
干系人报告	A/R	I	I	I	C

---

3. 决策图

对于高风险决策，请记录决策类型、谁拥有决策权，以及如何解决分歧：

决策	决策权（A）	必须咨询（C）	有分歧时的升级路径
范围变更超过 20% 的工作量	[高管发起人 / 项目负责人]	[项目经理、工程负责人]	[指导委员会]
预算超支超过 10%	[财务部门 / 高管]	[项目经理、项目负责人]	[首席财务官 / 董事会]
架构模式变更	[工程负责人]	[技术负责人、安全团队]	[首席技术官]
上线日期变更	[项目经理]	[工程、沟通、客户成功团队]	[项目发起人]
从范围中移除功能	[项目经理]	[产品、用户体验、工程团队]	[首席产品官]

---

4. 常见的 RACI 反模式及修正方法

对照以下问题检查已完成的矩阵：

反模式	症状	修正方法
多个 A	两个团队都认为自己负责某项结果	指定一个 A；另一个改为 C 或 I
没有 A	决策停滞；没人觉得自己有责任	指定职级最高的相关方为 A
人人都是 C	每项决策都要提交委员会讨论	检查每个 C——此人提供的意见是否确实会影响结果？如果不会，将其改为 I
有 R 无 A	工作有人做，但没人负责质量	增加一个 A；通常由 R 的经理担任
有 A 无 R	有责任却无人执行——经理与实际工作脱节	从团队中增加一个 R；或者在适当时合并 A/R
R 太多	责任分散	将任务拆分为子任务，每个子任务明确指定一个 R
矩阵缺少关键团队	他们会受到影响，但未列入 RACI	将其加入；至少在相关行中指定为 I

---

5. 沟通模板

RACI 达成一致后，请使用此模板向所有相关团队传达：

---

主题：[项目名称] — 已就角色与职责达成一致

我们已最终确定 [项目名称] 的 RACI 矩阵。以下是对你的具体含义：

**[角色 1 团队]：**你们对 [X、Y、Z 活动] 负有 最终负责。这意味着你们对这些决策作出最终决定，并在未达成预期结果时承担责任。

**[角色 2 团队]：**你们对 [A、B、C] 负有 执行责任。你们负责执行工作。对于 [D]，你们是 需咨询方——在决策最终确定前，我们需要听取你们的意见。

**[角色 3 团队]：**你们将 知悉 [E、F] 的进展——我们会在 [每周 / 里程碑 / 发布时] 向你们发送更新。无需采取行动，除非你们发现需要升级处理的问题。

请在此处查看完整矩阵：[链接]。如有任何疑虑，请在 [日期] 前提出——此后我们将视为已达成一致。

---

6. RACI 审查频率

触发条件	行动
新团队成员加入	审查与其职责相关的行；根据需要更新 R
阶段变更（例如，从调研阶段转入交付阶段）	审查完整矩阵——部分 R 和 A 会发生变化
出现升级处理或职责归属方面的困惑	使用矩阵进行诊断——找出缺失的 A
长期项目开展满 3 个月	全面审查 RACI——角色会随时间发生变化
团队架构调整或重组	全面重建——职责归属的假设会发生变化

---

质量检查

• 每行都恰好有一个 A
• 没有个人或团队承担超出其实际职权范围的 A
• C 列人数精简——咨询所有人会削弱流程
• 至少有一名来自每个角色列的代表审查并同意该矩阵
• 已制定沟通计划，向所有相关方分享 RACI
• 决策图涵盖项目中风险最高的 5–10 项决策

反模式

• 不要为一项任务指定多个问责人——共同承担问责意味着无人真正负责
• RACI 中的角色不要超过 5–6 个，否则矩阵会变得难以阅读和执行
• 不要纳入范围过于宽泛、导致无法据此采取行动的任务——将任务拆解到决策级别的粒度
• 不要跳过冲突解决流程——没有争议处理流程的 RACI 矩阵，在第一次出现分歧后就会被弃用
• 不要混淆负责人与问责人——清楚记录每个角色的区别

示例触发语句

• “为我们的产品发布制定一份 RACI 矩阵”
• “为我们的新跨职能项目创建一份责任矩阵”
• “这项计划中谁负责什么？帮我制定一份 RACI”
• “梳理工程团队和产品团队的决策权”
• “为涉及[团队]的[迁移／发布／流程]生成一份 RACI”