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

公司官网制作，合同内任务和临时救火任务怎样分别排期

把合同内任务和临时救火任务放进同一张排期表，是官网制作中最常见的失控点。更稳的做法是：合同内任务按“交付里程碑”倒排，临时救火任务按“影响面”插空，并且给救火任务设一个固定的时间上限——超过上限就转入变更流程，而不是继续挤占合同内任务的档期。

先分清两类任务的时间性质

合同内任务的特点是范围已确认、有验收节点、可以提前估算工时；临时救火任务的特点是突发、影响面不确定、往往由一方口头提出。这两类任务混排时，救火任务会天然挤占合同内任务的时间，因为它的紧迫感更强，但它的价值未必更高。

区分方法可以看三点：是否在已签范围里、是否有明确的验收人、延迟一周是否会导致合同节点违约。三个都指向合同内任务，就先排合同内任务；只有第三点指向救火任务，才允许它插队。

假设情境：一个首页改版和三次临时加急

以下为假设情境，用于说明排期方法，不代表任何真实项目。某公司官网制作项目处于开发中期，合同内还剩首页改版、表单联调、移动端适配三项，计划两周完成。此时陆续出现三个临时任务：领导要求加一个活动弹窗、销售要求改一处联系方式、合作方要求临时增加一个报名入口。

如果这三个任务全部按“马上做”处理，首页改版的档期会被切碎，表单联调被推迟，最终合同节点整体后移。反过来，如果全部拒绝，又可能影响活动上线和销售跟进。真正需要判断的不是做不做，而是分别排到哪一档。

合同内任务用里程碑倒排，不用“先做容易的”

合同内任务的排期依据是验收节点，而不是任务难度或完成快感。具体动作是：先标出合同约定的交付日期，再往前推每个环节需要的确认时间，把首页改版、表单联调、移动端适配按依赖关系排列。

例如表单联调依赖首页改版的结构定稿，那么首页改版的截止时间就不能晚于联调开始时间。这个动作的结果是：合同内任务有了明确的“最晚开始时间”，任何临时任务只能占用这个时间之外的余量，而不是占用余量本身。一旦发现余量为零，说明合同节点已经处于风险中，此时应该先暴露风险，而不是继续接救火任务。

临时救火任务按影响面分三档处理

救火任务不适合用“紧急/不紧急”两分法，因为它几乎都显得紧急。更可操作的是按影响面分档：

• 影响上线或合规：例如报名入口缺失导致活动无法收集信息。这类任务给固定时间上限，做完立即回到合同内任务。
• 影响转化但不影响上线：例如弹窗、联系方式修改。排入当周固定救火时段，不单独打断合同内任务。
• 影响体验或偏好：例如文案措辞、配色微调。进入待办池，等合同内任务到达可暂停点时统一处理。

分档之后，每个救火任务都有明确的处理时机和上限。上限的作用是防止单个救火任务无限扩张——如果超过上限仍未解决，说明它已经不是救火，而是范围变更，应该走变更确认，而不是继续占用排期。

给救火任务留固定窗口，而不是留“有空再说”

“有空再说”在实践中等于永远没空，因为合同内任务会自然填满所有时间。更可行的做法是每周固定留出一个救火窗口，例如半天，专门处理第二档和第三档任务。第一档任务允许突破窗口，但必须记录占用了哪项合同内任务的时间，并在下一周补回。

这个动作的关键结果是：临时任务有了可预期的处理时间，提出方不必反复催促；合同内任务也不会被随机打断，排期表仍然可读。如果救火窗口连续两周被第一档任务占满，说明问题不在排期方法，而在于需求提出阶段缺少过滤，需要回到范围确认环节处理。

判断排期是否失效的两个信号

第一，合同内任务的“最晚开始时间”被反复推迟，说明救火任务已经实质挤占了合同档期。第二，救火任务的处理时间持续超过设定上限，说明它应该被重新定义为合同变更。出现这两个信号时，继续微调排期没有意义，应该先确认范围，再重新倒排。

排期的目的不是让所有任务都显得被安排好了，而是让合同节点和救火任务各自有明确的边界。边界清楚之后，下一步才是决定哪些任务需要重新报价或顺延交付。