用责任矩阵识别职责空缺，核心是把“活动—角色—责任类型”逐格对齐：先列出研发项目启动阶段的关键交付物与活动，再为每项活动标注R（执行）、A（最终负责）、C（需征询）、I（需知会），然后逐行扫描无A、无R、多A冲突、接口缺失和A过度集中等异常，把异常行登记为职责空缺清单，按类型补齐角色、明确接口与交接，最后用更新后的矩阵复核。本文适用于研发项目启动阶段，聚焦角色职责与空缺识别；单任务负责人指派归任务分配，人员技能评估归资源匹配，不在本文展开。
要点总览（TL;DR）
- 责任矩阵以活动或交付物为行、角色或岗位为列，单元格标注R（执行）、A（最终负责）、C（需征询）、I（需知会），行列覆盖完整与判定口径统一是识别空缺的前提。
- 六步操作依次为：列出启动阶段活动与交付物、确定角色列并去重合并、逐格标注责任类型、按规则扫描异常行、登记空缺清单并分类、复核矩阵并形成补齐方案。
- 判定职责空缺看六类异常：无A行、无R行、多A冲突、A与R同一角色且无备份、C/I缺失造成接口断点、同一角色A过多；人员技能不足归资源匹配，不登记为职责空缺。
- 补齐路径有三种：指定现有角色承接、新增角色、拆分活动；每条空缺只设一个补齐责任人，并写清接口的输入物、输出物与交接时点。
- 启动会后一周和下一阶段准入前各复核一次，检查矩阵完整性、空缺闭环和接口交接确认，复核结果记入矩阵版本说明。
先明确矩阵的行、列与责任类型
责任矩阵是一张二维表：行是项目启动阶段需要完成的活动或交付物，列是承担这些工作的角色或岗位。行列确定后，每个单元格标注该角色在该活动上的责任类型。矩阵能否用于识别空缺，取决于行列是否覆盖完整、责任类型判定口径是否统一。
行的设定：以活动或交付物为单位
行应写成可交付、可验收的对象，避免写成“做好沟通”“推进项目”这类无法判断完成状态的动作。研发项目启动阶段建议纳入以下范围：
- 需求确认：需求基线确认、需求评审结论、需求变更入口约定。
- 方案与架构：技术方案评审、架构决策记录、关键技术风险识别。
- 计划与排期：迭代计划、里程碑计划、资源投入计划。
- 环境与工具：开发/测试环境准备、代码仓库与权限开通、构建与发布流程约定。
- 风险与质量：风险登记册建立、质量目标与验收标准确认。
- 协作机制：例会与汇报节奏、问题升级路径、文档与知识库规范。
- 启动收口：启动会结论、干系人确认、下一阶段准入条件。
行清单的完成标志是：每行都能对应一个明确产物或可观察结果，且行与行之间不重复。
列的设定：角色或岗位，不写具体人名
列写角色或岗位，如产品负责人、项目经理、技术负责人、测试负责人、运维接口人、质量接口人。同一角色在不同团队可能由同一人兼任，建矩阵时先按角色列，标注完成后再检查兼任情况。列清单的完成标志是：每个角色都有明确职责边界，且不存在两个列实际指向同一职责却重复列出的情况。
R/A/C/I的判定口径
| 责任类型 | 含义 | 判定口径 |
|---|---|---|
| R（执行） | 实际完成该活动的人 | 问“这项工作由谁动手完成”，可以多人，但需明确分工 |
| A（最终负责） | 对结果最终拍板并承担后果的人 | 问“出问题时谁最终负责、谁有权验收”，每行有且仅有一个 |
| C（需征询） | 完成前必须征求意见的人 | 问“不咨询谁会导致返工或方案不可行”，双向沟通 |
| I（需知会） | 完成后需要被告知结果的人 | 问“谁需要知道结果但不必参与决策”，单向通知 |
判定口径统一后，标注才有可比性。常见误区是把“参与讨论的人”都标成C，导致C泛滥；或把“领导”默认标成A，导致A与实际决策权脱节。标注时应以实际权责为准，而非以职级为准。
识别职责空缺的六步操作
六步操作从建矩阵到产出空缺清单，每步都有明确输入、动作和输出，可按顺序执行，也可在启动会前后分两次完成。
第一步：列出启动阶段活动与交付物
输入是项目立项材料、启动会议程和上一阶段交接物。动作是逐条拆出启动期必须完成的活动与交付物，合并同义项，删除无法验收的表述。输出是一份行清单，建议控制在15–30行，过多可先按模块分组。完成标志是每行都有产物名称和完成标准。
第二步：确定角色列并去重合并
输入是项目组织架构、干系人名单和接口人约定。动作是把实际承担职责的岗位列为列，合并职责相同的重复列，标注兼任关系。输出是列清单及兼任说明。完成标志是每个列都能对应到具体岗位，且没有两个列职责完全重叠。
第三步：逐格标注责任类型
输入是行清单和列清单。动作是按R/A/C/I口径逐格填写，空白格表示该角色与该活动无责任关系。标注时先定A，再定R，最后补C和I。输出是初版矩阵。完成标志是每行至少有一个A和一个R，且标注人确认自己填的是实际权责而非期望权责。
第四步：按规则扫描异常行
输入是初版矩阵。动作是逐行检查是否存在无A、无R、多A、A与R同一人且无备份、C/I缺失、同一角色A过多等情况。输出是异常行列表，每行注明异常类型和涉及角色。完成标志是所有行都经过扫描，异常行有明确编号。
第五步：登记职责空缺清单并分类
输入是异常行列表。动作是把异常行登记为职责空缺清单，按“无人最终负责”“无人执行”“责任冲突”“接口断点”“负荷集中”分类，并注明影响的活动和交付物。输出是空缺清单。完成标志是每条空缺都能对应到具体行和具体角色缺口。
第六步：复核矩阵并形成补齐方案
输入是空缺清单。动作是针对每条空缺选择补齐路径，更新矩阵，明确责任人和完成时点，并确定知会范围。输出是更新后的矩阵和补齐方案。完成标志是更新后的矩阵中异常行清零或已有明确处理计划，且相关角色已确认。
空缺的判定规则与常见类型
并非所有矩阵异常都算职责空缺。判定时应区分“责任无人承担或责任冲突”与“人员能力暂时不足”，前者通过矩阵补齐解决，后者归入资源与技能管理。
| 判定规则 | 矩阵表现 | 空缺类型 | 处理方向 |
|---|---|---|---|
| 无A行 | 某行没有任何角色标A | 无人最终负责 | 指定A角色，明确验收权 |
| 无R行 | 某行只有A和C/I，没有R | 无人执行 | 指定执行角色或拆分活动 |
| 多A冲突 | 同一行有两个及以上A | 责任冲突 | 收敛为一个A，其余转为C或I |
| A与R同一人且无备份 | 某行A和R为同一角色，且无其他执行人 | 单点风险 | 补充备份执行人或明确交接条件 |
| C/I缺失 | 关键接口角色未出现在应征询或应知会位置 | 接口断点 | 补C或I，明确接口时点 |
| 同一角色A过多 | 某角色承担超过约定阈值的A | 负荷集中 | 拆分活动或转移A |
无A行是最需要优先处理的空缺，因为缺少最终负责人意味着验收和决策无人拍板。多A冲突在研发启动阶段常见于需求确认和技术方案评审，产品负责人与技术负责人可能都认为自己有最终决定权，此时应按决策事项拆分，而不是简单删掉一个A。
C/I缺失造成的接口断点容易被忽略。例如环境准备活动未把运维接口人标为C，导致环境开通条件未确认；或里程碑计划未把测试负责人标为I，导致测试排期冲突。这类空缺不表现为“没人做”，而表现为“做完才发现不匹配”。
同一角色A过多属于负荷集中型空缺。判定阈值可按项目实际约定，例如单个角色A的数量超过总行数的三分之一时触发复核。此时应检查是否活动拆分过细，或是否该角色实际承担了过多决策。
需要区分的是：某行有明确A和R，但执行人技能不足，这属于人员技能与资源匹配问题，不应登记为职责空缺。矩阵解决的是“谁负责”，技能评估解决的是“能不能做好”，两者分开处理，避免把培训需求混入角色补齐清单。
角色分工与接口安排：谁补、补什么、怎么交接
空缺清单产出后，需要把每条空缺转化为具体的角色安排。补齐路径有三种：指定现有角色承接、新增角色、拆分活动。选择哪种路径，取决于空缺类型和项目实际约束。
| 空缺项 | 补齐方式 | 责任人 | 交接物 | 完成时点 |
|---|---|---|---|---|
| 需求基线确认无A | 指定产品负责人为A | 项目经理 | 需求基线确认记录 | 启动会前 |
| 环境准备无R | 新增运维接口人为R，开发负责人为C | 技术负责人 | 环境开通清单与权限表 | 启动会后三个工作日内 |
| 方案评审多A | 收敛技术负责人为A，产品负责人转C | 项目经理 | 评审结论与决策记录 | 评审会当天 |
| 里程碑计划C/I缺失 | 补测试负责人为C，运维为I | 项目经理 | 里程碑计划确认版 | 计划发布前 |
| 风险登记A过多 | 拆分风险识别与风险处置，分别指定A | 项目经理 | 风险登记册与责任人清单 | 启动会当周 |
指定现有角色承接适用于职责边界清晰、只是漏标的情况；新增角色适用于现有角色确实无法覆盖的接口，例如跨团队环境开通；拆分活动适用于一行包含多个决策点、导致A无法唯一的情况。三种路径可以组合使用，但每条空缺只能有一个补齐责任人。
接口安排要写清输入输出和交接时点。以环境准备为例：开发负责人向运维接口人提交环境需求清单（输入），运维接口人完成开通并返回访问信息（输出），交接时点为启动会后第三个工作日。交接物应是可检查的产物，而非口头确认。
补齐后需要更新矩阵，并把变更知会到所有受影响的C和I角色。知会范围包括：新增或变更的A、R角色，以及因接口调整需要重新确认的C角色。更新后的矩阵应标注版本和更新日期，避免后续引用旧版。
矩阵落地后，活动和责任人的状态需要在协作工具中持续跟踪。ONES 可以在项目空间中承载启动阶段的活动清单、责任人和交付物状态，把矩阵中的行对应为工作项，把交接物挂接到对应工作项或文档，便于在启动会后的执行中核对责任是否按矩阵落实。这样矩阵不只是一张启动会材料，而是随项目推进可查、可更新的责任记录。
示例：一次研发项目启动会的矩阵检查
以下为演示情景，用于说明从建矩阵到发现空缺、补齐职责的过程，不代表特定团队的真实项目。
示例活动清单与角色列
某研发项目启动阶段列出8项活动，角色列包括产品负责人（PO）、项目经理（PM）、技术负责人（TL）、测试负责人（QA）、运维接口人（OPS）。初版矩阵标注如下：
| 活动/交付物 | PO | PM | TL | QA | OPS |
|---|---|---|---|---|---|
| 需求基线确认 | A/R | C | C | I | |
| 技术方案评审 | A | C | A/R | C | |
| 迭代与里程碑计划 | C | A/R | C | ||
| 开发环境准备 | A | C | |||
| 测试环境与数据准备 | A | C | R | ||
| 风险登记册建立 | A/R | C | C | I | |
| 代码仓库与权限开通 | A | R | |||
| 启动会结论与干系人确认 | C | A/R | I | I | I |
标注后发现的典型空缺行
- 技术方案评审：PO和TL同时标A，属于多A冲突，评审结论由谁最终拍板不清晰。
- 开发环境准备：只有PM标A、TL标C，没有R，也没有OPS参与，属于无人执行且接口缺失。
- 迭代与里程碑计划：QA未出现在C或I位置，测试排期输入缺失，属于接口断点。
- 代码仓库与权限开通：TL同时为A和R，OPS未参与，权限开通的单点风险和执行接口均未覆盖。
补齐动作与更新后的矩阵变化
针对上述空缺，启动会当场确认补齐方案：技术方案评审收敛TL为唯一A，PO转为C；开发环境准备新增OPS为R、TL为C，PM保留A；里程碑计划补QA为C；代码仓库与权限开通新增OPS为R，TL保留A。更新后，技术方案评审行变为TL为A/R、PO为C；开发环境准备行变为PM为A、OPS为R、TL为C；里程碑计划行补入QA为C；权限开通行变为TL为A、OPS为R。四条空缺全部闭环，矩阵版本更新为V2，并在启动会纪要中知会全体干系人。
完成检查：矩阵可用与空缺闭环的验收项
矩阵和空缺处理是否完成，可按以下清单逐项核对。检查由项目经理组织，技术负责人和主要接口人参与确认。
矩阵完整性检查项
- 行清单覆盖启动阶段关键交付物，每行有可验收的产物名称。
- 列清单为角色或岗位，兼任关系已标注，无重复列。
- 每行有且仅有一个A，至少有一个R。
- 关键接口角色已出现在C或I位置，无遗漏。
- 矩阵标注了版本号和更新日期。
空缺清单闭环检查项
- 每条空缺有编号、类型、涉及活动和影响说明。
- 每条空缺有补齐方式、责任人和完成时点。
- 补齐后的矩阵中对应异常行已消除或有明确处理计划。
- 负荷集中型空缺已完成活动拆分或A转移。
接口与交接确认检查项
- 每条新增或变更的接口有明确输入物、输出物和交接时点。
- 交接物已挂接到对应活动或文档，可被相关角色查阅。
- 变更已知会到所有受影响的C和I角色，并有确认记录。
复核时点与责任人
建议在启动会后一周和下一阶段准入前各复核一次。启动会后一周的复核由项目经理负责，重点检查补齐动作是否按计划完成；下一阶段准入前的复核由技术负责人参与，重点检查矩阵是否随活动变化更新。复核结果记录在矩阵版本说明中，作为下一阶段责任安排的输入。
常见问题
启动阶段活动很多，矩阵行数控制在多少合适？
建议先控制在15–30行，按需求确认、方案与架构、计划排期、环境与工具、风险与质量、协作机制、启动收口等模块分组。行数过多时，优先保留有明确交付物和验收标准的活动，把同一产物的多个动作合并为一行。行数过少则容易漏掉接口类活动，例如环境开通和权限配置，这类活动往往正是职责空缺的高发区。
某行同时有A和R由同一角色承担，一定要拆开吗？
不一定。A与R由同一角色承担本身可以接受，需要处理的是没有备份执行人的单点风险。判断标准是：该角色缺席或负荷饱和时，这项活动是否会停摆。如果会，就补充备份执行人，或明确交接条件和触发时点；如果活动影响小、可延后，记录风险并保持现状即可。矩阵检查的目标是让风险可见，而非把所有A和R强行分开。
多A冲突在启动会上当场定不下来怎么办？
可以先把该行标记为待决，并约定决策人和决策时点，避免带着模糊责任进入执行。常见做法是按决策事项拆分：技术可行性由技术负责人拍板，需求范围由产品负责人拍板，把一行拆成两行后各自只有一个A。如果确实无法拆分，由项目经理提请项目发起人裁定，裁定结果写入矩阵版本说明并知会相关角色。
矩阵更新后，如何确认各角色真的按新分工执行？
把矩阵中的行对应为可跟踪的工作项，责任人、交付物和交接时点随工作项记录，在启动会后一周的复核中逐项核对补齐动作是否完成。同时检查交接物是否已产出并可被相关角色查阅，变更是否知会到受影响的C和I角色。矩阵版本号和更新日期要同步维护，后续引用以最新版为准。
兼任多个角色的团队成员，在矩阵里怎么标注？
建矩阵时仍按角色列，不按人名合并，标注完成后再检查兼任情况。如果同一人兼任的两个角色在某行分别承担A和R，按单点风险规则处理；如果兼任导致某人的A数量超过约定阈值，按负荷集中型空缺处理，考虑拆分活动或转移A。兼任说明应附在列清单中，便于复核时识别负荷分布。
