公司营销方案：合同任务和临时救火任务怎样分别排期
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /40c0865664d9.html
📄
公司营销方案：合同任务和临时救火任务怎样分别排期
先把两类任务放进两个独立的排期池：合同内任务按交付节点倒排，临时救火任务按影响面分级插空。只有当临时任务会挤占合同里程碑时，才动用预留缓冲，并同步通知对方调整某个非关键节点。如果临时任务持续超过两周仍无法收敛，就要把它升级为合同变更或单独报价，而不是继续靠加班消化。
先判断哪些旧安排值得保留
旧内容、旧系统或旧合作关系要退出之前，先做一次保留价值判断，而不是整体推翻。判断依据可以看三点：这部分是否仍在稳定带来有效线索、维护成本是否低于重做成本、交接是否会影响正在跑的合同节点。
如果三项都成立，保留是合理的，把它的排期固定成低频维护，例如每月一次巡检、每季度一次内容更新。如果只有第一项成立、维护成本却很高，适合改写：保留数据结构和可复用的素材，替换掉过时的呈现方式。如果三项都不成立，直接退出，把释放出来的工时并入临时任务池。
合同任务用倒排加缓冲，不要用正排
合同内任务的排期逻辑是倒排：从验收日往前推，标出每个交付物的最晚开始时间，再在关键节点之间留出缓冲。缓冲比例按历史偏差估算，假设过去类似交付平均延误两天，就按每个节点预留两天，而不是凭感觉留一周。
具体动作是先列出合同里可验收的交付物，再给每个交付物标注依赖关系。结果会直接影响下一步：如果发现两个交付物共用同一份素材，就必须串行排期；如果互不依赖，就可以并行，把节省出来的时间转为救火缓冲。
临时救火任务按影响面分级，不按提出顺序
临时任务最大的问题是按谁先提谁先做来排，结果合同节点被持续侵蚀。更稳的做法是按影响面分级：
- 一级：影响线上转化或客户可见内容的错误，当天处理，占用合同缓冲。
- 二级：影响内部效率但不影响对外交付，排进本周剩余空档，不占用缓冲。
- 三级：优化类、想法类需求，进入待评估清单，下次合同变更时一并谈。
分级之后要做一个动作：把一级任务写进当天的排期表，并明确它挤掉了哪个合同子任务。这个记录会影响下一步——如果一周内一级任务出现三次以上，说明合同排期本身留的缓冲不足，需要重新谈判交付节奏，而不是继续压缩质量。
改写还是退出：用维护成本做分界
当旧合作关系或旧系统需要调整时，改写和退出的分界是维护成本是否可预测。可预测的维护成本，适合改写：保留接口、保留已积累的数据，只替换表现层。不可预测的维护成本，比如每次改动都要重新排查历史遗留问题，适合退出，把资源转到新方案上。
假设一个旧落地页每月仍带来少量咨询，但每次改文案都要重新处理嵌套结构，耗时超过新建一个页面的时间。这种情况下改写的前提是结构可复用；如果不可复用，退出的实际动作是保留旧页只做静态维护，新需求全部走新页面，避免旧结构继续消耗排期。
把两类排期合并成一张周视图
分开排期不等于分开管理。每周固定一个时间点，把合同任务的进度和临时任务的实际占用合并到一张视图里，只回答一个问题：本周合同里程碑是否仍然可达。
如果可达，临时任务继续按分级处理；如果不可达，先调整非关键节点，再考虑增加投入。这个动作的结果决定下周的排期方式：缓冲被消耗过半，就降低临时任务的接收上限；缓冲充足，才允许接新的救火需求。排期不是一次排完，而是每周根据实际消耗重新分配。
