职责划分已经发布，跨角色协作却仍然推诿，原因通常要从三处找：角色边界存在重叠或空白，同一件事多人可管或无人认领；角色之间的交接接口没有定义清楚，交付物、时限和验收条件缺失；分工规则脱离实际流程，角色缺少权限、时间或信息去履行。诊断时先把推诿还原为具体事项，再逐项核对边界、接口和可执行性，用证据区分假设，最后针对根因补规则并验证效果。
要点总览（TL;DR）
- 职责划分发布后仍推诿，先别急着改文档：把推诿还原为具体事项清单，记录涉及角色、环节和发生次数，才能判断问题出在哪里。
- 三类原因假设各有证据形态：边界重叠看职责文档中的重复段落，边界空白看关键动作缺失；接口缺失看交接记录中对交付物、时点和验收标准的争议；规则不可执行看权限、排期和信息渠道的核查结果。
- 排查按顺序走：先对照职责文档与具体事项找重叠和空白，再查跨角色交接记录，最后核查执行条件，全程区分已证实与待验证。
- 处置按根因分开：边界问题明确唯一主责角色并写清协作方式；接口问题补齐交付物、时限、验收标准和异常升级路径；可执行性问题调整权限、排期或规则，先小范围试行。
- 修正效果用同类事项的认领速度、转交次数和悬空时长做前后对比，并在例行评审中持续检查接口执行情况，职责变更时同步更新接口说明。
推诿发生在哪些环节：先界定症状与范围
“推诿”是一个笼统的感受，直接讨论原因容易各说各话。第一步是把它还原成可核查的事项清单：哪件事、涉及哪两个或几个角色、卡在哪个环节、发生过几次。清单建立起来，诊断范围才清晰，后续讨论也有共同的事实基础。
推诿在协作中通常有三种可观察的表现。第一种是事项悬空：一项工作发布后没有人主动认领，停留在群里、邮件里或会议纪要里。第二种是反复转交：事项在角色之间来回传递，每次转交都附带“这块应该由你们先确认”之类的说明，但没有人推进实质动作。第三种是会上认领会后不动：会上口头确认了归属，会后没有产出、没有进展，下一次会议又重新讨论归属。三种表现的根因可能不同，记录时要分开标注。
记录清单建议包含以下字段，便于后续统计和对照：
- 事项名称与所属流程环节，例如“客户需求变更确认”“上线前配置核查”；
- 涉及的角色对，例如“产品经理—研发负责人”“售前—交付经理”；
- 推诿表现类型：悬空、反复转交、认领后不动；
- 发生时间与发生次数，同一事项多次出现要合并计数；
- 当前状态：已解决、仍悬空、临时绕过。
记录时还要区分相邻问题。单任务负责人的指派是否明确、人员技能是否匹配、资源是否充足，都会影响协作顺畅度，但它们属于任务分派和资源配置问题，与角色职责划分是两回事。把这类问题混进推诿清单，会让诊断失焦。清单只保留与“角色该不该管、怎么交接”直接相关的事项，其余问题另行处理。
三类原因假设：边界重叠、接口缺失、规则不可执行
症状清单建立后，可以提出三类原因假设。假设的作用是指导取证，每类假设都需要特定形态的证据才能成立，不能凭印象下结论。
| 原因假设 | 典型表现 | 成立所需证据 | 排除依据 |
|---|---|---|---|
| 边界重叠或空白 | 同一交付物出现在多个角色描述中；关键动作在职责文档里找不到归属 | 职责文档原文对照具体事项，指出重叠段落或缺失动作 | 文档对争议事项有唯一归属，且相关角色均知晓 |
| 跨角色接口缺失 | 交接时说不清该交什么、什么时候交、交到什么程度算完成 | 交接记录、邮件、会议纪要中反复出现对交付物和时点的争议 | 接口已有书面定义，争议来自执行偏差而非定义缺失 |
| 规则不可执行 | 角色被写入职责，但没有相应权限、排期或信息渠道 | 权限配置记录、排期表、信息获取路径的核查结果 | 角色具备履行条件，未履行属于意愿或能力问题 |
边界重叠与边界空白经常同时存在。重叠的典型信号是同一份交付物在多个角色描述中都能找到依据，双方都能说“这是我们的职责范围”，于是谁都可以等对方先动。空白的典型信号是某个关键动作在职责文档中完全没有出现，事项推进到这一步就停住。两类问题在文档上的证据形态不同：重叠看重复，空白看缺失。
接口缺失关注的是角色之间的连接处。职责文档通常写清了每个角色“负责什么”，却很少写清“交给谁、交什么、何时交、对方如何验收”。当交接条件模糊时，接收方可以以“材料不全”退回，交付方可以以“已经发出”回应，推诿就在这个缝隙里反复发生。接口假设成立需要交接记录支撑，而不是仅凭一次争执。
规则不可执行指向分工与现实条件的冲突。角色被赋予职责，却没有审批权限、没有排进排期、拿不到必要的信息，履行就无从谈起。这类假设的验证要落到具体条件上：查权限配置、查排期占用、查信息是否可达。需要注意的是，条件具备而协作仍不畅，说明原因在别处，不能继续用“不可执行”解释。
按顺序排查：用证据排除假设
三类假设不宜同时铺开讨论，按顺序排查更高效，也更容易留下可复核的记录。推荐顺序是：先查职责文档与具体事项的对应关系，再查跨角色交接记录，最后查执行条件。
第一步，取来现行职责文档，逐条对照症状清单中的事项。对每个争议事项回答两个问题：文档中是否有明确的归属角色？是否同时有多个角色可以主张归属？把重叠段落和缺失动作原文摘录下来，标注文档版本和条款位置。这一步的产物是“文档—事项对照表”，它直接支撑或排除边界假设。
第二步，调取争议事项的交接记录，包括邮件、即时消息、会议纪要和工单流转记录。重点看三件事：交付物是否写明、交接时点是否约定、验收标准是否明确。如果记录显示双方对“交什么、何时交、怎样算完成”反复争执，接口缺失假设成立的可能性较高；如果接口约定清楚、争议集中在执行拖延，则应转向其他假设。
第三步，核查执行条件。针对被写入职责的角色，确认其是否具备完成动作所需的权限、排期和信息渠道。核查要具体到操作层面，例如某项审批是否需要该角色发起、相关工作是否占用了其可用工时、所需数据是否在其可见范围内。核查结果同样以记录形式保留。
整个排查过程要区分“已证实”和“待验证”。文档原文、交接记录、权限配置属于可直接核对的证据；角色主观感受、个别冲突事件只能作为线索。排查结束时形成初步根因判断：以哪类原因为主、是否多类并存、哪些结论仍需补充证据。多类原因并存时，按影响事项数量和发生频次排序，优先处理高频事项对应的根因。
针对根因的处置动作
根因不同，处置动作也不同。共同的原则是先小范围修正、观察效果，再决定是否全面推行；修改职责文档前保留旧版本，确保口径可追溯。
边界问题的处置核心是建立唯一归属。对每个争议交付物，明确一个主责角色，其他相关角色写成协作角色，并写清协作方式：提供什么输入、在哪个节点参与、以什么形式反馈。主责角色对结果负责，协作角色对输入质量负责，两者分开表述，避免再次出现“都可以管”的模糊地带。对文档中完全缺失的关键动作，补充归属条款，同时检查该动作上下游是否因此产生新的接口需求。
接口问题的处置是补齐交接要素。每个跨角色交接点至少写清四项：交付物清单、交接时点、验收标准、异常升级路径。验收标准要可判断，例如“包含字段完整的配置清单并经对方确认”，避免“及时提供”这类无法核验的表述。异常升级路径写明交接受阻时向谁升级、在多长时间内升级，让卡住的事项有出口，而不是停留在双方互相等待。
可执行性问题的处置是调整条件。权限不足的，走权限变更流程；排期冲突的，与相关角色协商工时安排或调整节点；信息不可达的，打通信息获取渠道。调整后先在小范围试行，例如选择一个项目或一条业务线，观察一至两个协作周期。试行期间保留原规则作为对照，出现新问题及时记录，避免一次性全面改动带来新的混乱。
处置动作落地时，职责文档和接口说明需要同步更新，并让相关角色确认新版本。文档修订记录中注明修改原因、生效范围和生效时间，旧版本归档保留。这样后续再出现争议，可以回溯是规则问题还是执行问题。
在文档与事项流转的管理上，ONES 可以承载职责说明的版本留存与事项流转记录：修订后的职责文档在系统中保留历史版本，争议事项的认领、转交和处理过程留有记录，例行评审时可以直接调取这些记录核对接口执行情况。这类管理动作适合在处置和验证阶段使用，帮助团队把规则修正与实际执行对应起来。
验证恢复与防止复发
修正是否有效，要用同类事项的前后对比来判断，而不是凭一次会议上的表态。建议选取症状清单中频次最高的几类事项，在修正前后各观察一个完整协作周期，对比三项指标：认领速度，即事项发布到有人明确认领的时长；转交次数，即事项在角色之间传递的次数；悬空时长，即事项处于无人推进状态的总时长。三项指标同时改善，才能说明推诿确实减少；只有认领速度变快而转交次数未降，可能只是把推诿推迟到了交接环节。
验证之外，还需要建立持续检查机制。在例行项目评审或协作复盘中加入接口执行情况检查：上一周期发生的跨角色交接是否按约定的交付物和时点完成，异常升级路径是否被使用、是否有效。检查发现的问题记入同一份清单，与最初的症状清单衔接，形成连续记录。
防止复发的关键是让职责文档与流程保持同步。职责变更、流程调整、角色增减时，同步更新对应的接口说明，并在修订记录中注明变更内容。定期核对文档与实际执行是否一致，发现文档写了但实际未执行、或实际在做但文档未覆盖的情况，及时修正。文档与流程脱节越久，下一次推诿发生时排查成本越高。把版本留存、事项记录和例行检查结合起来，团队才能在推诿再次出现时快速定位是边界、接口还是执行条件的问题。
常见问题
职责文档写得很细，为什么推诿还是反复出现？
文档详细不等于规则可执行。常见的情况是文档写清了每个角色“负责什么”，却没有写清角色之间“交给谁、交什么、何时交、怎样算完成”。交接条件模糊时，交付方可以说“已经发出”，接收方可以说“材料不全”，事项就在这个缝隙里来回传递。另一种情况是角色被写入职责，却没有相应权限、排期或信息渠道，履行无从谈起。诊断时把争议事项的交接记录和执行条件调出来核对，比反复修订职责描述更有效。
边界重叠和边界空白，排查时怎么区分？
两者在职责文档上的证据形态不同。重叠看重复：同一份交付物在多个角色描述中都能找到依据，双方都能主张归属，于是谁都可以等对方先动。空白看缺失：某个关键动作在文档中完全没有出现，事项推进到这一步就停住。排查时逐条对照症状清单中的争议事项，把重叠段落和缺失动作的原文摘录下来，标注文档版本和条款位置。两类问题经常同时存在，摘录时分开标注，处置时分别处理。
多类原因同时存在时，应该先处理哪一类？
按影响事项数量和发生频次排序，优先处理高频事项对应的根因。例如某类交接争议每周都出现，而边界空白只影响个别低频流程，就先修接口。处置时先小范围修正、观察一至两个协作周期，再决定是否全面推行。试行期间保留原规则作为对照，出现新问题及时记录。多类原因并存时不宜一次性全面改动，否则难以判断哪项修正起了作用。
修正职责文档后，怎样确认推诿真的减少了？
用同类事项的前后对比来判断，而不是凭一次会议上的表态。选取症状清单中频次最高的几类事项，在修正前后各观察一个完整协作周期，对比三项指标：认领速度，即事项发布到有人明确认领的时长；转交次数，即事项在角色之间传递的次数；悬空时长，即事项处于无人推进状态的总时长。三项同时改善才能说明推诿减少；只有认领速度变快而转交次数未降，可能只是把推诿推迟到了交接环节。
职责变更频繁的团队，怎样避免文档与流程脱节？
关键是让职责文档与接口说明同步更新。职责变更、流程调整、角色增减时，同步修改对应的接口说明，并在修订记录中注明变更内容、生效范围和生效时间，旧版本归档保留。定期核对文档与实际执行是否一致，发现文档写了但实际未执行、或实际在做但文档未覆盖的情况，及时修正。文档与流程脱节越久，下一次推诿发生时排查成本越高。在 ONES 中，修订后的职责文档可以保留历史版本，争议事项的认领、转交和处理过程留有记录，例行评审时可直接调取核对。
