用 RASCI 澄清跨角色协作职责

团队目标和个人边界写清后，一个结果涉及多个角色时，谁执行、谁拍板、谁需要被咨询、谁只需知道结论，仍然需要单独澄清。这个问题很快就在手头的项目里出现了。一个涉及需求、前端、后端、测试几方的事（待确认：补上项目名称和具体背景），连续遇到两类情况：一个技术方案等着有人拍板，等了几天没人动；一个需求变更改完了，测试到提测时才知道。参与的人都在干活，卡住的是角色之间的接口。

以前带小团队时我不需要处理这类问题。三四个人，谁在干什么互相都清楚，有拿不准的快速对一下就解决了。那时要是有人让我给协作画一张职责矩阵，我会觉得是多余动作。现在这个团队十几个人，跨角色、跨职能的事成了日常，“看起来人人都在负责、实际上没人负责”的情况反复出现，这张矩阵的性质就变了：从多余动作变成必要的澄清。

2 月写过 RASCI 模型的字母定义，结论是每件事尽早确定主 R。这次将它用于跨角色项目，说明适用条件、填表和校验方式、启动会确认方式，以及一个月后的检查信号。

什么情况值得用一次 RASCI

并非每个项目都需要职责矩阵。我以以下三个条件判断是否使用。

1. 参与的角色多，且分属不同职能或不同汇报线。同一个人从头到尾能完成的事，填 RASCI 是多余动作。
2. 交付物明确。能列出”这个东西做完算数”的具体产出，才谈得上给每个产出分配职责。还在探索方向的事，交付物自己没定形，矩阵填了也很快失效。
3. 已经发生过等待或返工，或者可以预见会发生。如果几方协作一直顺畅，说明接口事实上是清楚的，补一张表不改变任何人的行为。我以前的小团队就属于这种情况。

RASCI 用于处理参与者众多、但决策和信息同步责任不清的协作问题。项目目标尚未对齐时，应先完成目标对齐；职责矩阵不能解决该问题。

先列交付物和决策点，再填字母

我第一次填的时候顺序反了：先把人头列出来，再挨个想每个人该算 R 还是 A。这也是小团队习惯的延续，脑子里先有人再有事。填到一半填不下去，因为有些格子对应的事根本没有人认领过。后来把顺序倒过来：先列事，再配人。

列的事分两类。一类是交付物，需求评审结论、技术方案、测试报告、上线检查单这类能验收的东西。另一类是决策点，需求变更由谁确认、方案选型听谁的、上不上线谁拍板。决策点容易被漏掉，而协作卡住多数卡在决策点上，交付物反而还好。

事列全了再填字母。每个事项占一行，角色占列，格子里填 R、A、S、C、I，或者留空。留空是合法答案，表示这个角色和这件事没有关系。当时用的矩阵大致是这个形状（角色为概括性描述）：

矩阵的作用取决于交付物和决策点是否列全，以及角色是否经过当事人确认。

填完之后按四条规则校验

填完后先自行校验，再带到会议中确认。我使用以下四条规则。

每行必须有主 R，且尽量只有一个。没有 R 的行就是上一篇说的”没人认领的事”，写进矩阵里它也不会自动有人做。一行出现两三个 R，要追问一句：这几个人里谁对交付结果负责到底，答不上来就合并或指定。

A 尽量唯一。A 是对结果负全责、做最终判断的角色。一行出现两个 A，等于把”出了分歧听谁的”留给了事后，而分歧恰恰是最需要事先约定的部分。

C 的范围要受控。C 是做事前或做事中必须征求意见的人。C 填得太多，每个决定都要问一圈，决策速度回到没有矩阵之前。判断标准：这个人的意见会不会改变方案本身。只是”希望他知道”的，归到 I。

I 只同步必要结论。I 是被告知结果的人，不参与讨论。把 I 当 C 用，会议人数会膨胀；把该是 C 的人放成 I，他会在事后推翻结论，比事前征求意见更费时间。

拿到启动会上逐项确认，并挂到项目节奏上

矩阵填完后，应在项目启动会或评审会上逐项确认。念的时候会有争议——后端觉得自己也该是 C，测试觉得上线与否自己不只是 C。这种争议正好在会上解决，吵完改表，所有人对过一遍，才算定下来。私下填好发邮件知会，等于跳过了这一步，后面还会反复。

矩阵需要关联到项目的日常节奏，单独存放在文档目录中难以支持实际协作。我的做法是把它挂到项目例会里：遇到需求变更，先按矩阵找到确认人再走流程；交付物完成的标准，引用矩阵里对应那一行（待确认：补充当时的具体关联方式，是写在项目文档开头还是例会纪要里）。矩阵只管回答”这件事找谁”，推进和检查靠例会本身。

填表和使用中的常见问题

用 RASCI 固化组织层级。把 A 固定填成职级最高的人，把 R 固定填成职级最低的人。填出来的矩阵反映的是汇报线，和”谁对这件事的结果负责”未必一致。有些事的 A 应该是一线负责人，管理者只在 I 里。

给每个人都安排角色。为了让表格看起来人人有份，在每行都铺满字母。矩阵的价值恰恰在于留空：空格子说明这个角色不需要参与这件事，会议和同步都可以少叫一个人。

把知会当成共同决策。群发了消息、会上提了一句，就默认相关方都认可了。I 的定义是被告知结果，被 I 的人没有承诺过同意。需要对方认可才能推进的事，必须放在 C 里并真正收到回复。

一个月后看什么信号

矩阵是否改变协作方式，需要在项目运行一段时间后检查。我将检查时间定在项目运行一个月左右，观察以下过程指标：

• 决策等待是否变少。方案、变更这类事项从提出到有人拍板的间隔有没有缩短，还是仍然”等一个不知道是谁的人”。
• 需求变更由谁确认是否还有争议。同样的问题第二次出现时，大家是直接去找确认人，还是重新讨论一遍流程。
• 出问题时能否定位到责任接口。回顾一个延期或返工，能不能指着矩阵的某一格说清楚是哪一环断了，而不是拉一群人开会互相对口径。
• 矩阵本身有没有人在用。如果一个月里没人翻它、没人引用它，说明它回答的不是真实发生的问题，要么是事项列错了，要么是确认那一步没做透。

若一个月内无人查看或引用矩阵，通常说明矩阵没有覆盖实际发生的事项，或角色确认不充分，应据此修改矩阵。

小结

RASCI 这张矩阵澄清的是协作接口：谁执行、谁拍板、谁要被咨询、谁只需知道结论。它不回答目标对不对、人选得合适不合适，那些仍然要管理者自己判断。

职责矩阵用于澄清协作接口。实际运行中仍需通过例会和其他沟通渠道发现成员状态与协作问题。