职责划分已经发布，跨角色协作却还是出现推诿，问题往往不在职责文本本身。更常见的情况是：角色边界在具体交付物上重叠或留白，角色之间的交接接口没有定义，或者分工规则在现有流程与权限下无法执行。本文给出一套排查顺序，帮助你把笼统的“推诿”转成可核对的事件与证据，再定位到具体原因。排查中形成的交付物归属表、交接记录和修正事项，可以放在工作项与文档中承载，ONES 也能承担这部分协作信息的记录与流转。
要点总览（TL;DR）
- 职责已发布仍推诿，先别改文档：把推诿转成事件清单，记录角色对、交付物、卡点位置（交接前/中/后）与发生时点，收窄排查范围。
- 三类原因假设各有证据：边界重叠或留白看交付物归属表是否重复认领或无人认领；接口缺失看交接记录中交付内容、完成标准、交接时点、确认方式是否写明；规则不可执行看真实任务走查中卡在审批、系统权限还是排期节奏。
- 排查按五步推进：整理事件清单、核对交付物归属、抽查交接记录、走查真实任务、按证据归类并形成修正清单；证据不足只标待验证，不写成结论。
- 修正后用同类推诿次数、交接退回率、无人认领等待时长复测，前后使用同一口径；把交付物归属与交接接口固化为职责文档固定字段，并设定期复核时点。
- 修改职责文档前先备份现行版本并明确生效时间，排查期间尽量不改文档，避免前后证据对不上。
推诿发生在哪些环节：先界定症状与范围
排查的第一步是把“推诿”从感受变成事件。推诿在协作中通常有四种可观察的表现：任务无人认领，在待办列表里停留多日；交接被退回，上游认为已交付、下游认为不完整；评审意见互相指向对方，双方都认为该由对方先改；决策等待无人拍板，事项卡在“等确认”状态。把这些表现对应到具体事件，才能判断问题出在哪个角色对、哪个交付物、哪个时点。
建议按“角色对—交付物—卡点位置”三个字段记录近几次推诿事件。卡点位置分为交接前、交接中、交接后：交接前卡住，多半是任务归属或启动条件不清；交接中卡住，多半是输入输出标准不一致；交接后卡住，多半是验收或后续处理责任不明。记录时标注发生时点，便于后续判断是偶发还是高频。
记录过程中要区分问题类型。单任务由谁负责、任务如何指派，属于任务分配与责任管理的问题；人员能力与任务要求不匹配，属于资源技能与匹配管理的问题。这两类问题会表现为推诿，但排查方法不同，本文不展开。本次排查范围应明确为：涉及哪几个角色、哪一类协作流程、哪个时间窗口内的推诿事件。范围收窄后，证据收集才有边界。
本节的交付物是一份推诿事件清单，字段包括：事件编号、涉及角色对、交付物名称、卡点位置（交接前/中/后）、发生时点、当时的表现描述。清单不必追求完整，覆盖近一两个月的典型事件即可，重点是事件之间能相互比对。
三类原因假设与各自的排除证据
拿到事件清单后，可以提出三类原因假设。每类假设都需要对应的证据来支持或排除，证据不足时只能标记为待验证，不能直接写成结论。
| 原因假设 | 典型表现 | 验证证据 | 排除方法 |
|---|---|---|---|
| 角色边界重叠或留白 | 同一交付物两个角色都认为对方负责，或都认为自己只是配合 | 交付物归属表比对结果：同一交付物是否被两个角色同时认领，或都未认领 | 逐项核对归属表，重叠项与留白项即为证据；若所有交付物归属唯一且无空白，可排除该假设 |
| 交接接口缺失 | 交接被退回，双方对“交付到什么程度算完成”理解不同 | 交接记录：输入输出内容、交接时点、验收标准是否写明 | 抽取若干次交接记录，检查关键字段是否缺失；字段齐全且双方理解一致，可排除该假设 |
| 分工规则不可执行 | 规则写明由某角色审批或处理，但该角色没有对应权限，或排期上根本来不及 | 一次真实任务走查记录：规则在执行中卡在哪个审批、权限或时间节点 | 走查中规则能顺利执行，可排除该假设；卡点集中在权限或节奏冲突，则假设成立 |
三类假设可能同时成立，排查时不必强求只归一类。重要的是每类结论背后都有可复查的证据：归属表的比对结果、交接记录的字段检查、走查记录中的卡点描述。证据只能支持“疑似”，就标记为待验证，并在修正清单中安排补充取证。
需要提醒的是，职责文档写得清楚，不等于执行层面清楚。文档描述的是角色职责，交付物归属表描述的是具体产出由谁负责，交接记录描述的是角色之间如何传递。三者缺一，推诿就有空间。排查时把这三层分开看，比笼统讨论“职责清不清晰”更容易找到落点。
按顺序排查：从事件到原因的操作步骤
排查按以下五步推进，每步都有明确的动作和产出，前一步的产出是后一步的输入。
第一步：整理推诿事件清单。把 S1 中记录的事件按角色对和交付物归类，标记高频角色对与高频交付物。高频项是后续核对的重点，低频偶发事件可以暂放。完成标志是清单中每起事件都有角色对、交付物和卡点位置。
第二步：用交付物归属表逐项核对。为排查范围内的每个交付物列出“主责角色、配合角色、验收角色”。核对时重点看两类情况：同一交付物出现两个主责角色，属于重叠；交付物没有主责角色，属于留白。重叠项和留白项直接对应事件清单中的高频交付物，就形成了边界问题的证据。
第三步：抽取若干次交接记录，检查接口字段。每次交接至少应包含：交付内容、完成标准、交接时点、接收方确认方式。字段缺失的交接，退回概率明显更高。把缺失字段与事件清单中的“交接中”卡点对照，可以判断接口缺失是否为主要原因。
第四步：选一个真实任务做走查。挑一个近期发生过推诿、且流程完整的任务，从发起到关闭逐步走一遍，记录规则在哪个节点卡住：是审批权限不在规则指定的角色手里，是系统权限打不开对应操作，还是排期节奏让规则要求的确认时点无法满足。走查记录是判断“规则不可执行”的直接证据。
第五步：按证据归类原因，形成修正清单。把前三步的证据分别归入三类假设，标注成立、排除或待验证。修正清单按“问题—证据—修正动作—责任角色—生效时间”组织，优先处理证据充分且影响高频交付物的项。
修改职责文档前要先备份现行版本，明确本次改动范围和生效时间。排查期间尽量不改文档，避免边排查边改导致前后证据对不上；确需修改的，记录修改时点，后续比对时以修改前的版本为准。
排查过程中产生的归属表、交接记录和修正清单，如果散落在个人表格和聊天记录里，复核时很难对齐。可以把交付物归属做成工作项字段，把交接记录挂在对应工作项下，修正事项作为独立工作项跟踪状态，让角色职责、协作记录和修正进度在同一处可查。ONES 的工作项与文档可以承载这类信息，具体配置按团队现有流程设定。
修正后如何验证恢复并防止复发
修正动作落地后，需要用指标确认推诿是否真正缓解。建议观察三类指标：同类推诿事件在观察窗口内的发生次数，与修正前同一窗口对比；交接退回率，即被退回的交接次数占交接总次数的比例；任务无人认领的等待时长，从任务创建到有人认领的时间。指标口径由团队按自身流程定义，关键是修正前后使用同一口径。
复测时使用同一批交付物和角色对，逐项对比修正前后的卡点变化。原来重叠的交付物是否已明确唯一主责，原来缺失的交接字段是否已补齐并被实际使用，原来卡在权限上的节点是否已调整。复测结果与修正清单逐条对应，才能判断哪项修正起了作用、哪项还需要补充。
防止复发要把排查成果固化下来。交付物归属和交接接口应作为职责文档的固定字段，职责变更时同步更新归属表和交接标准，避免文档更新而协作规则滞后。设置定期复核时点，比如每季度复核一次高频交付物的归属与交接记录，把新出现的推诿事件回填到事件清单，持续观察是否出现新的重叠或留白。修正清单中的待验证项也要在复核时补充证据，避免长期悬置。
常见问题
职责文档写得很细，为什么协作中还是会出现推诿？
职责文档描述的是角色职责，而协作中的推诿往往发生在更具体的层面：同一交付物由谁主责、角色之间按什么标准交接、规则在现有审批权限和排期下能否执行。文档写得细，但这三层没有对应内容时，推诿仍有空间。排查时把职责文本、交付物归属表、交接记录分开核对，比反复讨论“职责清不清晰”更容易找到落点。
三类原因假设同时成立时，修正应该先做哪一类？
优先处理证据充分且影响高频交付物的项。通常先修正交付物归属的重叠与留白，因为它直接决定谁对结果负责；再补齐交接接口字段，让交接有可核对的完成标准；规则不可执行的问题涉及审批权限或排期调整，协调成本较高，可放在前两类修正落地后推进。若走查发现规则卡点直接导致高频推诿，也可以提前处理，判断依据是证据强度与影响范围，而非固定顺序。
排查期间可以同步修改职责文档吗？
建议尽量不改。排查依赖修正前的归属表、交接记录和走查结果做比对，边排查边改会让前后证据对不上。确需修改的，先备份现行版本，记录修改时点和改动范围，后续比对以修改前版本为准。修正清单中的改动统一安排在排查结论形成后执行，并明确生效时间，让复测有清晰的基线。
团队规模小、角色经常一人兼多职，这套排查还适用吗？
适用，但核对重点不同。一人兼多职时，交付物归属表容易出现同一人既是主责又是验收，边界重叠表现为自我确认而非角色冲突。排查时可重点看交接环节：兼任角色之间的交接是否被省略，完成标准是否只存在于个人判断中。事件清单中标注实际执行人而非岗位名称，能更准确地暴露卡点。
修正后观察多久才能判断推诿问题已缓解？
观察窗口应与推诿事件的发生频率匹配。高频事件可用两到四周的窗口对比修正前后的次数与交接退回率；低频事件需要更长窗口，或改用同类交付物的交接质量作为替代观察对象。关键是修正前后使用同一口径、同一批交付物与角色对。窗口结束时若指标未改善，回到修正清单检查对应项是否真正落地，而不是直接扩大改动范围。
