项目问题挂在已离职或调岗的同事名下，常见结果是状态长期停在“处理中”、催促无人回应、跨团队协调断线。转派解决“谁来接”，升级解决“接不住时找谁决策”，两步需要衔接使用。本文按症状识别、原因排查、转派、升级、验证预防的顺序，给出可执行的处置路径和记录要求。
要点总览（TL;DR）
- 责任人缺位或调岗时，先对照症状清单判断问题是否已停滞：状态长期无更新、责任人字段仍是旧人、催促无人回应、跨团队协调断线。
- 排查原因要拿证据：先确认原责任人是否确实无法履职，再查记录是否失真、团队有无转派规则、问题信息是否足够接手人判断。
- 转派按“定接手人—改记录—通知相关方”执行，接手人优先由原责任人所在团队负责人指定，记录需写明转派原因、原责任人与新责任人、转派时间和预期处理节点。
- 转派后超过约定时限无进展、影响关键路径、跨团队协调无果或权限超出团队时，按团队负责人—项目经理—项目集或管理层逐级升级，升级时携带影响范围、已尝试处置和当前阻塞点。
- 转派升级后按检查节点验证问题是否真正恢复推进，并通过人员变动时批量核对名下问题、固化问题模板中的转派升级规则来减少责任人真空。
责任人缺位或调岗时，问题会表现成哪些症状
先判断当前问题是否属于本文处理的场景：项目推进类问题因责任人无法履职而停滞。典型症状可以从问题记录和协作行为两方面对照。
- 状态停滞：问题长期停留在“待处理”或“处理中”，最近一次更新距今已超过团队约定的响应时限，且没有说明原因的备注。
- 责任人信息失真：原责任人已离职、调岗到其他团队或长期不在岗，问题记录中的责任人字段仍是旧人。
- 催促无回应：问题提出人多次催促，原责任人不回复，也没有其他人主动接手。
- 协调断线：问题影响关键路径或涉及多个团队，原本由责任人牵头的协调动作停摆，相关方不知道下一步找谁。
需要划清边界：产品缺陷的修复流转归缺陷管理，服务中断的响应归服务事件管理，这两类有独立的流程和时限要求。本文讨论的是项目推进中阻碍交付、需要协调资源或决策的问题，例如需求口径未定、依赖方交付延迟、环境或权限未就绪。若问题本质是代码缺陷或线上故障，应转入对应流程，不套用本文的转派升级路径。
症状清单的作用是触发排查，不能直接作为结论。看到“无人处理”就认定原责任人不负责，容易误判；下一步需要用证据区分原因。
先判断原因：是责任人缺位，还是流程本身没有接手规则
问题停滞可能来自个人缺位，也可能来自流程缺失。两类原因的处置方式不同：前者要转派，后者要先补规则。建议按以下顺序排查，每一步都拿到证据再进入下一步。
| 原因假设 | 验证证据 | 排查顺序 |
|---|---|---|
| 原责任人已无法履职 | 人事或团队负责人确认其离职、调岗、长期请假状态；查看其近期在其他问题上的活跃记录 | 第一步 |
| 问题记录未随人员变动更新 | 责任人字段仍是旧人，但实际已有同事在处理，或问题备注中有口头交接痕迹 | 第二步 |
| 团队缺少转派规则 | 询问团队负责人和项目经理，确认是否存在“责任人缺位由谁指定接手人”的书面约定；查看历史问题是否有转派记录 | 第三步 |
| 问题信息不足，接手人无法判断 | 问题描述缺少影响范围、复现条件、期望结果；潜在接手人表示“看不懂要做什么” | 第四步 |
排查时先确认人的状态，再确认记录是否失真，最后看规则和信息质量。这个顺序的理由是：如果原责任人实际仍在岗，只是暂时未响应，直接转派会打乱原有分工；如果记录已失真，实际有人处理，转派反而造成重复。
有一个停止点需要明确：在未确认接手人之前，不要直接关闭、删除或改派问题给了无处置权限的人。关闭会让问题从视野中消失，删除会丢失追责和复盘依据。若问题确实已无处理必要，也应先记录关闭原因和确认人，再执行关闭。
排查结论要落到书面：是个人缺位、记录滞后、规则缺失，还是信息不足。不同结论对应不同动作——个人缺位走转派，规则缺失先由项目经理或团队负责人明确接手规则，信息不足先补充问题描述再转派。
转派怎么做：接手人、权限与记录三步走
确认需要转派后，按“定接手人—改记录—通知相关方”的顺序执行，每一步都有明确的角色和产物。
第一步：确认问题状态与影响范围。由问题提出人或项目经理核对问题当前是否仍在推进、影响哪些交付节点、是否涉及跨团队依赖。影响关键路径的问题，转派动作要与升级同步启动，不能等转派完成后再评估。
第二步：确定接手人。优先由原责任人所在团队的负责人指定接手人，因为该负责人最清楚团队内谁具备处置权限和当前负荷。跨团队问题由项目经理协调，避免两个团队互相等待。接手人应具备处置该问题所需的权限，例如能调动相关资源、能对需求口径做出判断；仅有名义责任人而无权限，问题会再次停滞。
第三步：更新记录并通知。转派时同步完成以下记录字段，缺一项都会影响后续追溯：
- 责任人字段改为新责任人；
- 转派原因，写明原责任人缺位、调岗或记录滞后等具体情形；
- 原责任人与新责任人；
- 转派时间与转派操作人；
- 预期处理时间或下一个检查节点。
记录更新后，通知问题提出人和相关协作方，说明新责任人是谁、预计何时给出进展。通知的目的不是形式告知，而是让提出人知道后续找谁跟进，让协作方知道协调对象已变更。
转派记录本身就是追责和复盘的依据。后续若问题再次停滞，可以据此判断是接手人未履职，还是转派时未授予足够权限，或是问题信息本身不完整。
在问题记录承载转派动作时，工具的作用是让字段变更和原因说明留痕。以 ONES 的问题管理为例，问题工作项可以记录责任人、状态和处理记录，转派时更新责任人并补充说明，后续查看问题历史即可还原交接过程。具体字段配置以团队实际使用为准。
升级怎么做：什么条件下升级、升到哪一级
转派解决接手人问题，升级解决权限和资源问题。满足以下任一条件即应升级，不必等到问题彻底失控。
| 升级触发条件 | 建议升级对象 | 升级时携带的信息 |
|---|---|---|
| 转派后超过约定时限仍无进展 | 团队负责人 | 问题描述、转派记录、当前阻塞点 |
| 问题影响关键路径或里程碑 | 项目经理，必要时到项目集负责人 | 影响范围、受影响的交付节点、已尝试的处置 |
| 跨团队协调无果 | 项目经理或双方团队负责人的共同上级 | 各团队立场、分歧点、需要谁做决策 |
| 所需资源或决策权限超出团队范围 | 项目集或管理层 | 资源缺口、决策事项、期望答复时间 |
升级路径按组织层级逐级上报：团队负责人—项目经理—项目集或管理层。逐级的意义在于每一级都有机会在自身权限内解决，避免所有问题直接涌向高层。紧急且影响关键路径的问题可以越级，但应在升级记录中说明越级理由。
升级时携带的信息要能让接收方直接判断：问题是什么、影响多大、已经做过哪些处置、现在卡在哪里、需要对方做什么决定。缺少这些信息，升级容易变成转述情绪而非推动决策。
升级记录应包含升级时间、升级对象、升级原因和结论。记录的作用有两个：一是让后续接手的人知道问题已经过哪些层级；二是复盘时能看出哪类问题频繁升级、卡在哪一级。
需要区分升级与追责。升级的首要目标是让问题获得决策和资源，先解决问题，再在复盘阶段依据记录界定责任。把升级当作追责手段，会导致团队隐瞒问题、延迟上报。
如何验证恢复并防止再次出现责任人真空
转派和升级完成后，需要验证问题是否真正恢复推进，而不是换了一个名字继续停滞。
恢复验证清单：
- 责任人字段已更新为新接手人，且新责任人确认接受；
- 问题记录中出现新的处理进展，而非仅有转派操作；
- 问题提出人确认已知晓新责任人和预期处理时间；
- 升级事项已有结论：决策已做出、资源已到位或协调结果已落地；
- 影响关键路径的问题，交付计划已相应调整并通知相关方。
验证的时间点建议设在转派时约定的第一个检查节点。到点无进展，直接进入升级条件判断，不再重复等待。
复发预防措施：
- 人员变动时批量检查其名下问题。离职或调岗生效前，由团队负责人列出该成员名下的所有未关闭问题，逐条指定接手人或确认关闭理由。
- 设置责任人离岗提醒。在人事流程或项目管理流程中加入检查点，人员状态变更时触发问题清单核对。
- 在问题模板中固化转派与升级规则。新建问题时即包含影响范围、期望结果、升级条件等字段，减少因信息不足导致的接手困难。
- 定期复盘转派升级记录。按季度或按项目阶段统计转派次数、升级层级和高频缺位环节，判断是人员流动集中，还是某类问题的责任划分本身不清。
追责以记录为依据，并区分流程缺失与个人失职。若转派时未明确权限、未通知相关方、未设定检查节点，问题再次停滞属于流程问题，应优先修补规则；若记录完整、权限明确而接手人仍未履职，才属于个人责任范畴。这个区分决定了改进动作是补流程还是做沟通，避免把所有停滞都归为个人态度问题。
当团队把问题记录作为统一载体时，转派原因、责任人变更、升级结论都留在同一条问题历史中，人员变动时的批量核对和事后复盘都有据可查。ONES 的问题管理可以承载问题工作项的状态、责任人和处理记录，团队可据此建立转派与升级的留痕习惯；具体流程配置需结合团队现有的问题分级和汇报关系确定。
常见问题
原责任人只是暂时未响应，还没确认是否调岗，可以先转派吗？
建议先核实状态再决定。如果原责任人仍在岗、只是短期未响应，直接转派会打乱原有分工，也可能造成两人重复处理同一问题。可以先通过团队负责人确认其当前状态和预计返岗时间，并设置一个明确的检查节点。到点仍无响应，再按转派流程处理，同时在记录中写明“暂时未响应”这一转派原因，便于后续追溯。
跨团队的问题，两个团队负责人都不愿指定接手人，怎么办？
这类情况已经超出单个团队的处置范围，应由项目经理介入协调，明确该问题归属哪个团队、由谁承担处置责任。协调时把问题的影响范围、受影响的交付节点和双方分歧点摆到桌面上，让协调有具体对象。若项目经理协调后仍无结论，按升级路径上报到双方团队负责人的共同上级，并在升级记录中写明各团队立场和需要谁做决策。
转派后新责任人迟迟不处理，能直接追责吗？
追责前先核对转派记录是否完整：接手人是否具备处置权限、是否收到明确通知、是否约定了检查节点和预期处理时间。如果这些条件在转派时没有落实，问题再次停滞更可能是流程问题，应优先补齐规则；如果记录完整、权限明确而新责任人仍未履职，才属于个人责任范畴。这个区分决定了改进动作是补流程还是做沟通。
问题已经升级到管理层，还需要继续保留原责任人和转派记录吗？
需要保留。升级不替代转派记录，两者共同构成完整的问题历史：转派记录说明问题经过谁手、为何换人，升级记录说明卡在哪一级、得到什么结论。后续复盘时，这些记录能帮助判断是人员流动集中、责任划分不清，还是某类问题本身需要更高层级的决策机制。关闭问题时也应保留这些记录，作为追责和流程改进的依据。
团队规模小、没有专职项目经理，转派和升级规则怎么定？
可以由团队负责人承担指定接手人和协调升级的职责，规则不必复杂，但要书面化：明确责任人缺位时由谁指定接手人、转派需要记录哪些字段、什么条件下上报到更高层级。规则写清楚后，人员变动时按规则执行即可，减少临时找人、口头交接带来的信息丢失。团队规模扩大或问题复杂度上升后，再考虑细分升级层级。
