职责空缺往往不是没人上班，而是某类动作长期没人真正负责：评审没人拍板、交接没人确认、异常没人升级。处理这类问题，先界定空缺的是哪一类角色责任，再用责任矩阵把决策、执行、评审、知会四类动作落到具体角色，随后补齐交接接口与代理规则，最后用一次真实任务验证空缺是否被覆盖。核心产物是一张角色责任矩阵、一份交接清单和一条代理与升级规则。ONES 可在矩阵落地与交接确认环节承载角色权限与工作项流转。
要点总览（TL;DR）
- 先按决策、执行、评审、知会四类动作拆解现有职责，区分角色空缺、单任务无人负责与技能不匹配三种问题，输出空缺清单。
- 用业务环节或交付物作行、角色作列填写责任矩阵，每个交叉格只标一类主要责任，空缺格给出指定承担、拆分或书面暂不设置三种处置。
- 为每个跨角色交接定义输入物、输出物、交接时点与确认方式，并写明未确认时的停留状态与催办角色。
- 为关键角色指定第一代理人与可判断的触发条件，按响应时长设置升级路径，区分临时代理与正式任命并设复核节点。
- 选一个近期跨角色任务按新矩阵回放，记录无人承接与交接断点，回写矩阵修订后按验收清单收尾。
先判断空缺的是哪一类角色责任
补职责空缺的第一步是定位缺口，直接加人容易把问题从“没人负责”变成“多人负责但无人拍板”。识别时以动作为起点，把一项业务或交付物涉及的职责拆成决策、执行、评审、知会四类，逐一核对每类动作当前由谁承担、是否有明确的人。
四类动作的核对重点不同。决策动作看谁有权定方向、定取舍、定是否通过；执行动作看谁产出交付物；评审动作看谁在交付前把关质量与合规；知会动作看谁需要被同步、由谁负责同步。实践中空缺最常出现在评审与知会两类，因为这两类动作不直接产出可见成果，容易被默认为“大家都会看”。
识别过程中要区分三种相邻但性质不同的问题，避免用同一种办法处理：
- 角色空缺：某类动作在制度上就没有对应角色，或原承担者离开后无人接续，属于职责结构问题。
- 单任务无人负责：角色本身存在，只是某个具体任务没有指派负责人，属于任务分配问题，通过明确任务负责人即可解决。
- 人员技能不匹配：角色有人承担，但承担者能力不足以完成该动作，属于人员配置与培养问题，需要培训、调整或换人。
三类问题的处置路径不同：角色空缺要改职责结构，单任务问题要改任务分配，技能问题要改人员安排。把技能问题误判为角色空缺，会导致不断新增角色；把角色空缺误判为单任务问题，则同一类缺口会在下一个任务中重复出现。
识别完成后输出一份空缺清单，至少包含四列：动作、应有角色、当前承担者、缺口表现。缺口表现要写成可观察的事实，例如“需求评审结论无人签字，评审会后仍反复修改”“上线通知无人统一发出，下游团队靠口头打听”。这份清单是后续填写责任矩阵的输入。
用责任矩阵把职责落到角色
空缺清单回答“缺什么”，责任矩阵回答“归谁”。矩阵的行是业务环节或交付物，列是角色，交叉格标注该角色在该环节承担的责任类型。行按实际工作流排列，例如需求提出、方案设计、开发实现、测试验证、上线发布；列按团队真实角色设置，避免使用“相关方”“所有人”这类无法追责的列名。
填写时遵循三条规则，保证矩阵可用：
- 每个交叉格只标一类主要责任。同一格同时写决策和执行，遇到分歧时无法判断谁说了算。若一个角色确实既执行又评审，拆成两行或分两列表达。
- 每行至少有一个决策责任和一个执行责任。只有执行没有决策的行，意味着该环节的取舍无人负责，通常就是空缺所在。
- 评审与知会单独成格。不要用“参与”笼统带过，评审要写清评审对象与通过标准，知会要写清知会内容与知会对象。
对识别出的空缺格，给出三种处置之一，并写进矩阵：
| 处置方式 | 适用情形 | 矩阵中如何记录 |
|---|---|---|
| 指定承担角色 | 空缺动作必要，且团队内有合适角色可承接 | 填入角色名与责任类型，注明生效时间 |
| 拆分到多个角色 | 动作范围过大，单一角色难以独立完成 | 按子动作拆行，分别标注角色，明确衔接顺序 |
| 明确暂不设置 | 该动作当前价值有限，或成本明显高于收益 | 标注“暂不设置”，写明风险与复核时间 |
“暂不设置”是正式结论，需要书面说明风险，例如“暂不设独立安全评审角色，由技术负责人兼看，风险为合规检查可能滞后，三个月后复核”。这样处理比留空更可控，也便于后续追溯。
矩阵填写完成后，在团队内做一次逐行确认，重点确认三件事：每个角色是否认可自己的责任格，空缺处置是否有明确结论，是否存在同一动作被两个角色同时认领。确认后的矩阵即为角色分工的基准文件，后续人员变动时在矩阵上修订，而不是靠口头传达。矩阵落到协作工具中时，可借助 ONES 的角色权限与工作项流转，把矩阵中的责任类型对应到工作项的负责人、评审人和知会人字段，使分工在任务流转中可见。
补齐角色之间的交接接口
矩阵解决“谁负责”，交接解决“责任如何传递”。空缺补上后，责任最容易在角色边界处再次掉落：上游认为已交付，下游认为未收到，中间没有人确认。为每个跨角色交接定义四项内容，可以把这个缝隙堵住。
- 输入物：接手方需要拿到什么才能开始工作，例如需求说明、设计稿、测试报告、变更记录。
- 输出物：交出方在交接时实际提供的成果，需与输入物对应，避免“给了但不够用”。
- 交接时点：在流程的哪个节点交接，是评审通过后、版本冻结前，还是固定时间点。
- 确认方式：由谁确认接收，确认动作是签字、在系统中变更状态，还是在交接记录中回复确认。
交接未完成时要有明确的停留状态和催办角色。例如规定“输出物提交后 24 小时内未确认，由交出方发起催办；超过 48 小时未确认，升级至双方共同上级”。停留状态写清楚，交接就不会因为一方沉默而无限期悬置。
交接内容应写进矩阵备注或独立交接清单，避免只停留在口头约定。交接清单可按以下结构逐条填写：
| 交接编号 | 交出角色 | 接收角色 | 输入物/输出物 | 交接时点 | 确认人 | 未确认时的催办角色 |
|---|---|---|---|---|---|---|
| H-01 | 产品 | 研发 | 需求说明与验收标准 | 需求评审通过后 | 研发负责人 | 产品负责人 |
| H-02 | 研发 | 测试 | 可测版本与变更说明 | 版本提测时 | 测试负责人 | 研发负责人 |
| H-03 | 测试 | 运维 | 测试报告与上线清单 | 上线评审前 | 运维负责人 | 测试负责人 |
表中每一行对应一个真实的角色边界，交接时点与确认人必须具体到角色而非个人，人员变动时只需替换角色承担者，接口规则保持稳定。交接确认动作若在协作工具中完成，可把工作项状态变更作为确认凭据，减少“是否已交接”的争议。
设置代理与升级规则
矩阵和交接清单覆盖正常情况，代理与升级规则覆盖人员缺位。为关键角色指定第一代理人，并写明代理触发条件，例如休假、出差、临时调岗或连续两个工作日未响应。代理触发条件要可判断，避免“必要时由他人代理”这类无法执行的表述。
升级路径需要回答三个问题：多久未响应算异常、向谁升级、升级后由谁决策。可以按响应时长分层设置：
| 情形 | 触发条件 | 处理角色 | 决策归属 |
|---|---|---|---|
| 第一层 | 关键角色 1 个工作日未响应 | 第一代理人代为处理 | 代理人按原职责决策 |
| 第二层 | 2 个工作日仍未响应或代理人无法决策 | 升级至角色所属团队负责人 | 团队负责人决策并记录原因 |
| 第三层 | 涉及跨团队争议或资源冲突 | 升级至双方共同上级 | 共同上级裁定，结果回写矩阵备注 |
代理与正式任命要区分开。临时代理有明确起止时间，代理期间的决策需在交接记录中留痕；正式任命则通过修订矩阵完成，更新责任格与生效日期。代理长期化是常见风险：临时顶替超过约定周期后，原角色与代理人都不再清楚谁最终负责。处理办法是给代理设置复核节点，例如代理满一个月时由团队负责人决定转为正式任命或恢复原角色。
代理与升级规则表应包含：角色名称、第一代理人、代理触发条件、升级对象、升级时限、决策归属、复核节点。规则制定后需告知所有相关角色，并在矩阵或交接清单中引用，确保需要时能查到。
用一个真实任务验证空缺是否被覆盖
设计完成后，用一次真实任务走查检验机制是否有效。选取一个近期发生过的跨角色任务，最好是曾经出现过延误或返工的任务，按新矩阵逐环节回放：每个环节的责任人是谁、交接是否按清单完成、出现异常时是否按升级路径处理。
走查按以下步骤进行：
- 列出任务从发起到结束的全部环节，与矩阵行一一对应。
- 逐环节标注实际承担者，与矩阵中的应有角色比对，记录不一致之处。
- 检查每个跨角色交接点，核对输入物、输出物、交接时点与确认方式是否落实。
- 模拟一次人员缺位，检验代理触发与升级路径是否能在规定时限内启动。
- 汇总仍无人承接的环节、交接断点和代理失效点，形成修订项。
走查记录要写成可追溯的条目，例如“环节：上线评审；矩阵应有角色：运维负责人；实际承担者：空缺；缺口表现：上线前无人确认回滚方案；修订项：指定运维负责人为评审角色，回滚方案纳入上线清单”。记录中的每个修订项都要回到矩阵或交接清单中修改，并注明修订日期与修订人，形成一轮闭环。
走查暴露的问题通常集中在两类：一是矩阵中标注了角色但该角色并不知晓，说明告知环节缺失；二是交接清单定义了输入物但实际交付不完整，说明确认标准需要细化。两类问题都通过修订矩阵和清单解决，而不是通过增加会议解决。
验证环节若在协作工具中回放，可直接调取历史工作项的流转记录，对照矩阵检查每个环节的负责人、评审人和知会人是否与规则一致，使走查基于实际数据而非回忆。
完成检查：职责空缺处置的验收标准
本轮职责空缺处置是否可以收尾，用以下清单逐项核对。每项都应有可查证的产物或记录，口头确认不计入完成。
| 检查项 | 验收标准 | 对应产物 |
|---|---|---|
| 空缺识别 | 每个空缺动作都有明确承担角色，或书面说明暂不设置并注明风险与复核时间 | 空缺清单、矩阵处置列 |
| 责任归属 | 矩阵每行有决策与执行责任，每个交叉格只标一类主要责任，无留空格 | 角色责任矩阵 |
| 交接接口 | 关键交接均有输入物、输出物、交接时点与确认人，未确认时有催办角色 | 角色交接清单 |
| 代理与升级 | 关键角色有第一代理人与触发条件，升级路径写明时限、对象与决策归属 | 代理与升级规则表 |
| 告知到位 | 矩阵、交接清单与代理规则已告知所有相关角色，并有确认记录 | 告知记录或确认回复 |
| 真实验证 | 至少完成一次真实任务走查，暴露的问题已回写矩阵并注明修订日期 | 任务走查记录与矩阵修订项 |
核对时重点关注两个容易漏掉的点：一是“暂不设置”的空缺是否有复核时间，没有复核时间的暂缓会变成永久遗漏；二是代理规则是否只写在文档里而未告知代理人本人，代理人不知情时规则无法生效。
全部检查项通过后，矩阵、交接清单与代理规则作为团队角色分工的基准文件归档，后续人员变动、业务调整时在基准文件上修订并记录变更，职责空缺的处置就从一次性梳理转为可持续维护的机制。
常见问题
团队规模较小，是否也需要完整的责任矩阵和交接清单？
规模较小的团队可以简化形式，但不宜省略结论。矩阵可以只保留当前实际发生的业务环节和角色，交接清单只覆盖跨角色的关键节点，代理规则可以合并为一张简表。需要保留的是三件事：每个空缺动作有明确承担角色或书面暂不设置、关键交接有确认人、人员缺位时有可执行的代理与升级安排。团队扩大或业务环节增加时，在同一份矩阵上追加行与列即可，避免重新梳理。
空缺动作确实找不到合适角色承接，应该怎么处理？
先判断该动作是否必须由独立角色承担。可以拆分为多个子动作，由现有角色分别承接其中一部分，并在矩阵中写明衔接顺序；也可以由上一级角色兼任，但要在矩阵中注明兼任关系与复核时间。若该动作当前价值有限，可作出“暂不设置”的书面结论，写明风险与复核时间，例如三个月后重新评估。留空是最不可取的处理方式，因为留空意味着下次出现问题时仍无人负责。
代理人与原角色意见不一致时，以谁为准？
在代理触发条件成立期间，代理人按原职责行使决策权，决策结果记录在交接记录中，原角色返岗后如需调整，按正常变更流程处理。若事项超出代理人权限或涉及跨团队资源冲突，按升级路径提交至角色所属团队负责人或双方共同上级裁定。规则中应提前写明代理人的决策范围，范围之外的事项直接进入升级，避免在具体事项上临时争论谁说了算。
矩阵和交接清单制定后，如何避免变成一份没人看的文档？
关键是让规则出现在日常工作的必经环节。矩阵中的责任类型对应到工作项的负责人、评审人和知会人字段，交接确认以工作项状态变更作为凭据，这样每次任务流转都会实际用到规则。同时把矩阵与清单放在团队共同可查的位置，人员变动时在基准文件上修订并记录变更日期与修订人。定期用一次真实任务回放检查规则是否仍与实际一致，比单独组织规则宣讲更能维持文档的有效性。
一次走查没有发现明显问题，是否可以直接收尾？
走查未发现问题时，先确认走查覆盖的范围是否完整：是否覆盖了全部跨角色交接点，是否模拟了人员缺位情形，是否核对了实际承担者与矩阵应有角色的一致性。若覆盖完整且结果一致，可按验收清单收尾。若只回放了顺利完成的环节，建议另选一个曾出现延误或返工的任务再走查一次，这类任务更容易暴露交接断点与代理失效点。
