“这件事不是有人在跟吗？”临近交付时问出这句话，往往已经晚了一步。编辑以为写完就能交，负责人等专业审核，客服等更新通知。大家都在群里，几项交接却没人说定。下面用假设的活动页项目说明怎样把这些责任拆开。
同样叫参与，承担的角色并不相同
RACI是一种责任分配矩阵，用四个字母区分执行、最终负责、征询意见和告知。先把具体交付事项放在行里，再把相关角色放在列里，比直接问“这个项目归谁”更容易形成可执行的约定。
| 序号 | 字母与英文 | 中文含义 | 需要回答的问题 |
|---|---|---|---|
| 1 | R · Responsible | 执行者 | 谁实际完成这项工作 |
| 2 | A · Accountable | 最终负责者 | 谁对结果负责并确认交付 |
| 3 | C · Consulted | 被征询者 | 完成或决定前要向谁征求意见 |
| 4 | I · Informed | 被告知者 | 进度或结果需要通知谁 |
常见设计是每项交付明确一位A，执行工作可以由多个R协作。这里的“明确”需要有关人员确认；表格不能覆盖组织本来的审批制度，也不会因为填上一个字母，就自动赋予某人系统权限。小团队里同一人可以同时承担A和R，不必为了填满表而额外安排人员。
先拆出结果，再讨论名字
假设一个虚构团队要上线活动页，先把工作拆成四份能确认的交付：页面初稿、价格与规则确认、上线批准、客服口径通知。不要只写一行“活动页上线”，否则资料准备、内容判断和发布操作会挤在一个模糊的责任里。
| 序号 | 交付事项 | R执行 | A最终负责 | C征询 | I告知 |
|---|---|---|---|---|---|
| 1 | 制作页面初稿 | 编辑 | 内容负责人 | 设计与业务人员 | 项目协调人 |
| 2 | 确认价格与活动规则 | 业务人员 | 获授权的业务负责人 | 必要的专业审核人 | 编辑 |
| 3 | 批准并安排上线 | 发布操作人 | 有发布批准权限的负责人 | 技术支持 | 客服 |
| 4 | 同步已确认的客服口径 | 项目协调人 | 业务负责人 | 客服代表 | 相关执行人员 |
这是一份讨论草稿，不是对任何真实公司的岗位授权。尤其第三行，需要把批准与操作分开理解：操作人有账号，并不意味着可以自行批准；负责人同意内容，也不意味着所有技术条件已经满足。如果批准与上线需要分别验收，可以再拆成两行。
名字填好后，交回当事人核对
把表交回相关人员逐行核对。执行者要知道交付物、位置和检查人；最终负责者要有权接下这项结果，并说明缺席时怎么办。征询和告知也得说清时点与方式，否则名字写进表里，人仍可能不知道什么时候该介入。
两个部门都要拍板，或没人接最终确认，就把分歧交给有权协调的人。解决前哪些动作暂缓，也一起写下来。制表者不能替双方随便删掉一个名字。
增加一条异常升级约定
日常安排清楚后，再讨论偏离计划怎么办。例如审核发现价格资料冲突，应由哪位负责人决定补资料还是延期；上线后出现错误，应先通知谁、谁有权暂停发布。约定应包含触发条件和授权范围，而不只是写“及时沟通”。
AI可以辅助从会议记录提取候选事项、找出缺少执行者的行，或标记多位最终负责者的冲突。但候选矩阵仍须人工确认；AI生成了表格，不等于相关人员已经接下职责。关于如何把角色与交付放进同一张表，可以参考 Asana的RACI实践说明。不同团队对执行角色的细分可能不同，采用哪种规则要共同确认，尤其要明确谁对结果和异常处理负责。
用一次真实交付检查这张表有没有用
选一个范围有限的事项试行，观察接手时是否仍要反复询问“找谁确认”，交付后需要获知结果的人是否及时收到信息，异常发生时是否有人能按授权采取动作。没有实际记录前，不要把“表已经填完”写成协作效率提升。
拿一次小交付试完，再问接手的人：还需要到群里四处找谁确认吗？该收到消息的人收到了吗？人员或范围一变，就更新表。确认和交接能照着走，这张矩阵才算派上了用场。
转载请注明：三五二萌文网 » 谁来做、谁拍板、通知谁？用 RACI 把项目责任说清楚
