项目问题拖到中途才发现“没人真正负责”，常见原因是登记时只写了问题描述，没有把提出、处理、负责和升级审批的角色分开。用RACI矩阵可以把这四类角色逐行固定下来：谁提出、谁执行处理、谁对结果负责、谁批准升级，在问题流转前就写清楚。本文给出角色定义、矩阵模板、流转节点和落地检查方法，范围限于项目推进中的障碍类问题。
要点总览（TL;DR）
- 四类角色按RACI落位：提出人通常为I（需参与判断时为C），处理人为R，责任人为A，升级审批人按组织授权为A或C，并在矩阵中写明上报对象。
- 矩阵每行只设一个A且必须是具体个人；R可多人但标出主处理人；C和I控制到真正需要征询和告知的人，避免矩阵退化成通讯录。
- 问题流转设登记、接单、方案确认、升级、关闭五个节点，四类角色字段是登记必填项，缺少任一字段不允许进入处理中状态。
- 升级审批人只在超时未解决、跨部门协调受阻、影响关键里程碑等条件触发时介入，输出继续处理、调整方案、追加资源或关闭上报的明确结论。
- 落地靠表单字段与状态规则约束，每月抽样比对实际流转与矩阵的一致性，把偏离原因回写到矩阵或表单规则中。
先定四类角色：提出人、处理人、责任人、升级审批人怎么分
RACI矩阵用四个字母描述参与方式：R（Responsible）是实际执行处理的人，A（Accountable）是对结果负最终责任的人，C（Consulted）是需要征询意见的人，I（Informed）是需要被告知进展的人。落到项目问题场景，四类角色分别回答四个不同的问题，判断标准也应分开写。
| 角色 | 对应字母 | 回答的问题 | 判定标准 | 典型误用 |
|---|---|---|---|---|
| 提出人 | 通常为I，需要参与判断时为C | 这个问题由谁发现并登记？ | 最先发现或受影响、能描述现象和影响范围的人 | 把提出人默认当成处理人，登记完就等对方解决 |
| 处理人 | R | 谁动手分析原因、执行处理动作？ | 具备处理该问题所需技能和权限、能产出处理记录的人 | 设多个R却不指定主处理人，出现互相等待 |
| 责任人 | A | 谁对问题最终解决结果负责？ | 能调动所需资源、能确认方案并决定关闭的人 | 把责任人写成“部门”或“项目组”，责任落到集体等于无人负责 |
| 升级审批人 | A或C，按组织授权确定 | 处理受阻时谁批准升级、谁裁定资源或范围调整？ | 在责任人权责之上、能跨部门协调或调整计划的人 | 与责任人设为同一人，升级变成自己批准自己 |
提出人与处理人的边界在于动作性质：提出人负责把问题说清楚，包括现象、发生时间、影响的对象和范围；处理人负责原因分析和处理动作。提出人可以补充信息、验证结果，处理动作的执行责任归处理人。若提出人恰好具备处理能力，可以在矩阵中注明兼任，但仍需在登记时分别记录两个字段，便于统计和追溯。
责任人与升级审批人的区别在决策层级。责任人对“这个问题怎么解决、何时可以关闭”负责；升级审批人只在处理受阻、超出责任人权限或影响关键里程碑时介入，对“是否升级、升级后采用哪种方案、资源从哪里来”作出裁定。两者合一，会让升级机制失去意义；两者层级差距过大，又会导致升级审批人不了解上下文。实践中可让升级审批人对应责任人的上一级管理者或跨部门协调角色。
同一人兼任多角色需要设限制条件。首先避免同一人同时担任R与A，否则执行与验收由同一人完成，处理质量缺少独立确认。其次，责任人可以兼任升级审批人，但仅限问题影响范围未超出其权限的情况，并在矩阵中注明“超出权限时上报至更高层级”。最后，提出人兼任处理人时，应在问题记录中保留原始提出信息，关闭前由责任人确认处理结果，避免“自己提、自己关”。
按问题类型建RACI矩阵：行与列怎么设计
矩阵的列固定为四类角色，必要时增加“信息同步对象”一列承载I。行的设计有两种取舍：按问题类型拆分，适合问题来源多、处理路径差异大的项目；按处理环节拆分，适合所有问题都走同一套流程、但各环节交接频繁的场景。多数项目团队可以先按问题类型建行，再在每类问题内部用流程节点约束动作，兼顾可读性和可执行性。
每行只能有一个A，这是矩阵成立的前提。R可以有多个，但必须标出主处理人，其余为协同处理；C控制在真正需要其专业判断的人，I控制在需要知晓结果才能开展后续工作的人。C和I列得过满，矩阵会退化成通讯录，反而削弱约束力。
| 问题类型（行） | 提出人 | 处理人R | 责任人A | 升级审批人 | 需征询C | 需告知I |
|---|---|---|---|---|---|---|
| 需求理解偏差 | 填写 | 填写 | 填写 | 填写 | 填写 | 填写 |
| 跨部门接口不通 | 填写 | 填写 | 填写 | 填写 | 填写 | 填写 |
| 关键资源不到位 | 填写 | 填写 | 填写 | 填写 | 填写 | 填写 |
| 计划节点延期风险 | 填写 | 填写 | 填写 | 填写 | 填写 | 填写 |
填写规则可以固化为四条：第一，每行A唯一，且A必须是具体岗位或个人，不写部门名称；第二，R至少一人，多人时标注“主处理”；第三，C仅限对处理方案有实质影响的人，I仅限因该问题调整自身工作的人；第四，升级审批人一栏允许填写“同A，超出权限时上报至××”，但需写明上报对象。
矩阵粒度以能指导实际分派为准。问题类型超过十类时，先按大类建矩阵，再在问题登记表单中用子类型字段细化；环节拆分不超过五个节点，避免每行都要开一次协调会才能确定角色。粒度是否合适的判断标准很简单：拿到一个问题描述，能在矩阵中一分钟内找到对应的行并确定四类角色。
从问题提出到升级审批：四类角色在流程中的交接动作
矩阵是静态分工，流程节点决定角色在什么时点交接。把四类角色嵌入问题流转的五个节点，每个节点都应有明确的动作和输出状态，问题状态随之推进，而不是停留在口头沟通。
| 节点 | 主责角色 | 动作 | 输出状态 |
|---|---|---|---|
| 登记 | 提出人 | 填写问题描述、影响范围、发生时间，按矩阵选择问题类型，系统带出或手动填写处理人、责任人、升级审批人 | 已登记，待接单 |
| 接单 | 处理人 | 确认问题属实、补充初步原因判断、给出预计处理时间；不属实则退回并提出人补充信息 | 处理中 |
| 方案确认 | 责任人 | 审核处理方案、确认资源投入、决定是否需要征询C角色意见 | 方案已确认 |
| 升级 | 处理人或责任人发起，升级审批人裁定 | 满足触发条件时提交升级申请，说明受阻原因、已尝试动作和需要的支持；升级审批人给出继续处理、调整方案、追加资源或关闭上报的结论 | 升级审批中，或按裁定结果转入对应状态 |
| 关闭 | 责任人 | 核对处理记录和验证结果，确认问题影响已消除，填写关闭说明 | 已关闭 |
提出人登记时的必填字段包括：问题标题、现象描述、影响的对象与范围、发现时间、问题类型，以及由矩阵带出的处理人、责任人、升级审批人。这四个角色字段是矩阵落地的关键，缺少任一字段的问题不允许进入处理中状态。
处理人接单后承担原因分析和处理执行，处理过程中按约定频率更新进展。处理受阻时，处理人先判断是否满足升级触发条件，满足则提交升级申请，不满足则继续处理或向责任人求助。责任人确认方案和关闭两个节点不可省略：方案确认保证处理方向与项目目标一致，关闭确认保证问题真正解决而非暂时掩盖。
升级审批的触发条件应事先写进矩阵说明，常见条件包括：超过约定处理时限仍未解决、需要跨部门协调而责任人无权调动、处理方案将影响关键里程碑或项目范围、问题反复出现且根因不在当前团队。升级审批人的输出必须是明确结论，并记录裁定依据，便于后续复盘。
示例：一个跨部门接口问题如何按矩阵走完
以下为演示情景，用于说明矩阵的应用方式。某项目在联调阶段发现订单系统与库存系统的接口返回字段不一致，导致测试无法继续。按矩阵，该问题属于“跨部门接口不通”类型，提出人为测试负责人，处理人为订单系统开发负责人，责任人为项目集经理，升级审批人为项目发起人。
| 节点 | 角色 | 实际动作 | 记录状态 |
|---|---|---|---|
| 登记 | 测试负责人（提出人） | 登记接口字段不一致的现象、影响的测试用例范围，选择问题类型后带出其余三个角色 | 已登记，待接单 |
| 接单 | 订单系统开发负责人（处理人） | 确认字段差异来自接口版本未同步，预计两个工作日对齐 | 处理中 |
| 处理受阻 | 处理人 | 库存系统团队排期已满，两个工作日内无法配合修改，处理人提交升级申请 | 升级审批中 |
| 升级裁定 | 项目发起人（升级审批人） | 裁定本周内优先安排库存系统接口调整，订单系统同步提供字段映射说明 | 处理中，已追加资源 |
| 方案确认 | 项目集经理（责任人） | 确认字段映射方案和联调时间，通知测试负责人调整测试计划 | 方案已确认 |
| 关闭 | 项目集经理（责任人） | 核对联调通过记录和测试用例执行结果，填写关闭说明 | 已关闭 |
这个例子中，责任人与升级审批人的分工体现在：责任人负责方案确认和关闭，升级审批人只在跨部门排期冲突时介入并作出资源裁定。关闭时的证据包括联调通过的测试记录、字段映射说明文档和测试用例执行结果，三者齐备才允许关闭，避免问题在未验证的情况下被标记完成。
落地与检查：让矩阵真正约束问题流转
矩阵建好后能否生效，取决于它是否嵌入问题登记和流转的必经环节。落地动作从表单开始：问题登记表单的字段与矩阵列一一对应，问题类型选择后自动带出默认角色，允许手动调整但需填写调整原因。这样矩阵从一份文档变成每次登记都要经过的检查点。
推行阶段建议每月复核一次矩阵与实际流转的一致性。复核方法是抽取当期已关闭和升级的问题，逐条比对登记的处理人、责任人、升级审批人与矩阵是否一致，统计偏离次数和原因。偏离集中在某类问题时，说明该类问题的矩阵设计需要调整；偏离分散且原因多为“临时找人”，说明角色字段尚未成为硬约束，需要收紧表单必填和状态流转规则。
责任不清问题的复盘可以固定三个问题：问题在哪个节点出现角色空缺或角色冲突；当时的矩阵是否覆盖了这类问题；升级触发条件是否被正确识别。复盘结论应回写到矩阵或表单规则中，形成一次修正闭环，而不是停留在会议记录里。
在工具承载上，这类管理动作可以落到工作项的问题登记与状态流转中。以ONES为例，问题可以作为工作项登记，表单中设置提出人、处理人、责任人和升级审批人字段，状态按“已登记—处理中—方案已确认—升级审批中—已关闭”推进，角色字段与状态规则共同约束流转；矩阵本身则以问题类型为维度维护，登记时按类型带出默认角色。具体字段和流程配置需结合团队实际在系统中设置。
| 检查项 | 通过标准 | 负责人 |
|---|---|---|
| 矩阵覆盖度 | 当期发生的问题均能对应到矩阵中的某一行 | 项目管理办公室或项目集经理 |
| 角色字段完整性 | 处理中的问题100%填写四类角色字段 | 问题登记人及项目经理 |
| A唯一性 | 每条问题记录的责任人唯一且为具体个人 | 项目经理 |
| 升级触发合规 | 升级申请均满足预设触发条件，裁定结论有记录 | 升级审批人 |
| 关闭证据 | 关闭的问题均附验证结果和关闭说明 | 责任人 |
| 月度一致性复核 | 抽样问题中角色与矩阵一致率达标，偏离原因已记录并处理 | 项目管理办公室 |
检查清单建议在项目周会或月度例会上过一遍，重点看角色字段完整性和升级触发合规两项，这两项直接反映矩阵是否在约束实际流转。矩阵运行一段时间后，若某类问题的升级频率持续偏高，应回头检查该类问题的责任人权责是否足够，而不是简单增加升级审批层级。
常见问题
项目问题登记时，提出人和处理人可以是同一个人吗？
可以，但需要在记录中保留两个独立字段。提出人负责把现象、发生时间、影响范围说清楚，处理人负责原因分析和处理动作。同一人兼任时，登记环节仍分别填写提出人和处理人，关闭前由责任人确认处理结果，避免出现自己提、自己关的情况。若问题涉及多个处理方，还应标出主处理人，其余作为协同处理。
责任人已经能调动资源，还需要单独设升级审批人吗？
需要，前提是问题可能超出责任人的权限范围。责任人决定问题怎么解决、何时关闭；升级审批人处理的是责任人无权决定的事项，例如跨部门排期冲突、影响关键里程碑的方案调整、需要追加预算或人力。两者合一，升级就变成自己批准自己。若问题影响范围始终在责任人权限内，可以在矩阵中写明“同责任人，超出权限时上报至上一级”，并注明具体上报对象。
矩阵按问题类型建行还是按处理环节建行，怎么选？
看问题来源和处理路径的差异程度。问题来源多、不同类问题处理路径差别大时，按问题类型建行更直观，登记时选类型即可带出角色；所有问题都走同一套流程、环节交接频繁时，按处理环节建行更能约束节点动作。多数团队可以先按问题类型建行，再在每类问题内部用流程节点约束动作。判断粒度是否合适，可以看拿到一个问题描述后能否在一分钟内找到对应行并确定四类角色。
升级申请提交后，处理人这段时间应该做什么？
处理人继续推进不受升级事项影响的部分，同时把已尝试的动作、受阻原因和需要的支持记录在问题记录中，供升级审批人判断。升级审批期间问题状态标记为升级审批中，避免其他人误以为问题已停滞或被遗忘。升级审批人给出结论后，处理人按裁定结果继续处理、调整方案或配合关闭，并把裁定依据保留在记录里，便于后续复盘。
矩阵运行一段时间后，发现某类问题升级特别频繁，应该怎么调整？
先检查该类问题责任人的权责是否足够，而不是直接增加升级审批层级。升级频繁通常说明责任人缺少跨部门协调权限、资源调配能力不足，或者该类问题的处理路径本身设计不合理。复核时抽取该类问题的升级记录，看触发条件集中在哪一类，再决定是调整责任人、补充协同角色，还是修改处理流程。调整后回写到矩阵和登记表单，观察下一周期的升级频率是否下降。
