公司网站推广计划，合同内任务和临时救火任务怎样分别排期
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /b56886e47bab.html
📄
公司网站推广计划，合同内任务和临时救火任务怎样分别排期
结论先说：合同内任务按交付节奏排，临时救火任务按影响面插队，但两者必须共用同一张排期表和同一个优先级口径，否则救火会不断吞掉合同内的时间。下面用一个假设情境，把决策过程拆开。
假设情境：一个五人小组的两类任务冲突
假设某公司网站推广计划里，合同内任务包括每月四篇内容、两次页面调整、一次数据复盘；临时救火任务包括首页被改坏、表单收不到提交、活动页要当天上线。样本只有一个客户时，负责人凭记忆就能协调；一旦同时服务三个以上客户，或者合同内任务开始按周交付，这套凭记忆的方式就会失效，因为救火任务没有统一入口，谁喊得响谁先做。
这个边界要写清楚：小样本靠人盯人能跑通，不代表可以照搬到多客户、多交付物的规模。规模一变，排期冲突的性质就从“忙不过来”变成“优先级没有共同依据”。
先给两类任务各定一个排期锚点
合同内任务的锚点是交付承诺日，它来自合同或需求说明书里写明的周期，不随当天情绪变动。临时救火任务的锚点是影响面，判断依据是这件事影响的是全站、单个页面还是一个渠道的局部表现。
- 合同内任务：按承诺日倒推，先占用固定工时，再开放剩余工时给临时任务。
- 临时救火任务：按影响面分三档——阻断型（用户无法完成关键动作）、损耗型（数据持续丢或页面持续报错）、优化型（想加一个按钮或改一句文案）。
- 阻断型当天处理，损耗型当天评估、次日排入，优化型进合同内任务的待排池，不单独插队。
这样做的实际动作是：在排期表上给合同内任务预留固定时段，临时任务只能使用剩余时段。结果是救火不再无条件抢占合同内时间，代价是部分优化型临时需求会被推迟，需要提前和提出方说明。
用影响面判断，而不是用提出人的语气判断
救火任务最容易出现的偏差，是把“说得很急”等同于“影响很大”。可区分的证据有三类：
- 是否阻断关键动作：表单提交、下单、登录这类动作失败，属于阻断型；页面某段文字不好看，不属于。
- 影响范围是否在扩大：同一问题从单个页面扩散到多个入口，说明需要优先处理；只在一个低流量页面出现，可以排入次日。
- 是否有临时绕行方案：如果运营可以先用手工方式承接，处理紧迫度下降一档；如果没有绕行方案，紧迫度上升一档。
这三条证据的作用是让排期决定可复核。当一个临时任务被判定为优化型，下一步不是直接拒绝，而是把它登记进待排池，并给出一个可预期的排入时间。
把两类任务放进同一张表，避免两套优先级
如果合同内任务用一张表、临时任务用聊天记录，冲突时就没有共同依据。可行做法是共用一张排期表，字段至少包括：任务来源（合同内/临时）、影响面档位、承诺日或期望完成日、当前状态、下一次检查时间。
每周固定一次检查，动作是核对合同内任务的剩余工时，再看临时任务是否已经挤占了预留时段。如果连续两周出现挤占，下一步要调整的是合同内任务的工时估算或临时任务的分流规则，而不是继续靠加班补。
一个可复用的判断顺序
遇到新任务时，按这个顺序走：先确认它是否属于合同内交付物，是则进承诺日排期；不是则判断影响面档位；阻断型当天处理并记录占用的工时；损耗型当天评估、次日排入；优化型登记进待排池。每次处理完临时任务，回填它实际占用的工时，这个数字会直接影响下一周合同内任务能否按承诺日交付。
需要说明的是，某个统计归零或某次抓取异常，并不能单独证明排期处理正确，它可能来自统计口径变化、样本量太小或任务本身波动，判断仍要回到影响面和承诺日这两个锚点。把这两个锚点写进排期表，合同内任务和临时救火任务才有一致的先后依据，而不是每次重新争论谁更重要。
