网页设计外包：合同内任务和临时救火任务怎样分别排期
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /f1e1aed44a14.html
📄
网页设计外包：合同内任务和临时救火任务怎样分别排期
结论是：合同内任务按里程碑倒排，临时救火任务按影响面插队，但两者必须共享同一份容量账本。只有当救火任务每周占用不超过总工时的两成、且不影响最近一个里程碑时，这套分排方式才成立；一旦救火连续两周超过这个比例，合同内任务的排期就会整体后移，此时应停止插队，转为变更单或延期协商。
合同内任务：按里程碑倒排，而不是按提交顺序排
合同内任务的排期起点不是“谁先提”，而是合同里写明的交付节点。把每个节点拆成可验收的产出物，再倒推所需工时，才能看出每周真正可用的余量。
- 先列出本周期所有必须交付的页面或模块，标注各自的验收标准。
- 按依赖关系排序：设计稿未确认的，不能进入前端排期；接口未就绪的，不能进入联调排期。
- 把每周可用工时填满到约八成，剩下两成留给救火，不要排到十成。
这里的关键动作是给每个里程碑标注“最晚开始日”。一旦某任务的开始日被推到最晚开始日之后，就说明余量已经耗尽，后续任何插队都必须走变更流程，而不是继续挤占。
临时救火任务：先定影响面，再决定插队位置
救火任务不能一律“最优先”。先问三个问题：影响的是线上可用性、转化路径，还是仅影响观感？是否阻塞合同内任务的验收？能否用临时方案先顶住？
- 影响线上可用或核心转化：立即插入当天排期，同时把被挤占的合同内任务标记为“待重排”。
- 影响观感但不阻塞验收：放入本周剩余的两成缓冲，不占用合同内任务工时。
- 仅影响个别页面且可延后：登记为待办，进入下一周期统一评估，不单独插队。
假设一个场景：某外包团队每周可用工时约为合同内任务安排的四天、缓冲一天。第一周救火占半天，合同内任务不受影响；第二周救火占两天，缓冲被击穿，合同内任务开始后移；第三周救火仍占两天，此时应触发变更单，而不是继续压缩合同内任务。这个假设说明的是判断方法，不是真实项目数据。
反例：小样本下可行，规模化后会失效
如果只有一两个救火任务，靠个人经验插队通常能维持。但当同时进行的合同内任务超过三条、或救火来源超过两个对接人时，口头排期会失效。原因是救火任务的优先级判断分散在不同人手里，没有人能看到总容量。
此时不能照搬“先到先排”或“谁催得急谁优先”。应改为统一入口加每日一次排期确认：所有救火任务先登记影响面和期望完成时间，再由同一负责人对照容量账本决定插入位置。若登记后发现本周缓冲已满，就只保留影响线上可用性的任务，其余顺延。
下一步：用一张容量表把两类任务分开
具体动作是建立一张按周维护的容量表，包含三列：合同内任务计划工时、救火任务实际占用、剩余缓冲。每周结束时更新一次，并对照最近一个里程碑的最晚开始日。
如果剩余缓冲连续两周低于总工时的两成，下一步不是继续加班，而是与对方确认：哪些合同内任务可以延期、哪些救火任务可以转为正式变更。这个动作的结果会直接决定下一周是恢复原排期，还是重新签订交付节点。
