RACI矩阵在研发团队落地，关键是把一张职责表变成可执行的协作规则：先选一个跨角色协作密集的流程做试点，为每项活动确定唯一的A（最终负责），再明确R（执行）、C（事前咨询）和I（事后知会），最后把矩阵对应到工作项、评审节点和状态流转中，用一次真实迭代验证后再扩展。本文按试点选择、填写规则、维护职责、流程承载、完整示例和验收检查六步展开。
要点总览（TL;DR）
- RACI落地从选一个跨角色协作密集的试点流程开始，先列活动清单、角色清单和待验证问题，范围控制在一到两周能画完并验证。
- 填写顺序是先定唯一A，再定R，最后补C和I；A可以不是执行者，C是事前必须征求意见的对象，I是事后知会对象。
- 矩阵需要明确流程负责人、角色代表和矩阵管理员三类职责，并作为受控文档记录版本与变更，避免画完无人维护。
- 把每项活动对应到工作项和评审节点，明确C的意见截止时间和A的确认时限，用状态流转体现R完成、A确认的交接。
- 试点运行一个完整迭代后，用A唯一、R有资源、C和I数量合理、矩阵与实际一致、变更有人维护五项检查判断是否落地，再决定扩展。
先定试点流程：RACI从哪里开始画
RACI落地的第一步是选一个具体流程作为试点，把范围收窄到可以在一到两周内画完并验证的程度。研发团队常见的候选流程包括需求评审、版本发布、缺陷分级处理、技术方案评审、上线变更审批。判断哪个适合先做，可以看三个信号：参与角色是否超过三个、是否存在明显的等待或返工、是否经常出现“以为对方会做”的情况。三个信号越集中，试点价值越高。
确定试点流程后，需要准备三类输入。第一是活动清单，把该流程从触发到结束的关键活动逐条列出，用动词开头，例如“提交需求评审材料”“确认技术可行性”“批准排期”。第二是现有角色名称，直接使用团队当前的组织称谓，如产品经理、开发负责人、测试负责人、架构师、项目经理，避免为画矩阵临时发明新角色。第三是关键交付物，标明每项活动产生或依赖的文档、记录或工作项，便于后续与工具对应。
同时要写清本次落地要验证的具体问题，例如“需求评审中谁对最终范围拍板”“缺陷修复的验收由谁确认”。问题写得越具体，后面填矩阵时越容易判断某个格子该不该填。试点阶段不建议画全公司或全部门的矩阵，范围过大时角色名称不统一、活动颗粒度不一致，矩阵很快会变成无人使用的文档。
本步骤的产出是一份试点流程说明，包含流程边界、活动清单、角色清单、关键交付物和待验证问题。完成标志是流程负责人能对着这份清单向参与角色讲清楚“我们要解决什么”，并且活动清单经过各角色代表一次确认。
逐项填矩阵：A、R、C、I的判定规则
填写矩阵建议按固定顺序进行：先定A，再定R，最后补C和I。先定A能迫使团队回答“这件事最终由谁负责”，避免在讨论执行细节时模糊责任归属。每项活动只能有一个A，A可以不是实际执行者，也可以是某个角色的负责人而非个人。出现两个A时，要么拆活动，要么明确其中一个是C或I。
R是实际完成活动的人，可以多人，但多人R需要在矩阵备注中说明分工，例如“开发负责人编写方案，架构师完成技术验证”。如果一项活动有多个R却说不清各自做什么，通常说明活动颗粒度太粗，应拆成两项活动。C是事前必须征求意见的对象，其意见会影响活动结果，缺少C的输入活动就无法可靠完成。I是事后知会的对象，只需要知道结果，不参与决策。C和I的区别在于时点和影响程度：C在活动完成前介入，I在活动完成后接收信息。
C和I数量过多是RACI填写中最常见的问题。收敛方法有三种：一是把“顺便知会”的对象从I中删除，改为通过例行同步或看板自行获取；二是把只在个别情况下需要征求意见的对象标注为条件性C，写明触发条件；三是把多个同质角色合并为一个代表，例如由测试负责人代表测试团队接收知会。一张矩阵中，单项活动的C通常控制在一到两个，I控制在三个以内，超过时先检查是否活动拆得不够细或角色设置过粗。
填写时还需要注意两个规则：同一项活动中，A和R可以是同一人，但该人同时承担决策和执行时，要在评审环节引入独立的C或确认动作，避免自我确认；C不能替代A做决定，C的意见是输入，最终取舍仍由A负责。矩阵填完后，建议逐行朗读一遍“谁负责、谁执行、谁被咨询、谁被知会”，由参与角色当场确认，口头确认比事后邮件确认更容易暴露分歧。
角色与交付物：谁维护矩阵、谁确认责任
矩阵画完无人维护，是RACI失效的主要原因。落地时需要明确三类职责。流程负责人负责组织填写、主持确认会、裁定A的归属争议，并在流程变更时发起矩阵更新。各角色代表负责确认本角色在矩阵中的R、C、I是否与实际工作一致，并在人员或分工调整时提出修改。矩阵管理员可以由项目经理或流程管理岗兼任，负责版本记录、变更登记和发布通知。
矩阵应作为受控文档管理，至少记录版本号、生效日期、变更内容和确认人。变更方式建议采用轻量流程：角色代表提出修改申请，流程负责人确认影响范围，涉及A变更的需相关角色共同确认，变更后在团队例会上同步。矩阵不宜频繁改动，但也不能一年不更新；当流程活动、角色设置或评审规则发生实质变化时，应触发一次复核。
矩阵与现有职责说明、评审规则的关系需要提前说清。职责说明描述角色的长期职责范围，RACI矩阵描述具体流程中每项活动的责任分配，两者是补充关系。评审规则中已有的审批人和参与人，应与矩阵中的A和C保持一致；出现不一致时，以矩阵确认会的结果为准，并同步修订评审规则，避免两套文件互相矛盾。
本步骤的产出包括RACI维护职责表和矩阵变更规则。维护职责表列明流程负责人、角色代表、矩阵管理员各自的动作和频率；变更规则写明谁可以发起、谁确认、多久复核一次、变更后如何通知。完成标志是矩阵文档有明确的责任人和版本记录，且下一次流程变更时有人按规则发起更新。
把矩阵接进研发流程：工作项、评审与状态
矩阵停留在文档里，日常工作中仍按习惯推进，RACI就不会真正生效。让矩阵进入流程的关键，是把每项活动对应到团队已经在用的工作项和评审节点上。需求、任务、缺陷、技术方案都可以作为承载活动的工作项类型；每项活动对应一个工作项或工作项中的一个检查项，矩阵中的角色对应到工作项上的负责人、评审人和知会人字段。
评审节点是A和C发挥作用的主要场景。在评审发起时，由R提交材料；评审过程中，C在规定时点前给出意见；评审结束时，由A做出确认或退回的决定。这里需要明确两个时点：C的意见输入截止时间，以及A的确认时限。缺少截止时间时，C容易变成拖延环节，A也容易在信息不全时被迫拍板。状态流转可以体现交接关系，例如“待评审—评审中—待A确认—已确认”，R完成材料提交后状态进入待确认，A确认后状态关闭，I在状态关闭后收到通知。
ONES等研发管理平台可以按需承载工作项、评审流程和角色字段，把矩阵中的责任关系配置到实际流转中，具体能力以实际产品资料为准。配置时建议从试点流程的一到两个评审节点开始，验证字段和状态是否够用，再逐步覆盖其他活动。工具配置的作用是让责任可见、可追溯，矩阵本身的判定规则仍需要在确认会上达成一致。
本步骤的产出是一张对应关系表，列出活动、承载工作项类型、评审节点、A/R/C/I对应字段和状态流转。完成标志是试点流程中的关键活动都能在工作项中找到对应位置，且评审记录能追溯到具体的A确认和C意见。
示例：一个需求评审流程的RACI填写
以下示例为演示情景，用于说明填写过程，不代表特定团队的实际做法。假设一个研发团队要梳理需求评审流程，参与角色包括产品经理、开发负责人、测试负责人、架构师和项目经理。活动清单拆为五项：编写需求说明、评估技术可行性、评估测试工作量、确认需求范围与排期、发布评审结论。
| 活动 | A | R | C | I |
|---|---|---|---|---|
| 编写需求说明 | 产品经理 | 产品经理 | 开发负责人 | 项目经理 |
| 评估技术可行性 | 开发负责人 | 架构师 | 产品经理 | 测试负责人 |
| 评估测试工作量 | 测试负责人 | 测试负责人 | 开发负责人 | 项目经理 |
| 确认需求范围与排期 | 产品经理 | 项目经理 | 开发负责人、测试负责人 | 架构师 |
| 发布评审结论 | 项目经理 | 项目经理 | — | 全体参与角色 |
填写过程中出现了两处冲突。第一处是“确认需求范围与排期”最初被产品经理和项目经理同时标为A，讨论后确认范围取舍由产品经理最终负责，项目经理负责排期协调并作为R，冲突通过拆分决策权和执行动作解决。第二处是“评估技术可行性”最初把测试负责人列为C，测试负责人提出技术方案评审阶段测试只需知会结果，最终改为I，减少了不必要的评审等待。
从这个示例可以提炼几条可迁移的规律：活动按“产出什么”拆解比按“谁来做”拆解更稳定；A集中在少数对结果负责的角色上，避免每项活动都出现多个A；C只保留意见会改变结果的对象，其余转为I；发布类活动的A通常是负责流程闭环的人，而不是内容编写者。
完成检查：判断RACI是否真正落地
试点运行一个完整迭代后，可以用一份检查清单判断RACI是否落地。检查项应逐条核对，并记录证据来源，例如矩阵文档、工作项记录、评审记录和角色访谈。
| 检查项 | 通过标准 | 证据来源 |
|---|---|---|
| 每项活动A唯一 | 矩阵中无一项活动出现两个A，相关角色能说出本流程的A是谁 | 矩阵文档、角色访谈 |
| R有对应资源和时间 | 每项活动的R在工作项中有明确负责人和计划时间，未出现无人认领 | 工作项记录 |
| C和I数量合理 | 单项活动C不超过两个、I不超过三个，评审未因等待意见而明显延长 | 评审记录、周期数据 |
| 矩阵与实际一致 | 抽查的工作项和评审记录中，负责人、评审人、知会人与矩阵一致 | 工作项与矩阵对照 |
| 变更有人维护 | 试点期间发生的角色或流程调整已反映在矩阵版本记录中 | 变更记录 |
通过标准可以设为：五项检查全部满足，且试点流程的平均评审等待时间或返工次数较试点前有可观察的改善。若只有部分满足，优先处理A不唯一和R无资源两类问题，这两类问题对执行的影响最直接；C和I过多可以通过下一轮收敛解决。
扩展的触发条件建议写清楚：试点流程连续一个迭代通过检查，且参与角色对责任分配无重大异议，再将方法复制到下一个流程。扩展时沿用同一套活动拆解和填写规则，但角色名称和A的归属需要重新确认，不直接套用试点矩阵。每次扩展后重复一次检查，逐步形成覆盖主要协作流程的矩阵集合。
常见问题
研发团队第一次画RACI，应该选哪个流程做试点？
优先选参与角色超过三个、存在明显等待或返工、经常出现“以为对方会做”的流程，例如需求评审、版本发布或缺陷分级处理。试点范围控制在一到两周能画完并验证的程度，同时写清本次要验证的具体问题，例如“需求范围最终由谁拍板”。不建议第一次就画全部门矩阵，角色名称和活动颗粒度不统一时，矩阵很难维护。
一项活动出现两个A，应该怎么处理？
先判断是两个角色都在对结果负责，还是活动本身拆得不够细。常见处理方式有两种：把活动拆成决策和执行两项，分别设A；或者确认其中一方实际提供的是意见输入，将其改为C。示例中“确认需求范围与排期”最初由产品经理和项目经理同时标A，最终确认范围取舍由产品经理负责，项目经理作为R承担排期协调。A变更后需要相关角色共同确认，并同步更新矩阵版本。
C和I填得太多，评审总是等人怎么办？
先检查是否把“顺便知会”的对象放进了I，这类对象可以改为通过例行同步或看板自行获取信息。对只在特定情况下需要征求意见的角色，标注为条件性C并写明触发条件。多个同质角色可以合并为一个代表，例如由测试负责人代表测试团队接收知会。同时为C设置意见输入截止时间，为A设置确认时限，缺少时限时C容易变成拖延环节。
矩阵画完后，日常工作中怎么防止它变成一份没人看的文档？
关键是让矩阵进入工作项和评审节点：每项活动对应一个工作项或检查项，矩阵中的角色对应到负责人、评审人和知会人字段，评审状态按“待评审—评审中—待A确认—已确认”流转。同时明确流程负责人、角色代表和矩阵管理员各自的动作与频率，流程活动或角色设置发生实质变化时触发复核。工具承载的具体配置方式，以团队实际使用的平台资料为准。
试点运行多久、达到什么条件才可以扩展到其他流程？
建议至少运行一个完整迭代，用五项检查核对：每项活动A唯一且相关角色知晓、R有对应资源和时间、C和I数量合理、矩阵与实际工作项和评审记录一致、变更有人维护。五项全部满足，且评审等待时间或返工次数有可观察改善，再复制到下一个流程。扩展时沿用活动拆解和填写规则，但角色名称和A的归属需要重新确认，不直接套用试点矩阵。
