研发团队用RACI分清审批人与执行人，关键在两点：每个交付物或决策点只设一个A（审批人），由其对结果负最终责任；R（执行人）承担具体产出并按时提交。把这两类角色逐行写清，再限定C（被咨询人）在定稿前提供意见、I（知会人）在结果确定后同步，职责表才能真正约束评审和发布。
要点总览（TL;DR）
- 把研发事项拆成以交付物或决策点为单位的行，例如需求定稿、技术方案评审、测试准入、发布审批、缺陷定级，一行对应一个可交付结果。
- 每行先定唯一A（审批人），写明审批动作与判断依据；再定R（执行人），写清产出物与提交时点，避免执行者自行批准自己的产出。
- C（被咨询人）限定在定稿前提供书面意见并记录采纳情况，I（知会人）只在结果确定后同步，防止咨询范围无限扩大拖慢决策。
- 把RACI行挂到需求评审、设计评审、测试准入、发布审批等固定节点，在评审记录中留下A的确认结论与R的提交材料。
- 用检查清单定期抽查：每行是否只有一个A、A的确认能否追溯、C与I是否各守时点，发现反复争议的行优先修正该行。
先定职责对象：哪些研发事项需要进RACI表
RACI表的第一项工作是把“要分清职责的事”列出来。判断标准是：这件事有没有一个可交付的结果，或者有没有一个需要拍板的决策点。有，就值得单独占一行；没有，就不要放进表里。
行应当写成交付物或决策点，例如“需求定稿”“技术方案评审通过”“测试准入判定”“版本发布审批”“缺陷等级认定”。写成“产品部”“开发组”“测试组”这类部门或岗位名称，会让表格变成组织架构说明，无法回答“谁批、谁做”。
粒度控制的原则是一行对应一个可交付结果，且不跨多个阶段。以“需求定稿”为例，它止于需求文档确认版本，不延伸到开发排期；以“发布审批”为例，它止于发布许可，不包含发布后的线上验证。若一行同时包含“方案评审”和“上线审批”，A会因阶段不同而难以唯一，表格随即失效。
需要说明与相邻管理动作的边界：RACI解决的是“某个结果由谁批、谁做、咨询谁、通知谁”，单个任务的负责人指派、任务拆分与工时安排属于任务分配范畴；人员技能是否匹配、谁适合承担某类工作属于资源与技能配置范畴。这两类问题可以在RACI确定角色后另行处理，不并入同一张表。
一份可用的行清单通常覆盖以下五类事项，团队可据此裁剪：
- 需求定稿：需求文档与验收标准的确认版本。
- 技术方案评审：架构或关键实现方案的通过结论。
- 测试准入：版本进入系统测试或验收测试的判定。
- 发布审批：版本具备上线条件的许可。
- 缺陷定级：严重缺陷的等级认定与处理优先级。
完成标志是：行清单中的每一项都能用一句话描述其交付结果，且团队对“这件事到哪一步算结束”没有分歧。
核心操作：逐行指定A、R、C、I的四步法
行清单确定后，逐行填写四个角色。四步的顺序不能颠倒：先定A，再定R，然后识别C，最后确定I。先定A是为了让审批责任成为表格的锚点，后续角色都围绕这个锚点展开。
第一步：为每行确定唯一A
输入是行清单和该事项的决策性质。动作是为每行指定一名A，并写明两件事：A的审批动作是什么（批准、驳回、有条件通过），判断依据是什么（验收标准、评审检查项、质量门槛）。输出是每行的A及其审批说明。完成标志是：任意一行被问“谁最终拍板”时，团队能给出同一个人名，且这个人能说出自己依据什么做判断。
一行只能有一个A。出现两个A，等于没有人对结果负责，争议时双方都可以等待对方决定。若确实存在两级审批，应拆成两行，例如“方案评审通过”和“方案预算批准”，各自设A。
第二步：指定R并明确产出与时点
输入是该行的交付结果定义。动作是指定承担具体产出的R，写清产出物名称和提交时点，例如“需求文档V1.2，评审会前两个工作日提交”。输出是R及其交付承诺。完成标志是：R能独立回答“我交什么、什么时候交、交给谁看”。
R与A的区别要在这里讲清：R负责把东西做出来并提交，A负责判断这个东西能否通过。R可以是多人协作，但每行的主R应当明确，避免出现“大家一起做、没人对提交负责”。
第三步：识别C并限定咨询时点
输入是该行涉及的专业判断需求，例如安全、性能、合规、运维影响。动作是列出必须被咨询的角色，并约定咨询发生在定稿前，同时说明意见如何被采纳或记录：采纳的写入文档，不采纳的注明理由。输出是C名单及意见处理方式。完成标志是：每个C都知道自己需要在什么时点之前给出意见，以及意见以什么形式留痕。
C最容易失控。把相关部门全部列为C，会让定稿前的沟通变成无休止的往返。控制方法是只保留“其意见会改变结论”的角色，其余转为I。
第四步：确定I与知会时机
输入是该行结果确定后需要知晓的范围。动作是列出I，并约定知会时机与渠道，例如“发布审批通过后，当日在发布群与项目文档中同步”。输出是I名单与知会方式。完成标志是：I在结果确定后能收到通知，且不需要参与定稿前的讨论。
四步完成后，逐行检查三类常见错误：一行出现多个A；把R写成A，即执行者自行批准自己的产出；C名单过长且没有意见处理规则。发现即回到对应步骤修正。
角色及交付物：谁维护RACI表，谁对结果签字
RACI表本身也需要责任人，否则它会在项目推进中逐渐过期。通常由项目经理或研发负责人担任维护者，负责建表、组织确认和版本更新。更新触发条件包括：组织调整导致角色变化、研发流程变更、新项目立项。每次更新保留版本记录，注明变更行与生效时间。
A的确认需要留下可追溯的形式。可选形式包括评审结论中的明确表态、审批记录、签字文件，或系统中对应的状态变更。形式可以因团队而异，要求是同一条：事后能查到“谁在什么时间、基于什么材料批准了这一行”。
| 角色 | 主要交付物 | 关键时点 |
|---|---|---|
| RACI表维护者 | 职责表及版本记录 | 项目立项、流程变更、组织调整时更新 |
| A（审批人） | 审批结论及判断依据 | 评审节点，R提交材料后 |
| R（执行人） | 交付物，如需求文档、方案、测试报告 | 评审会前按约定时点提交 |
| C（被咨询人） | 书面意见及采纳记录 | 定稿前，按约定时限反馈 |
| I（知会人） | 无交付物，确认接收 | 结果确定后，按约定渠道同步 |
R与A的交接时点应写进表格：R在评审前提交材料，A在评审中或评审后一个工作日内给出结论。C的响应时限建议与评审节奏对齐，例如“评审材料发出后两个工作日内反馈，逾期视为无异议”。I的知会通常在结果确定当日完成。
出现职责冲突时，升级路径要事先约定：先由该行A与R直接澄清；无法达成一致的，提交维护者协调；涉及跨部门资源或优先级冲突的，升级至项目负责人或研发负责人裁决。升级路径写进表格附注，避免争议发生时临时找人。
示例：一个需求从定稿到发布的RACI表
以下示例设定为单个需求的完整流转，团队规模与组织形态不影响表格结构，读者可按自身角色名称替换。示例中的角色用岗位代称，实际使用时替换为具体人名。
| 职责对象 | A | R | C | I |
|---|---|---|---|---|
| 需求定稿 | 产品负责人 | 需求分析师 | 技术负责人、测试负责人 | 项目成员 |
| 技术方案评审通过 | 技术负责人 | 开发工程师 | 测试负责人、运维负责人 | 产品负责人 |
| 测试准入判定 | 测试负责人 | 测试工程师 | 开发工程师 | 产品负责人、项目经理 |
| 发布审批 | 项目经理 | 开发工程师 | 测试负责人、运维负责人 | 产品负责人、客服接口人 |
| 严重缺陷定级 | 测试负责人 | 测试工程师 | 开发工程师、产品负责人 | 项目经理 |
逐行说明审批依据与产出。需求定稿一行，A依据验收标准是否完整、范围是否清晰作出批准，R产出需求文档与验收标准清单。技术方案评审一行，A依据方案是否覆盖性能、安全与回滚安排作出结论，R产出方案文档与评审材料。测试准入一行，A依据用例执行结果与遗留缺陷情况判定是否放行，R产出测试报告。发布审批一行，A依据测试结论、上线检查单与回滚预案批准发布，R产出发布说明与部署清单。缺陷定级一行，A依据影响范围与复现情况认定等级，R产出缺陷记录与复现步骤。
C的意见进入定稿的方式是书面反馈：技术负责人与测试负责人在需求评审前提交意见，采纳的写入需求文档，未采纳的在评审记录中注明理由。I的知会时机是各行结果确定后当日，通过项目文档与团队频道同步，知会对象无需回复。
示例的适用边界：它覆盖单个需求从定稿到发布的主干节点，不包含多团队联合发布、外部合规审查等场景。团队在迁移时应保留“一行一个结果、一行一个A”的结构，按自身节点增删行，不宜直接照搬角色名称。
嵌入研发流程：让RACI在评审节点生效
表格停留在文档里不会改变行为，生效的方式是把它挂到固定节点上。需求评审、设计评审、测试准入、发布审批四个节点分别引用RACI表中对应的行：会前由R按约定提交材料，会中由A对照判断依据给出结论，C的意见在会前已书面提交，I在结论确定后收到同步。
落地动作清单如下：
- 在评审通知中附上本次评审对应的RACI行，标明A、R、C、I。
- 评审记录中写明A的确认结论与依据，R的提交材料作为附件或链接留存。
- 发布审批前核对发布行的A是否已确认，未确认不进入发布。
- 职责变更时更新表格版本，并在下一次评审通知中引用新版本。
承载这些动作的载体可以是评审文档、审批单，也可以是研发管理工具中的工作项与文档状态。以ONES为例，团队可以把每个职责对象建成工作项，用状态流转记录R的提交与A的确认，把评审结论和知会记录留在同一处，便于事后追溯。具体状态如何配置，需结合团队现有流程设定。
版本管理同样重要。表格每次更新应记录变更行、变更原因和生效时间，旧版本归档。评审时引用当次生效版本，避免出现“按旧表审批、按新表追责”的情况。
完成检查：RACI表是否真的分清了审批人与执行人
机制是否生效，可以用以下清单逐项核对。每项给出通过标准，未通过时对应修正动作。
| 检查项 | 通过标准 | 未通过时的修正 |
|---|---|---|
| 每行是否只有一个A | 逐行核对，A列无并列人名 | 拆分事项或明确唯一拍板人 |
| A是否有明确审批动作与依据 | 每行能说出批什么、依据什么 | 补充判断标准，写入表格附注 |
| R是否清楚产出物与提交时点 | R能复述交付内容与时间 | 在行内写明产出物名称与时点 |
| C是否限定在定稿前 | C名单精简，意见有书面记录 | 移除非必要C，约定反馈时限 |
| I是否只在结果确定后知会 | I不参与定稿前讨论 | 调整知会时机与渠道 |
| 评审记录能否追溯到A的确认 | 抽查最近三次评审，均有A的结论记录 | 在评审模板中增加A确认栏 |
| 职责争议是否按升级路径处理 | 争议有处理记录与结论 | 补充升级路径并告知全员 |
抽查方式建议每季度进行一次：随机抽取若干已完成的评审，检查A的确认是否可追溯、R的提交是否按时、C的意见是否有记录。发现同一行反复出现争议，说明该行的A设置或判断依据存在问题，应优先修正该行，而非增加更多协调会议。
当以上检查项全部通过，RACI表才算真正分清了审批人与执行人：每个结果有人拍板、有人交付、有人被咨询、有人被知会，且这些动作都能在评审记录中找到痕迹。
常见问题
研发团队规模较小、角色重叠时，一个人可以同时担任A和R吗？
同一个人可以在不同行分别担任A和R，但在同一行内，A与R由同一人承担会削弱审批的把关作用，因为执行者批准自己的产出时缺少独立判断。小团队人手紧张时，可行的做法是：在同一行内把A交给另一位能对结果负责的成员，例如技术方案由开发工程师执行、技术负责人审批；若确实无人可分担，至少要求A在评审记录中写明判断依据，并接受维护者的定期抽查。角色重叠不改变“一行一个A”的结构，只改变人选安排。
RACI表定稿后，需求范围或流程发生变化，表格怎么同步？
表格需要指定维护者，并在三类触发条件下更新：组织调整导致角色变化、研发流程变更、新项目立项。更新时记录变更行、变更原因和生效时间，旧版本归档。同步的关键是评审时引用当次生效版本，并在评审通知中附上对应行，避免出现按旧表审批、按新表追责的情况。若变更只涉及某一行的人选，也应更新版本，而不是口头通知，否则事后追溯会失去依据。
C（被咨询人）反馈太慢，导致评审一再推迟，怎么处理？
先检查C名单是否过长。只保留“其意见会改变结论”的角色，其余转为I。对保留的C，约定明确反馈时限，例如评审材料发出后两个工作日内反馈，逾期视为无异议，并在表格附注中写明这一规则。同时要求C的意见以书面形式提交，采纳的写入文档，未采纳的注明理由。这样既压缩了往返次数，也让意见处理有据可查。若某类意见反复影响结论，可考虑把该角色提升为共同审批并拆出独立行，而不是继续在C环节反复协商。
评审记录中怎样才算留下了A的确认痕迹？
可追溯的标准是：事后能查到谁在什么时间、基于什么材料批准了这一行。常见形式包括评审结论中的明确表态、审批记录、签字文件，或系统中对应的状态变更。无论采用哪种形式，都应同时保留R提交的材料作为依据。抽查时随机抽取已完成的评审，检查A的结论是否与提交材料对应；若发现只有会议纪要中的笼统表述，应在评审模板中增加A确认栏，写明结论与依据。
RACI和任务分配是什么关系，会不会重复管理？
两者解决不同问题。RACI确定的是某个交付物或决策点由谁批、谁做、咨询谁、通知谁；任务分配解决的是具体任务拆给谁、工时怎么排、进度怎么跟。实践中可以先定RACI，明确每个结果的责任结构，再在任务层面做拆分与指派。把两者混在一张表里，容易让职责表变成任务清单，反而看不清审批关系。人员技能是否匹配、谁适合承担某类工作，属于资源与技能配置范畴，同样在RACI确定角色后另行处理。
