团队目标和个人边界写清后，一个结果涉及多个角色时，谁执行、谁拍板、谁需要被咨询、谁只需知道结论，仍然需要单独澄清。这个问题很快就在手头的项目里出现了。一个涉及需求、前端、后端、测试几方的事（待确认：补上项目名称和具体背景），连续遇到两类情况：一个技术方案等着有人拍板，等了几天没人动；一个需求变更改完了，测试到提测时才知道。参与的人都在干活，卡住的是角色之间的接口。
以前带小团队时我不需要处理这类问题。三四个人，谁在干什么互相都清楚，有拿不准的快速对一下就解决了。那时要是有人让我给协作画一张职责矩阵，我会觉得是多余动作。现在这个团队十几个人，跨角色、跨职能的事成了日常，“看起来人人都在负责、实际上没人负责”的情况反复出现，这张矩阵的性质就变了：从多余动作变成必要的澄清。
2 月写过 RASCI 模型的字母定义，结论是每件事尽早确定主 R。这次把它放进跨角色项目里实际用了一遍。下面记录使用条件、怎么填和校验、启动会上怎么确认，以及一个月后看什么信号判断它有没有起作用。
什么情况值得用一次 RASCI
不是每个项目都需要画这张矩阵。我的判断标准是看三个条件是否同时成立。
- 参与的角色多，且分属不同职能或不同汇报线。同一个人从头到尾能完成的事，填 RASCI 是多余动作。
- 交付物明确。能列出”这个东西做完算数”的具体产出，才谈得上给每个产出分配职责。还在探索方向的事，交付物自己没定形，矩阵填了也很快失效。
- 已经发生过等待或返工，或者可以预见会发生。如果几方协作一直顺畅，说明接口事实上是清楚的，补一张表不改变任何人的行为。我以前的小团队就属于这种情况。
RASCI 处理的是”大家都参与、但决策和信息同步的责任不清”这一类协作问题。如果项目连目标都还没对齐，先做目标对齐，职责矩阵帮不上这个。
先列交付物和决策点，再填字母
我第一次填的时候顺序反了：先把人头列出来，再挨个想每个人该算 R 还是 A。这也是小团队习惯的延续，脑子里先有人再有事。填到一半填不下去，因为有些格子对应的事根本没有人认领过。后来把顺序倒过来：先列事，再配人。
列的事分两类。一类是交付物，需求评审结论、技术方案、测试报告、上线检查单这类能验收的东西。另一类是决策点，需求变更由谁确认、方案选型听谁的、上不上线谁拍板。决策点容易被漏掉，而协作卡住多数卡在决策点上，交付物反而还好。
事列全了再填字母。每个事项占一行，角色占列，格子里填 R、A、S、C、I，或者留空。留空是合法答案，表示这个角色和这件事没有关系。当时用的矩阵大致是这个形状（角色为概括性描述）：
| 事项 | 需求方 | 前端 | 后端 | 测试 | 我 |
|---|---|---|---|---|---|
| 需求评审结论 | A、R | C | C | C | I |
| 技术方案 | C | R | R | I | A |
| 测试报告 | I | I | C | R | A |
| 需求变更确认 | A | I | I | C | C |
| 上线与否 | C | C | C | C | A、R |
这张表本身没什么特别的，起作用的是填表和确认的过程。
填完之后按四条规则校验
填完先自己过一遍，再拿去开会。我用的是四条校验规则。
每行必须有主 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 这张矩阵澄清的是协作接口：谁执行、谁拍板、谁要被咨询、谁只需知道结论。它不回答目标对不对、人选得合适不合适，那些仍然要管理者自己判断。
职责矩阵只能澄清协作接口，不能替代持续沟通。实际运行中仍要通过例会和其他沟通渠道，及时发现成员状态与协作中的问题。
