互联网营销公司，合同内任务和临时救火任务怎样分别排期
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /77de2eeefde9.html
📄
互联网营销公司，合同内任务和临时救火任务怎样分别排期
合同内任务和临时救火任务不能塞进同一张排期表按先后顺序处理，而应分成两条通道：合同内任务按交付里程碑占用固定产能，临时救火任务按影响面和时限占用预留产能。判断分界线的依据不是任务大小，而是它是否改变已承诺的交付日期、是否阻塞客户正在进行的投放或上线、以及是否可延后到下一个合同周期。
矛盾现象：排期表越满，救火反而越多
很多团队把两类任务混排后会发现一个反常现象：合同任务排得越密，临时救火插入得越频繁，最终两边都延期。表面看是产能不足，实际是排期结构问题。混合排期时，救火任务没有独立预算，只能挤占合同任务的时间；合同任务被挤压后又产生新的延期，制造出更多救火需求，形成自我强化的循环。
两种解释：产能真的不够，还是通道没有分开
解释一：产能确实不足。如果连续多个周期里，合同任务本身就需要全部可用工时才能完成，没有任何余量，那么救火任务无论怎么排都会造成延期。这种情况下问题在报价和承诺阶段，不在排期方法。
解释二：产能够，但两类任务共用一个队列。如果合同任务在正常周期内能留出余量，只是每次救火插入都打乱顺序，那么问题在缺少分流规则。救火任务被当成普通任务排队，既没有优先级定义，也没有时间上限，导致它无限膨胀。
区分两种解释的证据
可以观察三个可验证的信号：
- 救火任务的来源分布。如果多数救火来自合同任务延期后的连锁反应，说明是排期结构问题；如果多数来自客户外部突发需求，说明是需求管理问题。
- 合同任务的完成节奏。统计连续几个周期内合同任务的实际完成时间与计划时间的偏差。偏差稳定且小，说明产能有余量，只是被救火打乱；偏差持续扩大，说明产能本身不够。
- 救火任务的关闭方式。如果救火任务大多能在一到两天内关闭，说明它本可以走短通道；如果每个救火都演变成多天项目，说明它实际是未签约的新需求，应走变更流程而非救火通道。
注意，某段时间救火任务数量下降，不能单独证明分流规则生效。它也可能是客户进入淡季、合同任务恰好减少，或救火被推迟而非解决。需要结合合同任务偏差是否同步收窄来判断。
分流排期的具体做法
把每周可用产能按比例切成两块：合同内任务占用固定份额，临时救火占用预留份额。预留份额的具体比例取决于业务类型，假设某团队每周可用工时为100小时，合同任务占70小时，救火预留20小时，剩余10小时作为缓冲。这个数字只是说明分配方法，不代表任何实际团队的推荐值。
救火通道需要三个约束：
- 时限约束。每个救火任务先限定在一个明确的时间盒内，比如半天。时间盒结束时必须给出结论：已解决、需要转为合同变更、或确认可延后。
- 触发条件。只有满足以下条件之一才进入救火通道：客户正在进行的投放或上线被阻塞、已交付内容出现影响访问的错误、合同约定的关键节点当天到期。其余需求一律进入待评估队列。
- 溢出规则。当救火预留份额在周期内用完，新救火任务不再自动插入，而是由负责人决定是否从合同份额中临时借调，并同步调整对应合同任务的交付日期。借调动作必须留下记录，让合同任务的延期有明确归因。
一个实际动作是：在排期表里为每个合同任务标注它的下一个硬节点日期，为每个救火任务标注它的阻塞对象。当两者冲突时，比较硬节点日期和阻塞影响的持续时间，选择影响面更小的一方延后。这个动作的结果会直接决定下一周期预留份额是否需要调整：如果借调频繁发生，说明预留份额偏低或触发条件过宽。
前提变化后应切换决策的条件
当业务从“以合同交付为主、救火偶发”变为“救火常态化、合同任务被持续挤压”时，排期方法需要切换。切换的判断条件不是救火次数，而是合同任务的实际交付日期是否连续两个周期偏离计划超过约定容差。一旦满足这个条件，继续用预留份额微调已经不够，需要重新评估合同承诺的产能基础，或在报价阶段就把常态化的临时支持计入工作量。
反过来，如果合同任务偏差稳定、救火任务能在时间盒内关闭，就应维持分流排期，不必因为某周救火偏多就推翻整套规则。排期的调整依据是连续周期的偏差趋势，不是单次波动。
