📍 WDQWDWQD987AAAAA:216.73.216.173
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /3a1a29ecdf5a.html
📄

网络营销公司排名：合同内任务和临时救火任务怎样分别排期

核心判断只有一条：合同内任务按交付里程碑排期，临时救火任务按影响面排期，两者共用同一张周排期表但使用不同的优先级规则。如果救火任务会占用超过当周可用工时的两成，就必须把它转为变更单，重新谈交付时间，而不是靠加班硬扛。下面给出两种条件下的不同选择，以及把分歧变成可核对项目的具体动作。

条件一：救火任务不影响合同交付节点时，用插入式排期

当临时任务只影响执行顺序、不影响验收日期时，选择插入式排期：把救火任务放进当周的空档，合同内任务保持原里程碑不变。

判断依据是可以核对的三个事实：救火任务预计占用的小时数、本周剩余可用工时、合同内任务的下一个交付节点日期。三者都写在排期表上，谁都能核对，就不再靠口头感觉争论。

实际动作：在排期表里给每个任务加两列，来源（合同内/临时）和影响节点（是/否）。每周一由项目负责人填一次，填完后把表发给所有相关角色确认。结果是分歧从“你觉得急我觉得不急”变成“这一行填的是否准确”，讨论对象从立场变成数据。

例外：如果同一个临时任务被反复插入三次以上，说明它不是救火，而是被漏掉的常规需求，应回到合同范围重新讨论，而不是继续插入。

条件二：救火任务挤占合同交付节点时，用置换式排期

当救火任务预计占用的小时数超过当周可用工时的两成，或者会直接推迟某个验收节点时，选择置换式排期：明确写出被置换的合同内任务是哪一个，以及它顺延到哪一天。

置换式排期的关键不是“都做”，而是“先减后加”。先确认哪一项合同内任务可以顺延，再接受救火任务。没有这一步，排期表就会变成一张永远填不满的愿望清单。

实际动作：发起一次变更确认，内容只包含四项——救火任务描述、预计工时、被置换的合同任务、新的交付日期。相关角色在这四项上确认后，排期表同步更新。结果是后续验收时以更新后的日期为准，避免“当时说好了”这类无法核对的分歧。

假设例子：某周可用工时为40小时，合同内任务原计划占用32小时，临时救火任务预计12小时。两者相加超出可用工时，此时应把合同内任务中优先级最低的一项顺延，而不是把12小时摊进每天的下班时间。这个例子只说明比较方法，不代表任何真实项目数据。

把两种排期落到同一张表上的三个字段

• 优先级来源：合同内任务写验收节点日期，临时任务写影响面（影响几个页面、几个渠道、是否影响正在投放的落地页）。两类优先级不放在同一列里比较，避免用“都重要”互相抵消。
• 可顺延标记：每个合同内任务提前标好是否可顺延、可顺延几天。救火任务到来时直接查这一列，不用临时开会决定。
• 确认人：每个任务写一个确认人，而不是一个团队。多个角色对同一事实理解不同时，由确认人做最终判断并留下记录。

这三个字段的作用是让排期可核对。执行一周后如果发现救火任务频繁触发置换，下一步不是继续加人，而是回头检查合同范围是否漏项。

需要区分的两种“急”

临时任务里有一种是真急：影响正在投放的广告落地页、影响已承诺给客户的交付物。另一种是假急：只是提出者当天想看到结果。区分方法是问一句“如果这周不做，会发生什么可核对的具体后果”。答不出具体后果的，进入下周常规排期，不占用当周救火额度。

这个判断动作的结果会直接影响下一步：真急任务触发置换式排期，假急任务只进入待办列表。两类任务分开记录两周后，就能看出救火额度是否被滥用。

排期之外还要留一个复核点

无论采用哪种排期，每周结束时核对一次：本周实际发生的临时任务小时数、被顺延的合同任务、更新后的交付日期。三者对不上时，先查记录是否完整，再查判断是否一致。复核的目的不是追责，而是让下一周的排期依据更接近实际。

如果连续几周都出现置换，说明合同内任务的工时估算偏乐观，或者临时任务的来源没有被纳入范围管理，此时应调整估算方式或重新界定服务范围，而不是继续用置换来维持表面进度。