临时加活：如何把优先级问题讲清楚

场景：下午突然收到“今晚要一版”

你正在收尾周五交付的核心版本，下午两点又收到一项临时任务：“客户晚上要看，今天先出一版。”新任务本身只需要三小时，但会占用原项目回归时间。

此时真正需要沟通的不是愿不愿意帮忙，而是两个交付节点无法同时保持原计划。把取舍说清楚，任务发起人才有机会做优先级判断。

直接答应会发生什么

常见回复是：

好的，我尽快弄。

这句话看起来配合，却没有记录新任务对原计划的影响。到了晚上，新任务可能只完成一半；原项目的回归也被压缩。第二天双方记住的往往是“已经答应”，而不是当时资源不足。

更有效的回复结构

一条可执行的优先级沟通包含四项信息：

1. 确认新任务目标：说明你理解要交付什么。
2. 列出现有承诺：写出当前占用时间的任务和节点。
3. 量化影响：告诉对方新任务会让哪个节点变化。
4. 请求选择：给出两到三个可执行方案。

可以这样回复：

收到，客户今晚需要一版可展示的方案。我现在在做周五版本的最后回归，预计还需要三小时。如果今天优先处理客户方案，周五版本的回归会顺延到明天上午。我们可以选两种安排：今晚先出客户方案，原版本明天中午交；或我先完成回归，客户方案明天上午 10 点给。你确认优先级后我马上调整。

为什么这段话更容易推进

它没有拒绝新任务，也没有隐藏资源冲突。对方可以基于客户时点和原项目风险做判断。无论选择哪一项，新的交付预期都在消息里留下了记录。

如果对方仍然要求“两件都要”

继续补充资源条件：

如果两个节点都保持，需要增加一位同事协助回归，或把客户版范围缩到首页与核心流程。我可以在半小时内拆出任务清单，确认协作人后同步推进。

这时讨论从个人加班转向范围与资源，更接近真实解决办法。

面对不同对象的调整

对上级

先给结论和影响，再请对方拍板。重点写业务节点，不展开个人情绪。

对同事

明确依赖与协作接口，避免只把压力传回去。可以主动给出拆分方案。

对客户

只承诺已确认的交付范围。内部优先级由团队先统一，再对外给出一个口径。

复盘：临时加活为什么总是重复发生

如果同类情况每周出现，可以记录三项数据：临时任务来源、占用工时、被顺延的原任务。连续两到三周后，用事实讨论容量和排期，比单次抱怨更容易推动改进。

发送前检查

• 新任务的交付标准是否清楚？
• 原任务的时间承诺是否被写出来？
• 影响是否具体到范围或时间？
• 对方是否拿到了可选择的方案？
• 新优先级确认后，相关协作方是否都会收到更新？

临时任务并不可怕，模糊的优先级才会把风险留到最后一刻。