项目问题责任不清，常见表现是问题提出后停在群里没人受理，处理人反复更换，跨部门协调人承担了结果责任，升级时又找不到有权拍板的人。用RACI矩阵可以把提出人、处理人、责任人和升级审批人固定到问题的不同动作上：先界定问题范围和状态流转，再明确四类角色对应的RACI字母，按问题类型搭建责任矩阵，最后把矩阵写进问题记录字段和升级规则。ONES可在问题工作项与流程配置中承载这些字段和流转规则，本文按这一落地路径展开。
要点总览（TL;DR）
- 先划定矩阵适用范围：项目推进障碍类问题纳入本矩阵，产品Bug归缺陷管理，服务中断归服务事件与问题管理，避免同一问题在两套流程中重复指派角色。
- 四类角色对应关系：处理人对应R（执行者），责任人对应A（问责者），提出人按参与深度设为I或C，升级审批人按决策权限设为A或C。
- 每类问题有且只有一个A，每个处理动作有明确R；跨部门问题的A落在业务负责人身上，协调人通常标为R或C。
- 矩阵要落到问题记录的提出人、处理人、责任人、升级审批人四个必填字段，并按问题等级设定升级触发条件、响应时限和升级后动作。
- 项目经理或PMO负责矩阵初稿与维护，各问题类型责任人确认本行配置，矩阵变更经评审后发布，并用抽查近期问题记录的方式验证执行情况。
先界定问题范围与状态流转
RACI矩阵只对纳入管理的问题有效，第一步要划定适用对象。本文覆盖项目推进障碍类问题，例如进度阻塞、资源冲突、需求变更、跨团队接口未决、关键决策待定。产品Bug归入缺陷管理流程，服务中断归入服务事件与问题管理流程，它们有各自的受理和处置规则，不放进这张矩阵，避免同一问题在两套流程中重复指派角色。
范围确定后，列出问题从提出到关闭的状态节点。一个可操作的状态序列通常包括：提出、受理、处理中、待验证、已关闭，必要时增加升级中、挂起两个分支状态。状态节点决定角色在什么位置介入：提出节点需要提出人填写问题描述和期望完成时间；受理节点由处理人确认问题成立并给出初步方案；处理中由处理人推进具体动作；待验证由提出人或验证人确认结果；关闭由责任人确认并归档。升级中状态则触发升级审批人介入，重新确认责任人或调整处理人。
状态流转清单建议写成表格，每个状态标注进入条件、责任角色和退出条件。完成标志是：团队能对“一个问题现在处于哪个状态、下一步由谁动作”给出一致回答。这一步的输出是问题范围界定说明和状态流转节点清单，它们是后续角色分配的锚点。
四类角色在RACI中的对应关系
责任不清往往源于同一个称呼在不同团队含义不同。把四类角色映射到RACI字母，先统一语言，再谈分工。
| 业务角色 | RACI字母 | 核心职责 | 关键约束 |
|---|---|---|---|
| 处理人 | R（执行者） | 执行具体推进动作，更新处理进展，提交处理结果 | 每个处理动作有明确R，不能空缺；可有多个R分工，但需按动作拆分 |
| 责任人 | A（问责者） | 对问题最终结果负责，确认方案、验收结果、决定关闭 | 每类问题有且只有一个A，避免多人对结果负责导致责任稀释 |
| 提出人 | I或C | 描述问题、提供背景、确认结果 | 参与方案讨论时为C，仅需知会进展和结果时为I |
| 升级审批人 | A或C | 在升级触发时裁决资源、优先级或责任归属 | 按决策权限设定；与责任人同一人时须明确其审批动作独立于处理动作 |
提出人的字母选择取决于参与深度。提出人只在问题解决后收到通知，标为I；需要参与方案评审、补充需求细节或确认验收标准的，标为C。把提出人一律标成C会造成不必要的会议和确认环节，一律标成I则可能在方案偏离原始诉求时缺少反馈。
升级审批人的设置要区分两种情形。当审批人拥有跨部门资源调配权，能在升级时直接改变责任归属，可设为A，但此时原责任人应转为R或C，保证每类问题只有一个A。当审批人只对升级事项给出意见、最终仍由原责任人决策，设为C更合适。无论哪种情形，处理人不应同时担任同一问题的升级审批人，避免自己处理、自己审批。
按问题类型搭建责任矩阵
矩阵的行是问题类型或项目阶段，列是四类角色，单元格填R、A、C、I。行按问题类型划分更适合跨部门项目，因为不同类型问题的决策权归属不同；行按阶段划分适合流程稳定、角色随阶段轮换的项目。两种方式可以叠加，先用类型分行，再在类型内标注阶段差异。
填写时逐行检查三条规则：每行有且只有一个A；每个处理动作有对应R；C和I的数量控制在必要范围，避免整行都是C导致无人真正推进。跨部门问题的A应落在业务负责人身上，协调人通常标为R或C，协调人可以推动沟通和排期，结果责任仍由业务负责人承担。
| 问题类型 | 提出人 | 处理人（R） | 责任人（A） | 升级审批人 |
|---|---|---|---|---|
| 进度阻塞 | 受阻任务负责人（I） | 项目经理（R） | 项目发起人（A） | 项目发起人（A，升级时裁决优先级） |
| 资源冲突 | 需求方负责人（C） | 资源经理（R） | 部门负责人（A） | 分管领导（C，提供调配意见） |
| 需求变更 | 业务方（C） | 产品负责人（R） | 业务负责人（A） | 变更委员会（A，超出阈值时接管） |
示例中需求变更一行出现了两个A，需要按变更规模拆分：阈值内的变更由业务负责人作为A，超出阈值的变更由变更委员会作为A，业务负责人转为C。这样每一行在给定条件下只有一个A。矩阵完成后应作为项目启动材料的一部分发布，而不是留在PMO的文档库里。
把矩阵落到问题记录与升级规则
矩阵停留在文档层面，责任仍会回到口头确认。落地方式是在问题记录中设置四个角色字段：提出人、处理人、责任人、升级审批人。字段设为必填，创建问题时即完成指派，受理环节由处理人确认字段无误，状态进入处理中后变更角色需留下变更记录。
升级规则按问题等级设定触发条件和时限。等级划分可参考影响范围和紧迫程度，例如影响关键路径且当日未受理的问题、跨两个以上部门且三日内未达成方案的问题、处理超期两次的问题。每条规则写明触发条件、升级对象、响应时限和升级后的动作：审批人可变更责任人、调整处理人或调整优先级，变更结果回写到问题记录字段。
| 问题等级 | 升级触发条件 | 升级对象 | 响应时限 | 升级后动作 |
|---|---|---|---|---|
| 高 | 影响关键路径，受理超4小时 | 项目发起人 | 1个工作日 | 确认责任人，必要时调整处理人 |
| 中 | 跨部门问题3日未达成方案 | 部门负责人 | 2个工作日 | 裁决资源或方案分歧 |
| 低 | 处理超期两次 | 项目经理 | 3个工作日 | 重新排期或关闭问题 |
状态变更时的字段更新责任也要写清：处理人负责更新处理进展和预计完成时间；责任人在待验证转关闭时确认结果；升级审批人在升级动作完成后更新责任人或处理人字段。ONES的问题工作项可配置上述角色字段、状态流转和按条件触发的通知，使矩阵中的角色在每条问题记录上可见、可追溯，减少在群聊中反复确认归属。
角色分工与交付物确认
矩阵需要有人维护，否则问题类型变化后配置会逐渐失效。项目经理或PMO负责矩阵初稿编制和日常维护，包括新增问题类型、调整角色配置、更新升级阈值。各问题类型的责任人确认本行配置，确认内容包括A是否唯一、R是否覆盖全部处理动作、升级审批人是否具备相应决策权。
提出人和处理人在问题记录中承担操作责任：提出人填写问题描述、影响范围和期望结果；处理人受理问题、更新进展、提交处理结果。矩阵变更采用评审后发布的方式，由PMO发起变更说明，相关责任人确认，发布后在项目例会上同步一次，并更新问题记录中的字段选项和升级规则配置。
| 角色 | 矩阵相关职责 | 交付物 |
|---|---|---|
| 项目经理/PMO | 编制初稿、维护矩阵、组织变更评审 | 责任矩阵、变更记录 |
| 问题类型责任人 | 确认本行A、R、C、I配置 | 确认意见 |
| 提出人 | 按字段要求提交问题 | 完整的问题记录 |
| 处理人 | 受理、更新进展、提交结果 | 处理记录与结果说明 |
完成检查：矩阵是否真正消除责任不清
矩阵发布后，用以下清单逐项核对，判断它是否具备可执行性。
- 每类问题有且只有一个A，跨部门问题的A落在业务负责人而非协调人。
- 每个处理动作有明确R，不存在只有A没有R的空缺行。
- 升级审批人与责任人的权限边界清晰，处理人不兼任同一问题的升级审批人。
- 问题记录中的提出人、处理人、责任人、升级审批人字段为必填，且与矩阵配置一致。
- 升级触发条件和时限已写入流程规则，触发后有明确响应动作。
- 抽查近期10条问题记录，四个角色字段填写完整，状态流转与角色动作对应。
- 矩阵变更经过评审并发布，问题记录字段选项同步更新。
抽查发现字段空缺或角色与矩阵不符时，回到对应问题类型修正配置，而不是在单条记录上临时指派。完成标志是：任取一条在办问题，团队成员能依据记录字段说清谁提出、谁处理、谁对结果负责、升级找谁，且四个答案与矩阵一致。
常见问题
提出人到底该标I还是C，判断标准是什么？
看提出人是否参与方案形成过程。只在问题解决后收到结果通知的，标为I；需要参与方案评审、补充需求细节或确认验收标准的，标为C。
实际操作中可按问题类型统一约定，例如进度阻塞类问题的提出人通常标I，需求变更类问题的提出人通常标C。统一约定后写入矩阵，避免每条问题临时判断造成不一致。
升级审批人和责任人可以是同一个人吗？
可以，但需要把两种动作分开写清。当审批人拥有跨部门资源调配权、能在升级时直接改变责任归属，可同时担任A，此时原责任人应转为R或C，保证每类问题只有一个A。
如果审批人只对升级事项给出意见、最终仍由原责任人决策，设为C更合适。无论哪种情形，处理人不应同时担任同一问题的升级审批人，避免自己处理、自己审批。
问题类型很多，矩阵要一行一行全部列出来吗？
不必穷举所有细分场景。先按决策权归属归类，把A相同的场景合并成一行，例如各类进度阻塞可共用一行，各类资源冲突可共用一行。
当某类问题频繁出现且现有行的角色配置不适用时，再拆出新行。矩阵行数控制在团队能记住和维护的范围内，比追求覆盖全部场景更实用。
矩阵发布后，问题记录里的角色字段还能改吗？
可以改，但要留下变更记录。建议约定：受理环节由处理人确认字段无误；状态进入处理中后变更责任人、处理人或升级审批人，需填写变更原因并通知相关角色。
如果某类问题反复出现角色变更，说明矩阵中该行的配置与实际决策权不符，应回到矩阵层面修正，而不是在单条记录上临时指派。
团队规模小、问题类型单一，还需要完整的RACI矩阵吗？
可以简化，但两条底线建议保留：每类问题有且只有一个A；每个处理动作有明确R。小团队可以把矩阵压缩成一张角色对照表，写清谁提出、谁处理、谁对结果负责、升级找谁。
简化的是矩阵行数和C、I的细分程度，角色字段和升级触发条件仍建议写入问题记录，否则问题增多后责任归属会重新变得模糊。
