公司网站设计，合同内任务和临时救火任务怎样分别排期
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /d42ef1efe26c.html
📄
公司网站设计，合同内任务和临时救火任务怎样分别排期
结论先说：把合同内任务和临时救火任务放在同一张排期表上，按“先到先做”排序，通常会让合同内任务被反复推迟；更可操作的做法是给两类任务设不同的排期池，合同内任务按里程碑锁定产能，临时救火任务只占用预留的机动产能，超出部分进入待评估队列。这个结论成立的前提是：临时救火任务的数量和单次耗时可以被大致记录，而不是完全不可预测。如果救火任务本身来自合同内任务反复返工，那么分池排期只会掩盖问题，此时应先处理返工原因，而不是继续加池子。
为什么“先到先做”会让合同内任务持续延期
合同内任务的特点是范围、验收标准和交付节点在合同里已经写定，延期往往触发违约或尾款争议；临时救火任务的特点是发起人急、看起来只要几十分钟，但没有明确的优先级依据。当两者混在一张表里，救火任务因为“更急”不断插到前面，合同内任务的排期被切成碎片，每次重启都需要重新进入上下文，实际耗时比连续做更长。
可以核对的一个现象是：如果合同内任务的完成时间在推迟，但团队总工时并没有下降，那么大概率不是产能不足，而是产能被切碎。另一个合理解释是需求本身在变更，这时分池排期同样无效，需要先走变更流程。两种原因可以通过一个动作区分：连续记录两周内每个任务的实际起止时间和被打断次数，如果合同内任务的打断次数明显高于救火任务，说明是排期结构问题；如果合同内任务本身的需求描述前后不一致，说明是范围问题。
分池排期的具体做法：锁定产能加机动产能
假设一个团队每周可用于公司网站设计的产能是固定的，可以把其中大部分锁定给合同内任务，只留出一小部分作为救火机动池。这个比例不需要精确，关键是先定一个可执行的初始值，再按实际数据调整。例如假设每周可用产能为十份“半天工作量”，可以先锁定七份给合同内任务、留三份给救火任务；如果连续两周机动池都没用完，说明留多了，可以回收一部分；如果连续两周机动池在周中就用完，说明留少了，或者救火任务需要单独设门槛。
配套的动作是给救火任务设一个入口条件：发起人需要说明影响范围、是否可以等到下一个排期窗口、以及不处理的后果。这个动作的结果会直接影响下一步——如果多数救火任务在回答后被认为可以等，那它们应该进入常规队列而不是机动池；如果确实不能等，机动池才有存在意义。合同内任务一侧，则按里程碑而不是按天锁定，里程碑内部允许小幅调整，但跨里程碑的挪动需要走变更确认。
一个会让上述结论失效的反例
如果临时救火任务中有相当比例其实是合同内任务的返工，那么分池排期会把返工成本隐藏起来：合同内任务看起来按期推进，实际产出却不断被推翻重做，机动池被返工填满，团队仍然在加班。这种情况下，正确的下一步不是扩大机动池，而是把返工单独统计出来，回溯到需求确认、设计评审或验收标准这几个环节，找到返工集中出现的位置。
区分这两种情况的证据是：返工任务的描述里是否反复出现同一类问题，比如同一批页面在不同阶段被要求改版、或者验收时才发现某项功能不在合同范围内。如果返工集中在少数几个原因上，优先修流程；如果返工原因分散且每次不同，才适合用机动池吸收。
下一步可以立刻执行的动作
- 把当前所有未完成任务分成两类：合同内任务、临时救火任务，分别列出预计耗时。
- 为下一周设定一个初始的机动产能比例，并写下来。
- 给救火任务加一个入口问题：影响范围、能否等待、不处理的后果。
- 连续记录两周的实际耗时和打断次数，再决定是调整比例还是处理返工原因。
这个动作的结果会告诉你，问题出在排期结构还是需求质量上，从而决定下一步是继续调整产能分配，还是回到合同范围和验收标准去修正。
