整站优化服务，合同内任务和临时救火任务怎样分别排期
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /2bc5bf862f17.html
📄
整站优化服务，合同内任务和临时救火任务怎样分别排期
直接回答：把合同内任务按“可交付里程碑”排进固定节奏，把临时救火任务按“影响面+恢复时限”排进缓冲池，两者共用同一份容量表，而不是共用同一条队列。合同任务占用的应是可承诺产能，救火任务占用的是预留缓冲；一旦缓冲被连续吃满，就要回到合同范围重新谈优先级，而不是继续挤压前者。
先看一个假设情境：缓冲被吃满的第三周
假设某站点与整站优化服务方签了季度合同，约定每月完成一批栏目结构梳理、模板层调整和内容质量抽检。执行到第三周，站点方连续报来四件临时事项：某栏目批量页面无法正常访问、一次改版导致旧链接大面积跳转异常、某个高流量入口出现重复内容、以及一次促销活动页需要临时加监测。服务方如果把这四件事全部插到当天，合同内的模板层调整就会停摆；如果全部推后，站点方又会觉得“花钱没反应”。
这个情境的关键不是谁更重要，而是两类任务的性质不同：合同内任务有明确交付物和验收口径，救火任务只有恢复目标。排期方式必须分开，否则每次救火都会变成对合同承诺的隐性挪用。
合同内任务：按里程碑占用固定产能
合同内任务的排期依据是交付物，而不是“本周做了几件事”。可操作的做法是先把合同期切成若干里程碑，每个里程碑写明可验收的产出，例如“完成某层级栏目的URL归并与重定向规则”“完成某类模板的标题与描述字段改造”“完成一轮内容质量抽检并输出待处理清单”。
- 每个里程碑预留固定人力，不因临时事项自动让位；
- 里程碑内部的日排期可以微调，但里程碑的完成窗口不轻易后移；
- 验收标准在开工前写清，避免做完后再补口径。
这样做的结果是：合同任务的进度可预测，临时事项也不会被误记为“合同内已完成”。如果里程碑本身已经排满，说明合同产能没有余量，此时任何救火都只能从缓冲或变更中出，而不能默认从合同任务里挖。
临时救火任务：按影响面分级，不按提出顺序排
救火任务最常见的错误是按“谁先提”排，而不是按“影响谁、影响多大”排。更可用的分级方式是先判断影响面，再判断是否有可接受的临时替代方案。
- 影响可访问与转化路径：优先处理，目标是尽快恢复，不必追求一次做到最优；
- 影响收录与重复内容判断：可排在当天或次日，先控制扩散，再补长期修复；
- 影响数据观察与归因：可进入缓冲池排队，除非它同时影响前两类；
- 纯新增需求：不属于救火，应走变更评估，不占用救火缓冲。
这里的实际动作是：给每件救火任务标注影响面和恢复时限，再决定它占用多少缓冲。恢复时限越短，越应该采用“先止血、后补账”的方式，并把补账动作登记为后续合同任务或独立变更。这样做的结果是，救火不会无限延长，也不会因为一次止血而丢掉长期修复。
两类任务共用一张容量表，但用不同刻度
分开排期不等于分开管理。两类任务应共用一张容量表，但刻度不同：合同任务看“里程碑完成度”，救火任务看“缓冲消耗率”。
可以这样设置假设规则：每周总产能中，合同任务占用固定比例，救火缓冲占用另一固定比例。当某一周救火缓冲消耗超过预留量，下一周要么减少合同任务的并行项，要么把新增救火转为变更单。判断依据不是“这周很忙”，而是缓冲是否连续被击穿。如果只是单周波动，通常不需要动合同排期；如果连续两周以上击穿，就说明预留量或合同范围需要重谈。
什么时候该调整，什么时候该拒绝
出现以下条件时，应调整排期而不是硬扛：救火任务的影响面覆盖多个栏目或模板、恢复动作会改动合同内已验收的产出、或者同一类救火在短期内重复出现。重复出现往往说明根因没有处理，此时应把根因修复升级为合同内任务，而不是继续按次救火。
出现以下条件时，应明确拒绝或转为变更：临时任务只是“顺便做一下”、没有明确恢复目标、或者要求占用合同任务的固定产能却不改变交付承诺。拒绝的代价是短期沟通成本，但不拒绝的代价是合同里程碑持续后移，最终两类任务都无法验收。
把这两条线分开之后，下一步动作就清楚了：先确认本周缓冲是否够用，够用就按影响面处理救火，不够用就走变更或调整合同并行项。排期是否成立，不取决于任务数量，而取决于缓冲消耗和里程碑完成度是否仍在约定范围内。
