RACI矩阵要在研发团队落地，关键条件有三个：选一条边界清晰、近期会真实运行的跨角色流程做试点；每项活动只设一个A（最终负责）；用一次真实流程运行核对矩阵与实际行为是否一致。本文按“定范围—填角色—嵌流程—跑试点—做检查”的顺序，给出可直接执行的步骤、填写规则和完成检查清单。
要点总览（TL;DR）
- 先选一条跨角色、有明确起止、近期会真实运行的研发流程做试点，把活动拆到可交付物或决策点的粒度，形成8到15行的活动清单。
- 逐行填写R、A、C、I：R可以多人，A每行有且只有一个；C是意见影响结果的事先咨询，I是事后知会，C的数量要控制。
- 矩阵要挂到评审与交接节点上才有约束力：评审前按矩阵核对参会角色，结论由A确认；明确维护人、确认人和更新触发条件。
- 用一次真实流程运行验证矩阵，出现无人拍板、多人争责或关键角色事后才知道，就回到对应行调整A、C、I。
- 试点通过检查项后再扩展到相邻流程；连续出现找不到明确A、C过多导致评审难推进、维护人缺位时，先暂缓扩展。
落地前先定范围：选哪条流程、哪些活动进矩阵
RACI矩阵最常见的失败方式，是一开始就试图覆盖整个研发团队的所有工作。角色一多、活动一杂，矩阵会变成一张没人维护的大表。更稳妥的起点是选一条试点流程，把这条流程的活动列清楚，先让矩阵在这条流程上跑通。
试点流程的选取标准
一条适合做试点的研发流程，通常同时满足三个条件：
- 跨角色。流程中至少涉及三个以上岗位，例如产品、开发、测试、运维，否则RACI的四类角色区分不出来。
- 有明确起止。流程有清楚的触发条件和结束标志，例如“需求评审”从需求提交开始，到评审结论确认结束。
- 近期会真实运行。试点流程在未来两到四周内会有真实的需求或版本经过，这样才能用实际运行验证矩阵，而不是停留在纸面。
研发团队中常见的候选流程包括需求评审、技术方案评审、提测与验收、版本发布。首次试点建议选周期短、参与角色固定的一条，例如需求评审或提测流程，避免选跨越数月的大版本规划流程。
活动拆解的粒度
矩阵的一行对应一项活动。活动拆得太粗，例如只写“需求管理”，RACI无法区分；拆得太细，例如把“打开评审会议链接”也列为一行，矩阵会失去可读性。合适的粒度以可交付物或决策点为一行：
- 产生一个可交付物的动作，例如“输出需求文档”“提交测试报告”。
- 做出一个决策的动作，例如“确认需求优先级”“批准发布”。
一条试点流程拆出8到15行活动比较合适，既能覆盖关键交接，又不至于难以维护。
活动清单的输入来源
活动清单不需要从零编写，可以从三类现成材料中整理：现有流程文档或规范中的步骤描述；近期评审记录中实际发生的讨论与确认事项；交接环节中经常出现遗漏或争议的位置。第三类尤其值得关注，交接处出问题，往往说明职责边界本身不清楚，正是RACI要解决的地方。
本节交付物是一份试点流程的活动清单，包含流程起止、每项活动的名称和对应交付物。清单确认后，再进入角色填写。
四类角色怎么填：R、A、C、I的判定规则
填写矩阵时，逐行对每项活动判断四类角色。判定规则清楚，填写速度会明显加快，争议也会减少。
R与A的区别，以及每行只设一个A
R（Responsible，执行者）是实际动手完成活动的人，可以多人。A（Accountable，最终负责）是对这项活动结果负最终责任的人，每行有且只有一个。A不一定亲自执行，但活动出问题时由A承担并推动解决。
每行只设一个A，是RACI矩阵最核心的规则。出现两个A，等于没有人真正负责，争议时容易互相等待。如果一项活动确实涉及两个部门，需要先明确由谁做最终裁决，另一方通常归入C。
C与I的区分
C（Consulted，事先咨询）在活动完成前参与，其意见会影响决策或产出，通常是双向沟通。I（Informed，知会）在活动完成或关键节点后被告知结果，通常是单向通知。判断方法很简单：这个人的意见如果被忽略，活动结果是否需要返工？需要，就是C；只需要知道进展，就是I。
C的数量要控制。把大量岗位都标成C，会让每项活动都变成集体讨论，流程变慢。只保留意见真正影响结果的角色。
角色用岗位还是人名
矩阵中建议使用岗位或角色名，例如“后端负责人”“测试负责人”，而不是具体人名。岗位相对稳定，人员变动时矩阵不需要重写。对于一人多角色的小团队，可以在矩阵中标注同一人承担多个角色，但要检查是否出现自己执行、自己最终负责、自己咨询自己的情况。这类情况在小团队中难以完全避免，至少要在评审时由其他人做交叉确认。
研发常见活动的填写示例
下表以一条包含需求评审、设计评审、提测、发布的流程为例，演示逐行填写的结果。表中为演示情景，岗位名称可按团队实际调整。
| 活动 | R（执行） | A（最终负责） | C（事先咨询） | I（知会） |
|---|---|---|---|---|
| 需求文档编写 | 产品经理 | 产品负责人 | 技术负责人、测试负责人 | 项目经理 |
| 需求评审并确认结论 | 产品经理 | 产品负责人 | 技术负责人、测试负责人 | 开发团队 |
| 技术方案设计与评审 | 开发负责人 | 技术负责人 | 测试负责人、运维负责人 | 产品经理、项目经理 |
| 提测与冒烟验证 | 开发工程师 | 开发负责人 | 测试负责人 | 项目经理 |
| 发布上线 | 运维工程师 | 技术负责人 | 测试负责人、开发负责人 | 产品负责人、项目经理 |
填写完成后，逐列检查：A列每行是否只有一个名字；R列是否每行都有人；C列是否只保留了意见真正影响结果的角色；I列是否覆盖了需要知道结果但不必参与的角色。
把矩阵嵌进流程：评审、交接与变更时怎么用
矩阵填好只是文档，要真正约束行为，需要把它挂到流程的具体节点上，让每个角色在对应时刻知道自己的动作。
在评审与交接节点的使用方式
评审会议开始前，主持人按矩阵核对参会角色：A必须到场或明确授权，C应提前收到材料并给出意见，R准备交付物。评审结论由A确认，而不是由参会人数最多的一方决定。交接环节同样按矩阵执行，例如提测时，R提交测试说明，A确认提测范围，C中的测试负责人确认准入条件，I中的项目经理收到提测通知。
矩阵落到协作工具中时，可以把活动对应为工作项或评审任务，把A设置为该工作项的负责人，把C和I对应为评审参与人与知会对象。ONES的项目管理与流程自动化模块可以承载工作项流转和节点通知，帮助把矩阵中的角色关系固定到流程里；具体字段与通知规则需要按团队流程配置。ONES DevOps解决方案也将“团队角色协作困难”列为业务挑战之一，并提供项目管理、测试管理、流程自动化等模块组合，用于打通研发协作链路。
谁维护、谁确认、何时更新
矩阵需要明确一个维护人，通常由流程负责人或项目经理担任，负责记录变更并发布新版本。矩阵的确认由各活动的A共同完成，涉及跨部门边界时由双方负责人确认。更新触发条件包括：活动增减、交付物变化、岗位调整、连续两次运行中出现职责争议。更新后应通知所有受影响的C和I角色。
矩阵与任务分配、资源技能配置的边界
RACI矩阵回答的是“这项活动谁负责、谁参与、谁被告知”，它不负责具体到人的任务派发，也不处理人员技能是否匹配、工作量是否均衡。任务分配和资源技能配置属于另外的管理动作。把这两类问题混进矩阵，会让矩阵承担它无法承担的功能，最终难以维护。
一次试点运行示例：从活动清单到矩阵生效
下面用一个演示情景说明完整过程。某研发团队选择“提测流程”作为试点，流程从开发完成自测开始，到测试接收并给出冒烟结论结束。
活动拆解与逐行填写
团队从现有提测规范和最近三次提测记录中整理出五项活动：开发完成自测并提交提测单、确认提测范围与准入条件、部署测试环境、执行冒烟测试、输出冒烟结论并决定是否进入正式测试。逐行填写后，A分别落在开发负责人和测试负责人身上，每行只有一个A；C保留技术负责人和运维负责人；I为项目经理和产品经理。
运行中各角色的实际动作
第一次真实提测时，开发工程师作为R提交提测单并附自测记录；开发负责人作为A确认提测范围；测试负责人作为C在提测前确认准入条件；运维负责人作为C确认环境可用；项目经理作为I在提测完成后收到通知。冒烟测试由测试工程师执行，测试负责人作为A给出是否进入正式测试的结论。
暴露的问题与调整
运行中出现了两个问题：一是提测单提交后环境未就绪，开发和运维互相等待，原因是“部署测试环境”一行的A没有明确；二是产品经理被标为I，但实际需要参与冒烟结论的确认。团队据此调整：为环境部署活动补充明确的A，把产品经理从I调整为C。调整后第二次运行，等待时间明显缩短，结论确认也有了明确责任人。
这个示例说明，矩阵的价值不在填写本身，而在运行后能定位到具体哪一行、哪个角色出了问题，并做出有针对性的修改。
完成检查：判断矩阵是否真的落地
试点运行一到两次后，用下面的清单逐项核对，判断矩阵是否具备扩展条件。
| 检查项 | 核对方法 | 通过标准 |
|---|---|---|
| 每行有且仅有一个A | 逐行检查A列 | 无空行、无重复A |
| R不缺位 | 逐行检查R列 | 每项活动都有明确执行角色 |
| C与I无遗漏 | 对照最近一次运行的实际参与和通知记录 | 该咨询的角色提前参与，该知会的角色收到结果 |
| 实际行为与矩阵一致 | 用一次真实流程运行核对 | 评审、交接、确认的动作与矩阵标注相符 |
| 变更记录可追溯 | 检查矩阵版本与更新通知 | 每次调整有记录、有通知 |
验证方式以真实运行为准，不以文档是否漂亮为准。如果运行中出现无人拍板、多人争责、关键角色事后才知道的情况，说明对应行的A、C、I需要调整。
满足检查项后，可以把同一套方法扩展到相邻流程，例如从提测扩展到发布，或从需求评审扩展到技术方案评审。每次扩展仍按“选流程、拆活动、填角色、跑一次、做检查”的顺序执行。出现以下信号时建议暂缓扩展：矩阵连续两次运行后仍有行找不到明确A；C角色数量持续增加导致评审难以推进；维护人缺位，矩阵更新滞后于流程变化。这些信号说明当前流程的职责边界尚未稳定，先解决现有试点的问题，再扩大范围。
常见问题
小团队一人身兼多个角色，RACI矩阵还有必要做吗？
有必要，但填写方式要调整。小团队中同一个人可能同时是某项活动的R和A，矩阵里可以标注一人多角色，重点是检查是否出现自己执行、自己最终负责、自己咨询自己的情况。这类情况在小团队中难以完全避免，可以在评审时安排其他人做交叉确认，把关键结论的确认动作留给另一个人。矩阵的作用是让这些重叠关系显性化，而不是假装团队人手充足。
矩阵填好后，活动或人员发生变化怎么办？
把变更纳入固定机制，而不是临时口头调整。矩阵应有明确的维护人，通常由流程负责人或项目经理担任；活动增减、交付物变化、岗位调整，或连续两次运行中出现职责争议，都触发一次更新。更新后由各活动的A确认，并通知所有受影响的C和I角色。变更记录保留版本，便于追溯哪次调整对应哪次运行问题。
RACI矩阵和任务分配是什么关系，会不会重复管理？
两者回答的问题不同。RACI矩阵回答一项活动谁执行、谁最终负责、谁事先参与、谁事后知会，作用范围是流程层面的角色职责；任务分配则落到具体的人、具体的工时和交付时间。矩阵稳定后，任务分配可以参照矩阵确定负责人和参与人，但不需要把每个人的工作量、技能匹配都写进矩阵。把这两类问题混在一起，矩阵会变得难以维护。
评审会上A没有到场，流程还能继续吗？
可以继续，但需要事先明确授权。矩阵中A对活动结果负最终责任，评审结论应由A确认。A无法到场时，应提前指定授权人代行确认，并在记录中注明授权关系。若既不到场也没有授权，结论确认环节应暂缓，否则容易出现会后反复推翻结论的情况。这一条建议写进矩阵的使用说明，作为评审前的核对项。
扩展到第二条流程时，需要重新走一遍全部步骤吗？
需要，但可以复用已有经验。每条流程的活动清单、角色分布和交接点不同，仍按“选流程、拆活动、填角色、跑一次、做检查”的顺序执行。可以复用的是判定规则、表格格式、维护与变更机制，以及上一轮运行中总结出的常见问题。扩展时优先选与试点流程相邻、参与角色重叠较多的流程，例如从提测扩展到发布，迁移成本更低。
