RACI在研发团队落地，核心是把“谁都知道一点”的模糊分工，变成每项关键交付有且仅有一名A、若干R、被咨询的C和被知会的I，并把这张职责表挂到评审、变更、发布等固定节点上。本文按试点范围、拆解对象、角色分配、维护责任、流程接入、示例和验收七步展开，适合准备在1–2个研发环节先行试点的团队参照。
要点总览（TL;DR）
- 先选1–2个交付物清晰、跨角色多、返工频繁的研发环节试点，例如需求评审、技术方案评审、版本发布或缺陷定级，避免一上来铺满全流程。
- RACI表按交付物和决策点填写，不按岗位填写；一个对象对应一份可交付文档、一个可记录结论或一个需拍板的决定。
- 分配时守住四条规则：每项只有一个A，R可多人但明确主责执行人，C限定为必须被征求意见的角色，I只用于结果知会。
- 职责表本身要有Owner和更新触发条件，并在评审、变更、发布节点的入口和出口被实际引用，否则容易沦为孤立文档。
- 试点运行一个完整周期后，从A唯一性、C数量控制、节点引用证据、复核记录和缺口回填五方面验收，未达标按对应动作回退调整。
RACI落地先定范围：从哪个研发环节开始
第一步是圈定试点范围，把RACI用在交付物清晰、跨角色协作多、返工频繁的环节。这三个条件同时成立，职责不清造成的返工才容易被观察，试点效果也才可衡量。范围铺得过大，团队会在填表阶段就失去耐心。
常见的可选起点有四类：需求评审、技术方案评审、版本发布、缺陷定级。需求评审参与角色多、结论影响后续设计与开发；技术方案评审涉及架构、开发、测试多方判断；版本发布跨研发、测试、运维；缺陷定级则直接影响修复优先级。团队可结合近期返工记录，选其中问题最集中的1–2个环节。
选择时可用三个判断标准：该环节是否有明确的交付物或结论产出；是否涉及三个以上角色或团队；近一个季度是否出现过因职责不清导致的返工、延期或遗漏。三项都满足的环节优先纳入。
试点范围说明需要写清三部分内容：纳入环节、本次排除的环节及排除理由、后续扩展顺序。排除环节要写明原因，例如“发布环节涉及运维团队，待需求评审试点稳定后再纳入”，避免被理解为永久不做。扩展顺序建议按依赖关系排列，先做上游评审类环节，再做发布类环节。
完成标志是形成一份一页以内的试点范围说明，经研发负责人和试点环节的主要参与角色确认。
拆交付物与决策点：RACI表的填写对象
RACI表的填写对象是交付物和决策点，岗位只作为角色来源。以岗位为单位填表，容易写成岗位说明书，无法回答“这份文档谁最终负责”“这个结论谁拍板”。拆解时逐项问：这个环节产出什么、要做什么决定。
颗粒度有两个失败方向。过粗，例如整张表只有“需求评审”一行，职责依然模糊；过细，例如把一次会议的每个发言都列为对象，维护成本会迅速超过收益。合适的颗粒度是：一个对象对应一份可交付的文档、一个可记录的结论或一个需要拍板的决定，且该对象有明确的完成状态。
以需求评审环节为例，可拆出以下对象：需求文档（交付物）、评审结论（决策点）、变更申请（交付物，评审中提出修改时产生）、评审排期（交付物）。技术方案评审可拆出技术方案文档、方案选型结论、风险清单；版本发布可拆出发布计划、上线检查单、回滚预案、发布放行决定。
拆解完成后形成交付物与决策点清单，每个对象标注类型（交付物或决策点）、完成标志和所属流程节点。清单经试点环节参与者过一遍，确认没有遗漏关键对象，也没有把同一件事拆成多行。
分配R/A/C/I：四条规则与常见冲突处理
分配阶段按四条规则执行，规则的作用是让职责可判定，而非追求表格好看。
- 每项只有一个A。A是最终负责并承担结果的人，可以亲自执行，也可以只做批准。A唯一是整张表最重要的约束，出现两个A等于没有A。
- R可以多人，但需明确主责执行人。多人协作时在R中标注主责者，其余为协同执行，避免“大家都做”变成“没人推进”。
- C限定在必须被征求意见的角色。判断标准是：不咨询该角色，结论会有实质缺陷或无法执行。只是“知道了更好”的角色不列入C。
- I只用于结果知会。I不参与讨论、不阻塞流程，仅在接受结果后知晓进展。
三类常见冲突及处理办法：
| 冲突类型 | 表现 | 处理办法 |
|---|---|---|
| 一人多角色 | 同一人在不同对象上分别担任A、R、C | 在表中标注角色切换的场景，例如“需求文档为A，评审结论为C”，并在流程节点说明中写清何时以何种身份参与 |
| 跨团队A缺位 | 对象涉及多个团队，无人愿意承担A | 由上一级研发负责人指定唯一A，通常落在对该结果承担考核责任的一方，并在表中记录指定依据 |
| C膨胀 | 一项对象挂五六个C，评审变成多方等待 | 逐个追问“不咨询会怎样”，无法给出具体后果的移出C，改为I或直接移除 |
分配完成后产出职责表初稿和冲突处理记录。记录中写明每处冲突的处理方式和确认人，便于后续复核时追溯。
角色及交付物：谁维护、谁评审、谁使用
职责表本身也需要分工，否则一次填完就无人更新。建议指定一名Owner，通常由试点环节的流程负责人或项目管理角色担任，负责表的版本、变更和发布。
更新触发条件要事先写清，常见的有：组织或团队结构调整、流程节点增减、某对象连续两次在评审中被指出职责不清、季度复核发现与实际执行不符。触发后由Owner发起修订，修订范围限于受影响的对象行。
评审参与者包括试点环节的各角色代表，评审通过标准可设为三条：每项对象A唯一、C的数量有明确理由、表中角色与实际参与人员对应。评审通过后由Owner发布版本并通知相关角色。
使用场景分三类：评审前，主持人按表确认A和C是否到场；变更时，提出方按表找到对应对象的A确认；发布时，放行决定只由表中A做出。各角色在流程节点上以职责表为准，不再临时口头指定负责人。
把RACI挂到流程节点：评审、变更与发布的接入方式
职责表只有被流程节点引用才会生效。接入的基本做法是在每个固定节点的入口和出口各设置一次引用动作：入口处按表确认参与角色和A是否明确，出口处按表确认结论由A做出、C的意见已记录。
在评审节点，评审通知中附上本次涉及的职责表行，主持人开场确认A和C；在变更节点，变更申请单要求填写对应对象的A，未填写不予受理；在发布节点，放行决定记录中写明做出决定的A。职责表与工作项、文档状态的关联方式，可以是在工作项或文档模板中增加“对应职责表对象”字段，使每次流转都能回溯到具体行。
节点上发现职责缺口的回填机制同样需要约定：执行中发现某对象无人承担A、或C缺失导致结论无法执行时，由主持人当场记录缺口，节点结束后一个工作日内提交Owner，Owner判断是补充分配还是新增对象，修订后更新版本。
当职责表需要与工作项、评审记录和文档状态长期绑定时，可借助ONES这类研发管理平台承载：把职责表对象对应到工作项或文档，在评审、变更、发布的工作项流转中引用对应行，使A的确认和C的意见留在同一条记录里，减少表与执行两张皮的情况。具体承载方式需结合团队现有工具配置确定。
示例：一个需求评审环节的RACI表
以下为演示情景：某研发团队有产品、开发、测试、项目管理四类角色，选择需求评审作为试点环节。示例仅用于说明填表形态，不代表任何真实团队。
| 对象 | 类型 | R | A | C | I |
|---|---|---|---|---|---|
| 需求文档 | 交付物 | 产品经理（主责）、开发代表 | 产品负责人 | 测试代表、架构师 | 项目管理 |
| 评审结论 | 决策点 | 评审主持人 | 产品负责人 | 开发代表、测试代表 | 项目管理、相关开发 |
| 变更申请 | 交付物 | 提出变更的产品经理 | 产品负责人 | 受影响模块的开发负责人 | 测试代表 |
| 评审排期 | 交付物 | 项目管理 | 项目管理负责人 | 产品负责人 | 全体参会角色 |
示例中的处理方式：产品负责人在需求文档和评审结论上均为A，属于一人多角色，表中通过对象区分其职责——文档阶段承担内容最终责任，结论阶段承担拍板责任，两个动作在流程上前后衔接，不构成冲突。C的数量控制在每项不超过两个，测试代表在需求文档和评审结论上均为C，因为其意见直接影响可测性；架构师仅在需求文档上为C，评审结论阶段改为I，避免每次结论都等待架构确认。
这张表可直接作为需求评审环节的参照模板，替换角色名称后使用。
完成检查：RACI是否真正落地的验收项
试点运行一个完整周期后，按以下清单逐项核对，判断RACI是否真正落地。
| 检查项 | 达标标准 | 证据来源 |
|---|---|---|
| A唯一性 | 试点环节每项对象有且仅有一个A | 职责表逐行核对 |
| C数量控制 | 每项对象C不超过两个，且每个C有书面理由 | 职责表备注栏 |
| 流程节点引用 | 评审通知、变更申请、发布记录中能查到对职责表行的引用 | 节点记录抽样 |
| 复核记录 | 按约定周期完成复核，有版本更新或“无需修订”的结论 | 复核记录与版本历史 |
| 缺口回填 | 节点中发现的职责缺口已记录并处理完毕 | 缺口记录与修订版本 |
复核周期建议与团队迭代节奏对齐，例如每个迭代或每月一次，由Owner组织，重点核对表中角色与实际参与人员是否一致、C是否仍在膨胀。
未达标时的回退与调整动作：A不唯一，回到分配阶段重新指定并记录依据；C过多，按必要性逐个裁剪；节点引用缺失，检查是模板未加字段还是执行中跳过，前者修模板，后者在下次节点前重申；复核未执行，先确认Owner是否仍在岗，必要时更换Owner。若试点环节连续两个周期无法达标，可缩小范围到单个对象重新试行，再逐步扩展。
常见问题
试点环节选需求评审还是版本发布，怎么判断？
两个环节都可以作为起点，判断依据是近期问题集中在哪里。需求评审参与角色多、结论影响后续设计与开发，适合职责模糊主要表现为“结论没人拍板”的团队；版本发布跨研发、测试、运维，适合问题集中在“上线前谁确认、谁放行”的团队。
如果两类问题都明显，建议先做需求评审，因为它是上游环节，职责表稳定后可以复用到技术方案评审，再扩展到发布。发布环节涉及外部团队时，等评审类试点稳定后再纳入，扩展顺序按依赖关系排列。
一个对象上出现两个A，实际执行中怎么处理？
两个A等于没有A，需要回到分配阶段重新指定。处理时先确认该对象的结果由谁承担考核责任，通常由这一方担任唯一A；另一方如果必须参与，改为C并在备注中写明咨询原因。
跨团队场景下无人愿意承担A时，由上一级研发负责人指定，并在表中记录指定依据，便于后续复核追溯。指定后要在下一次流程节点前通知相关角色，避免执行时仍按旧习惯找错人。
C的数量控制到多少合适，业务方坚持要参与怎么办？
建议每项对象的C不超过两个，且每个C在备注中写明不咨询会导致的具体后果。业务方坚持参与时，先区分其诉求是“影响结论”还是“了解进展”：前者可列为C，后者改为I，通过结果知会满足知情需求。
如果业务方确实对多个对象都有实质影响，可考虑把这些对象合并或调整拆解颗粒度，而不是在每个对象上都挂C。C膨胀的直接代价是评审等待时间变长，这一点在试点周期内可以通过节点记录观察到。
职责表由项目经理维护，还是由各环节负责人各自维护？
建议指定一名Owner统一维护版本和发布，通常由试点环节的流程负责人或项目管理角色担任；各环节负责人作为评审参与者提供输入。统一维护的好处是版本可追溯、跨环节冲突能被发现，代价是Owner需要及时响应更新触发条件。
如果试点扩展到多个环节，可以按环节拆分维护责任，但版本号和发布动作仍集中在一处，避免出现多份并行版本。Owner离岗或长期无法响应时，需要提前约定替代人，否则复核机制会先失效。
试点两个周期仍未达标，是继续推还是先停？
先判断未达标集中在哪一项。如果是A不唯一或C过多，属于分配问题，回到分配阶段修订即可，不必停止试点；如果是节点引用缺失，检查是模板未加字段还是执行中跳过，前者修模板，后者在下一次节点前重申。
如果连续两个周期多项检查都不达标，可缩小范围到单个对象重新试行，例如只保留需求文档一项，跑通后再逐步增加对象。缩小范围不是放弃，而是降低维护成本，让团队先形成按表执行的习惯。
