项目问题长期停在“待处理”，原责任人已调岗或联系不上，是项目推进中常见的异常。处理这类情况，先确认问题当前状态和影响范围，再按“临时接管—正式转派—按级别升级—结果验证”的顺序推进，并把责任人和交接记录同步到问题单上。本文只讨论项目推进障碍类问题的责任人异常，产品缺陷和服务中断另有对应流程。
要点总览（TL;DR）
- 先看问题单上的可观察痕迹：长期停在待处理、交接只有一句话、多次催办无回复、位于关键路径或临近里程碑，出现任意两项就启动处置。
- 把“没人处理”拆成假设再验证：人员离岗未交接、权限不足、归属不清、升级路径缺失、优先级被低估，先查问题单状态，再查责任人在岗情况，最后查流程规则。
- 处置按临时接管、正式转派、按影响与时限升级、追责沟通四步推进，临时接管设期限，正式转派要让接手人仅凭问题单就能继续推进。
- 升级以事实材料为凭据，一级到项目负责人，二级到项目指导委员会或职能负责人，跨部门协调和资源调整是二级的典型触发条件。
- 转派后一到两个处理周期内核验责任人、推进节奏、遗留事项和关键路径，并用交接清单、责任人备份和超时提醒减少同类异常复发。
责任人缺位或调岗时，问题会呈现哪些症状
判断是否需要启动转派升级，看的是问题单上的可观察痕迹，而不是对某个人工作态度的印象。以下症状出现任意两项，就应当进入处置流程。
| 观察维度 | 典型表现 | 说明 |
|---|---|---|
| 责任人状态 | 问题单长期停留在“待处理”，无责任人，或责任人显示为已离职、已调岗人员 | 状态停滞超过约定响应时限即可视为异常 |
| 交接完整性 | 调岗后问题单只有一句“已转交”，没有交接说明、待办清单和截止时间 | 信息断层会让接手人无法判断下一步动作 |
| 响应记录 | 评论和催办记录显示多次提醒无回复，最近一次实质更新距今超过一个处理周期 | “长期未响应”需要以记录为依据，不凭感觉判断 |
| 影响范围 | 问题位于关键路径、阻塞其他任务，或临近里程碑仍未推进 | 影响越大，升级层级越高、时限越短 |
影响范围判断建议按三个问题依次过一遍：该问题是否在关键路径上；是否已经阻塞其他任务或交付物；距离最近一个里程碑还有多少时间。三个问题中有一个答案为“是”或时间紧迫，就应按高优先级处置，不必等到常规时限到期。
范围边界需要提前说清：产品缺陷的修复与跟踪归缺陷管理流程；服务中断、服务事件的应急响应归服务事件与问题管理流程。本文处理的是项目推进过程中因责任人缺位、调岗或长期未响应造成的障碍，例如需求确认无人跟进、依赖方接口迟迟不提供、评审结论无人落实。把类型分清，才能找对升级对象。
先分清原因：缺位、调岗还是流程本身失效
“没人处理”是一个现象，背后可能是人员问题，也可能是流程问题。把可能原因先列为假设，再用证据逐项排除，可以避免把流程缺陷误判为个人失职，也能避免把人员离岗当成流程问题拖延处置。
| 原因假设 | 验证证据 | 排查顺序 |
|---|---|---|
| 人员离岗或调岗未完成交接 | 交接记录、组织归属变更信息、问题单最近一次变更历史 | 第2步 |
| 责任人权限不足，无法推动依赖方 | 问题单评论中是否出现“需要协调”“无权限”等表述，催办记录是否反复指向同一外部角色 | 第3步 |
| 问题归属划分不清，多方都认为不归自己 | 问题单描述中的责任范围、相关会议纪要中的分工结论 | 第3步 |
| 升级路径缺失，责任人不知道向谁求助 | 项目规则文档中是否有升级条款，历史同类问题是否都靠临时协调解决 | 第4步 |
| 问题优先级被低估 | 问题单优先级字段与实际影响范围的对比，排期会议上是否被反复推迟 | 第3步 |
排查顺序建议固定为：先查问题单状态与最近一次实质动作，确认停滞了多久、停在哪一步；再查责任人当前是否在岗、组织归属是否变化；最后查流程规则本身是否明确了归属、时限和升级路径。这个顺序的好处是先拿到事实，再讨论规则，避免一上来就开会追责却拿不出依据。
需要强调的是，以上每一项在核实前都只是假设。例如“责任人调岗”需要以组织变更信息或本人确认为准，不能因为消息不回就下结论；“优先级被低估”需要对比影响范围与排期记录，不能凭印象判断。排查结束后，把已确认事实和仍存疑的部分分开记录，处置动作只基于已确认事实展开。
转派与升级的处置步骤
处置按四步推进，每一步都有明确的负责人、产出物和停止点。整体原则是先保证问题有人接、能推进，再补齐责任归属和流程记录。
第一步：临时接管
由项目负责人确认问题现状，指定一名临时责任人，并在问题单上写明接管期限和待办事项。临时接管的作用是止血，期限建议与最近一个里程碑或一个处理周期对齐。临时责任人可以是原责任人的直接上级、同职能的备份人员，或对问题依赖方最熟悉的人。这一步的完成标志是：问题单上有明确的临时责任人和期限，且临时责任人已确认接手。
第二步：正式转派
临时接管到期前，项目负责人应完成正式转派。操作内容包括：更新问题单责任人；补充交接说明，写清已完成事项、未完成事项、关键依赖和下一步动作；设定新的截止时间；关联受影响的上下游任务；保留原责任人的历史记录，便于后续追溯。正式转派的完成标志是接手人能够不看聊天记录、仅凭问题单内容继续推进。
第三步：按影响与时限升级
升级不是转派的替代，而是转派后仍无法推进时的兜底。触发条件建议按影响和时限两个维度设定：
| 升级层级 | 升级对象 | 触发条件 |
|---|---|---|
| 一级 | 项目负责人 | 临时接管到期仍未指定正式责任人；或问题超过约定响应时限未更新 |
| 二级 | 项目指导委员会或对应职能负责人 | 问题位于关键路径且临近里程碑；或跨部门协调在一级层面无法解决；或涉及资源调整 |
升级时应携带事实材料：问题单链接、停滞时长、已尝试的协调动作、期望的决策事项。升级的目的是请求决策或资源，不是把问题原样上交。
第四步：追责与沟通
如果确认存在交接缺失或长期未响应，沟通应以问题单记录为基础，说明延误的事实、影响和改进要求，聚焦后续动作而非人身评价。追责结论应写入项目记录，作为流程改进的输入。
操作风险需要提前交代：批量转派前先导出或备份问题清单，避免误改后无法还原；涉及跨项目调整责任人时，先与接收方确认工作量和排期，避免转派变成新的积压；升级到二级之前，确认一级层面已经实际介入过，否则容易造成层级空转。
这些管理动作需要有承载的地方：问题单的责任人字段、交接说明、变更历史和超时提醒，如果分散在聊天工具和表格里，转派后就很难追溯。在ONES中，工作项可以记录责任人、状态、优先级和变更历史，交接说明可作为评论或描述留存，升级流转通过状态和负责人变更体现，项目负责人据此核对每一步是否落实。工具承载的是记录和流转，处置判断仍由项目负责人做出。
处置后如何验证恢复并防止复发
转派和升级完成不等于问题已经恢复。建议在正式转派后的一到两个处理周期内做一次核验，确认问题回到正常轨道。
| 验证项 | 核验内容 | 通过标准 |
|---|---|---|
| 责任人明确 | 问题单责任人字段是否为在岗人员，接手人是否确认 | 无空置、无挂名 |
| 按新时限推进 | 是否按新截止时间产生实质更新 | 连续两次以上更新有进展，而非仅改状态 |
| 遗留事项闭环 | 交接说明中列出的未完成事项是否逐项有结论 | 每项有完成、转出或明确取消的记录 |
| 关键路径恢复 | 被阻塞的任务是否解除阻塞，里程碑是否仍可达成 | 阻塞标记清除，排期无新增延期 |
恢复判断以实质进展为准：连续若干次更新都有具体动作和产出，关键路径不再被该问题阻塞，即可认为恢复正常。如果核验未通过，回到升级步骤，按影响重新确定层级，而不是继续等待。
复发预防从三个机制入手。人员变动时使用交接清单，至少覆盖在办问题清单、每项问题的当前状态与下一步、关键依赖方联系人和未决决策，交接双方确认后生效。为关键问题设置责任人备份，明确主责和备责，主责离岗时备责自动接管，无需临时找人。为升级设定时限与超时提醒规则，例如问题超过约定响应时限自动提醒项目负责人，临时接管到期自动提醒完成正式转派。
最后，把本次异常的原因、处置过程和结果写入项目复盘，区分哪些是人员变动带来的偶发情况、哪些暴露了流程缺口。复盘结论用于调整交接清单、备份机制和升级时限，让下一次人员变动时，问题单不至于再次停在“待处理”。
常见问题
临时接管期限设多长比较合适，到期还没找到正式责任人怎么办？
临时接管期限建议与最近一个里程碑或一个常规处理周期对齐，让接管人有明确的交付节点，而不是无限期代管。期限到期仍未确定正式责任人时，不要顺延临时状态，应按升级规则把问题提交到项目负责人层面，说明已尝试的协调动作和需要决策的事项，例如人员调配或职责重新划分。临时接管时间越长，责任归属越模糊，后续追溯也越困难。
责任人调岗后，原责任人还需要对交接前的问题负责吗？
这取决于组织自身的责任界定规则，本文不给出统一结论。可以明确的是，交接前的处理记录应当完整保留在问题单上，包括已完成事项、未完成事项和当时的判断依据，这样无论责任如何界定，都有事实可查。沟通时以记录为基础说明延误事实和影响，聚焦后续动作与改进要求，避免对个人作评价。若组织有明确的离任交接制度，按制度执行即可。
问题已经升级到二级，但会上没有形成决策，接下来怎么处理？
升级到二级后仍未决策，通常说明缺少明确的决策人或决策所需信息不足。此时应把问题重新整理为一份决策请求：问题现状、影响范围、已尝试的动作、可选方案及各自代价、期望的决策时点。同时确认二级对象是否具备相应权限，跨项目资源调整往往需要更高层或职能负责人共同确认。在决策形成前，为问题设定一个明确的观察节点，避免升级后再次陷入无人跟进的状态。
批量转派问题单时，怎样避免把积压转给同一个人？
批量转派前先导出问题清单，按接收人统计待处理数量和优先级分布，再与接收方确认工作量和排期。转派时保留原责任人和变更历史，便于回溯。对优先级高或位于关键路径的问题，建议逐条确认而不是随批量操作一起转出。转派完成后核对接收人的问题总量，若明显超出其处理能力，应同步启动升级，请求资源支持或调整排期。
团队规模较小、没有项目指导委员会时，升级对象怎么设置？
升级层级可以按实际治理结构简化，关键是每一级都有明确的决策人和触发条件。小团队可以把二级设为职能负责人或业务负责人，把跨团队协调交给能调动资源的人。无论层级多少，都应写清什么情况下升级、升级时携带哪些材料、期望得到什么决策。层级简化后，超时提醒和临时接管到期提醒更需要落实，否则问题容易在少数几个人之间反复流转。
