公司网站推广：合同内任务和临时救火任务怎样分别排期
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /7c213c276993.html
📄
公司网站推广：合同内任务和临时救火任务怎样分别排期
先给结论：合同内任务按“交付物依赖顺序”排，临时救火任务按“影响面+可逆性”排，两者共用一条容量上限，而不是共用一张任务清单。你手上如果只有一个内容日历、一页待办列表或一份合同附件，也能先做分离：把有明确交付物和验收条件的条目归入合同池，把因外部变化、故障或临时需求产生的条目归入救火池，再分别给两个池子设上限。缺少完整数据或后台权限时，这个动作仍然可执行，但它只能帮你判断排期优先级，不能证明某个页面会被收录、某次推广一定见效。
先判断一条任务属于合同池还是救火池
判断依据不是“谁提的”，而是这条任务有没有事先约定的交付物、时间窗和验收信号。合同池的典型特征：对应合同或工作说明书里的具体条目，例如每月固定数量的页面更新、指定栏目的内容维护、约定的技术检查项，完成标准可以事先写清。救火池的特征：由合同外事件触发，例如页面突然打不开、活动临时改期、渠道政策调整导致素材必须更换，通常没有事先约定的完成标准，且拖久了影响面会扩大。
如果一条任务同时具备两种特征，例如合同内约定的栏目因为服务器问题无法更新，把它拆成两条：恢复可访问性归救火池，按约定完成更新归合同池。拆不开就按救火处理，但要在记录里注明它占用了合同任务的工时，方便后续判断是否需要调整合同池的排期。这一步的产出是一张两列清单，而不是一个笼统的优先级排序。
给两个池子分别设容量上限，而不是抢同一份时间
常见错误是把所有任务放进一张按紧急程度排序的列表，结果救火任务不断插到前面，合同任务被无限推迟，直到临近交付才集中赶工。更稳的做法是给两个池子分别设上限：例如每周可投入的推广工时中，固定划出一部分给合同池，剩余部分留给救火池，并明确救火池用超时合同池不会自动让位，而是触发一次取舍决定。
假设一周可投入20小时，合同池占12小时，救火池占8小时。某周救火任务实际需要14小时，超出6小时。此时不要直接把合同池压到6小时，而是先判断：这6小时里有多少是必须本周处理的，有多少可以顺延到下周。必须本周处理的部分，从合同池借时间，并同步告知合同任务的交付时间会推迟；可以顺延的部分，放进下周救火池的预留额度。这个假设例子的作用只是说明比较方法，不是真实项目数据。
缺少完整数据时，容量上限可以先用估算值，但要把估算依据写下来，例如“按上周实际投入倒推”。估算值不能用来推出“救火任务占比高说明团队效率低”这类结论，因为任务量波动、外部事件频率、审批等待时间都可能是更合理的解释。
用依赖关系排合同池，用影响面排救火池
合同池内部按依赖关系排序：先做被其他任务依赖的条目，例如先确定页面结构，再写内容，再做技术检查。判断方法很简单：问“这条不做，后面哪几条会卡住”。卡住越多的越靠前。合同池的排期可以按周或按双周滚动，但每次滚动只调整顺序，不轻易改变已承诺的交付时间。
救火池内部按影响面和可逆性排序。影响面指问题波及的范围，例如影响全部访客还是个别页面；可逆性指处理错了能不能快速回退。影响面大且不可逆的优先处理，影响面小且可逆的可以合并到固定时段集中处理。这里同样要注意：某个指标短时下降或某项请求量归零，不能单独证明是故障，也可能是统计延迟、渠道正常波动或权限变更，需要先确认再决定是否升级为救火任务。
一个可执行的最小动作：把现有待办列表拆成两栏并标注下一步
如果你现在只有一个待办列表，按下面步骤处理，不需要后台权限或完整数据：
- 逐条标注它对应合同里的哪一条，标不出来的先归入救火池。
- 给合同池条目写上“完成时能看到的验收信号”，例如页面可访问、指定栏目已更新、检查项已通过。
- 给救火池条目写上“不处理的后果”和“本周是否必须处理”。
- 按上面的容量上限，把两条清单分别排进本周时间。
- 把因救火而推迟的合同任务单独列出，写清推迟原因和新的预计完成时间。
这个动作的结果是：你能明确说出本周哪些合同任务会被影响、影响多少、下一步是补时间还是改交付时间。它不能推出的结论包括：不能据此判断推广效果好坏，不能据此判断某个渠道是否值得继续投入，也不能替代对具体页面或账号的实际检查。缺少数据时，先做分离和记录，比强行给所有任务排一个精确到小时的顺序更可行。
