PMP责任分配矩阵RACI把工作事项与参与角色对应起来，分别标明执行、最终责任、咨询和知会。填写时先确定每行究竟交付什么，再分配角色；一张写满字母却找不到决定者的表格，不能解决职责冲突。
信息核对：2026年9月21日。概念参考PMI：角色、责任与资源；下文数字及项目情境为本站原创教学示例，不是官方试题或真实项目统计。
四个字母分别表示什么
R表示承担实际工作的执行角色，A表示对该事项最终结果负责的角色，C表示应当征求意见的角色，I表示需要获得进展或结果信息的角色。中文翻译可能把A称为负责、问责或批准，因此使用前应写明团队采用的含义，不能只凭汉字判断。
| 标记 | 主要问题 | 沟通特点 | 常见误填 |
|---|---|---|---|
| R | 谁实际完成工作 | 需要获得输入并报告进度 | 所有参与者都填R |
| A | 谁对结果承担最终责任 | 需要有对应决策能力 | 因为职级高就填A |
| C | 作决定前要问谁 | 需要双向沟通 | 把知会误写成咨询 |
| I | 哪些人需要知道结果 | 以信息送达为主 | 所有人都邀请开会 |
矩阵中的A不能凭空创造组织授权。某项采购仍需依法定或公司规定的审批流程执行，不能因为表上把项目经理列为A，就认为项目经理有权签署任何合同。最终责任与具体法定签字权需要相互衔接，但未必由同一张表完整表达。
先列角色还是先列工作
先确定要交付的事项及其边界，再邀请相关角色确认参与方式。直接把组织架构横向展开，容易得到“每个部门都参与所有工作”的大表，真正的交接点却仍然含糊。
例如，“完成上线”太宽泛，可能包含功能验收、安全复核、发布操作和运营接收。四件事需要不同技能与权限，应拆成能够单独确认结果的行。若拆到每个点击操作，又会产生维护负担；合理颗粒度是让参与者可以回答由谁推进、结果由谁负责以及意见从哪里取得。
选择列名时可用角色而非个人姓名，另附当前任职人员，减少人员调整造成的重写。供应商、业务代表和运营方也应纳入必要范围。外部角色不能因为不在本公司组织图中而被省略，尤其是负责接口和验收的人员。
一个上线项目怎样填写
下面是本站原创示例，不代表所有公司的授权方式。假设业务代表负责验收结论，安全负责人负责安全结论，发布负责人负责技术发布的结果。
| 工作事项 | 业务代表 | 开发团队 | 安全负责人 | 发布负责人 |
|---|---|---|---|---|
| 确认业务验收结论 | A | R | C | I |
| 完成安全复核 | C | R | A | I |
| 执行已批准的发布 | I | C | C | A/R |
同一角色可以同时承担执行和最终责任，但团队应核对工作负荷与必要的独立复核。若存在职责分离要求，就不能因为表格允许A/R组合而取消复核。表中没有列出的测试或运营角色，真实项目中应按情况补入，不应为了保持表格简短而遗漏。
一项工作能不能有多个R或多个A
可以有多个执行角色，但必须说明各自负责的部分和交付接口。两个团队共同实现接口时，可以共同标R，再用说明列区分数据提供、接口调用和联调，或拆成多行。只写“双R”而没有边界，容易出现双方等待对方行动。
实践中通常为一项清晰工作明确一个最终责任角色，避免结果无人拍板。这是常用的清晰性原则，不意味着现实治理永远只有一个审批步骤。若确需多方批准，应拆分各自负责的结论，或在治理说明中记录联合决定程序，而不是留下两个含义不清的A。
若某行没有R，先检查工作是否真的必要；若必要，就要补齐执行能力。若有R却没有A，团队可能做完工作却得不到结论。反过来，一个管理者在几十行都承担A，也可能说明决策过度集中，需要讨论授权，而非要求其参加更多会议。
咨询和知会怎么区分
判断标准是“信息是否需要在决定前进入讨论”。安全专家若必须评价方案，通常应在该事项中承担C或对应责任，事后发邮件不能代替咨询。只需要知道发布结果的用户支持团队，则可能主要承担I，并根据影响提前获得必要通知。
咨询对象过多会拖慢决定，但解决办法不是擅自删掉关键利益相关方。应确认咨询范围、反馈时间和缺席处理办法。可以把意见归并后讨论，也可以指定代表；需要保留可追溯记录，证明重要意见确实进入了权衡。
矩阵与沟通方法需要配合：RACI回答找谁，沟通计划回答何时、用什么方式以及传递什么内容。对于需要多方协作的工作，还可用PMP沟通渠道计算公式理解潜在联系数量，但不能用渠道数决定所有人都必须互发消息。
职责冲突发生后怎样更新
先对照已约定的工作边界与实际授权，听取当事人的理解，再确定冲突来自遗漏、重叠还是人员能力不足。不要只把某个人的字母改掉就宣布问题解决。涉及职责变化时，需要相关负责人确认资源、权限和交接条件。
更新后应同步通知受影响人员，并在下一次实际交付中观察是否仍出现等待。矩阵不是只在项目启动时签字的静态附件。范围调整、组织重组、供应商更换及关键人员离职，都可能触发检查。资源层面的全貌可参阅PMBOK第八版资源绩效域。
敏捷团队还需要这张表吗
可以按需使用，尤其是跨部门、外部采购或监管接口较多时，但不应把矩阵变成管理者每天给成员分派微任务的工具。团队内部可以自主管理实现方式，外部责任和必要审批仍需清楚。目标是减少等待和返工，不是用字母取代协作。
怎样检查矩阵确实被理解
选一项即将发生的交接，请执行者、最终责任人和被咨询者分别复述自己的动作。若执行者认为只需提交文件，而最终责任人认为还应组织验证，就说明工作定义仍需澄清。现场用同一个交付示例核对，比各自签字确认一整张表更容易发现歧义。
还可以从列方向检查个人负担，从行方向检查责任闭环。一个角色承担过多咨询任务可能成为等待点，一项工作没有任何接收者则可能在交付后无人使用。矩阵应帮助看见这些问题，而不是仅满足文档归档要求。
常见问题
RACI是不是组织结构图？
不是。组织图表达汇报或隶属关系，RACI表达某项工作中不同角色的参与责任，同一个人可能在不同事项中承担不同角色。
RACI中的A一定是项目经理吗？
不一定。应由具有相应结果责任和决策能力的角色承担，并与组织授权保持一致，不能按职位名称机械填写。
一个人可以同时是R和A吗？
可以，但需要核对能力、工作负荷和职责分离要求。涉及独立审核的事项，不能用组合标记取消审核。
RACI填写完成后还要更新吗？
需要在工作边界、角色或授权发生变化时检查并更新，同时告知受影响人员，避免继续沿用过期职责。
来源与适用边界
PMI官网知识库中的署名论文属于实践参考，不等同于当前考试通知。本站为第三方知识整理站，本文不替代PMP考试内容大纲，不承诺某一工具的固定考试题量；考务及认证要求以官方最新通知为准。