线上推广公司：合同内任务和临时救火任务怎样分别排期
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /6df45f9960ca.html
📄
线上推广公司：合同内任务和临时救火任务怎样分别排期
先把两类任务放进同一张可排序的清单，但用不同队列和不同准入条件：合同内任务按交付里程碑排固定产能，临时救火任务只占用预留缓冲，并且必须由需求方书面确认“插入后哪些合同任务顺延”。如果两类任务混在一张待办里按先后顺序做，救火任务会持续吞掉合同产能，最后两边都延期。判断是否该插入，不看任务紧急程度，而看它是否满足三个条件：影响已上线页面或账户的正常运行、有明确责任人和截止时间、不插入会造成可量化的损失。不满足就进入下一周期，而不是当天处理。
先把手上的资料变成两类任务清单
拿你正在用的项目排期表或需求登记表，逐条标注四个字段：来源（合同附件、口头新增、平台通知）、验收标准、依赖的前置动作、最晚可完成时间。标完后会发现，很多所谓救火任务其实缺验收标准，比如“把落地页改一下”没有说明改哪一块、改完谁确认。这类任务不能直接排期，先退回补充信息。真正需要插入的，通常是已上线页面出现抓取异常、表单提交失败、广告落地页与账户政策冲突等会直接影响已有交付的情况。
这一步的实际动作是：把每条任务写成一句可验收的话，例如“在周三前替换首屏主图并确认移动端不溢出”。结果会直接影响下一步——能写成这句话的任务进合同队列，写不出来的进待澄清区，不占用任何产能。
合同内任务按里程碑锁定产能，不按天排满
合同内任务的排期依据是交付物和验收节点，不是每天塞满工时。假设一份合同约定每月产出若干页面并完成站内结构调整，那么排期应围绕“内容初稿—内部审核—上线—数据观察”这几个节点倒推，每个节点留出返工余量。常见的错误是把产能按天排到满负荷，一旦出现救火就整体后移，导致验收节点连续失守。
可执行的做法是：先确认本周必须交付的合同任务数量和各自的最晚完成时间，再把剩余可支配时间标注为缓冲。缓冲不分配给任何合同任务，专门用于临时插入。这样做的结果是，合同任务的完成时间不再随救火任务波动，你也能在需求方问“为什么这个没做完”时给出明确依据：合同任务占用的是锁定产能，救火任务占用的是缓冲，缓冲用完就只能顺延合同任务并同步通知。
临时救火任务用准入条件和缓冲额度控制
临时任务最大的问题是无限扩张。控制方式不是拒绝所有插入，而是给缓冲设一个额度，并规定额度用完后如何处理。额度可以按周设定，例如每周预留固定比例的可支配时间用于救火，超出部分进入下一周或触发合同任务顺延确认。额度不是精确预测，而是让“插入”这个动作产生可见代价。
准入条件建议写成三条，全部满足才插入：
- 影响范围明确，能指出受影响的页面、账户或投放计划；
- 有唯一责任人，能在当天给出所需素材或确认；
- 不处理的后果可描述，例如已上线页面无法正常访问或转化路径中断。
只满足“领导很急”或“客户在催”不构成插入理由。执行结果是：缓冲内的任务当天处理，缓冲外的任务进入下一周期，同时把被顺延的合同任务和新的完成时间书面同步给相关方。这一步会暴露一个常见遗漏条件——很多团队没有约定顺延规则，导致救火做完后没人知道合同任务该不该补、什么时候补。
用一个假设例子看清顺延代价
假设某周可支配时间为四十个单位，合同任务锁定三十个，缓冲十个。周一插入一个救火任务，占用六个单位，缓冲剩四个。周二再来一个救火任务，评估需要八个单位，超出缓冲四个。此时有两个选择成立的条件不同：如果合同任务的最晚完成时间还有余量，可以从合同产能中临时借四个单位，但必须记录借用量并在本周内归还；如果合同任务已接近验收节点、没有余量，就应把第二个救火任务顺延到下周，并同步说明顺延原因。选择哪种，取决于合同任务当前是否处于不可移动的验收窗口，而不是取决于哪个需求方声音更大。
这个例子里的数字只用于说明比较方法，不代表任何真实项目的产能标准。真正要记录的是每次借用的数量和归还情况，否则缓冲会被反复透支，合同任务和救火任务的边界再次消失。
每周复盘时只改一个变量
排期稳定后，每周复盘只需要看一个指标：缓冲被救火任务用掉的比例，以及合同任务因插入而顺延的次数。如果缓冲长期不够用，先检查准入条件是否执行到位，而不是直接扩大缓冲。扩大缓冲等于默认所有临时任务都合理，合同产能会被持续侵蚀。如果顺延次数集中在某类任务上，说明该类任务应该在合同阶段就写入范围，而不是每次靠救火处理。复盘的输出是一份调整后的任务清单和明确的顺延记录，下一次排期直接沿用，不再重新争论优先级。
