把合同内任务和临时救火任务放进同一张待办清单,通常是排期失控的起点。更可执行的做法是:合同任务按交付周期占槽位,救火任务按影响面决定是否插队,并强制记录插队造成的合同任务顺延。判断排期是否合理,不看当天完成了多少条,而看被顺延的合同任务有没有明确的补位日期。
合同内任务的排期依据是交付节点,比如月度内容产出、阶段性技术整改、固定周期的数据复盘。这类任务的完成时间可以提前约定,适合用固定槽位管理。临时救火任务的排期依据是影响面,比如核心页面无法访问、结构化数据大面积报错、重要落地页流量异常下滑。这类任务无法提前预知,适合用触发条件管理,而不是塞进日常清单里按顺序排队。
两类任务混排时,最常见的错误是用同一个优先级标准。合同任务因为“早就约定”而被默认不紧急,救火任务因为“现在不做就出事”而被默认最高级。结果是合同任务持续顺延,救火任务持续插队,团队始终在应付眼前问题。排期要解决的不是谁更重要,而是谁在什么条件下可以让路。
不是所有临时任务都值得打断合同排期。可以先按三个问题过滤:影响的是单个页面还是整站可访问性;影响的是已经产生转化的页面还是尚未上线的页面;不处理的话,损失是持续累积还是一次性波动。三个问题都指向影响面小、可延后,就放进下一个合同周期的缓冲时段,而不是立刻插队。
如果判断结果指向必须插队,动作是记录插队起止时间和被挤掉的合同任务编号,并当场给出补位日期。这个动作的结果会直接影响下一步:如果补位日期能落在本周内,合同交付节奏基本不受影响;如果补位日期只能排到下周,就需要提前和需求方沟通交付顺延,而不是等到交付日再解释。
假设某月合同内任务包含四篇页面优化和一次技术整改,救火任务出现两次。第一次救火影响核心产品页收录状态,判断为必须插队,占用半天,被挤掉的页面优化补位到次日上午。第二次救火只是后台某个统计字段显示为零,判断为可延后,放进缓冲时段核查。两次救火的处理方式不同,合同任务只顺延了半天。这个对照说明:插队本身不是问题,插队后没有补位才是问题。
如果合同排期排满,任何临时任务都会造成顺延。更稳妥的做法是在合同周期内预留固定比例的缓冲时段,专门承接影响面中等的临时任务。缓冲时段的比例取决于业务波动程度:流量来源集中、页面数量少的站点,缓冲可以少一些;页面数量多、依赖多个渠道引流的站点,缓冲需要多一些。
缓冲不能无限扩大,否则合同交付会被持续侵蚀。可以设一条判断线:当某个周期内缓冲时段被临时任务占满,且合同任务已经顺延两次以上,就说明当前排期结构不适合继续硬扛,需要考虑调整合同范围、增加交付周期,或者把部分临时任务转为下一周期的合同任务。这条判断线的作用是让排期问题提前暴露,而不是等到交付日才暴露。
当合同任务和救火任务持续冲突时,通常有三种取舍方向,各自适用前提不同。
三种方向没有通用答案。判断依据是连续几个周期内合同任务的顺延次数和临时任务的影响面分布,而不是某一次救火任务处理得快还是慢。
排期是否合理,不能靠“最近好像很忙”来判断。可以记录三类信息:每次临时任务的触发时间、影响面判断结果、是否插队;每次插队造成的合同任务顺延天数和补位日期;每个周期结束时缓冲时段的占用比例。这些记录不需要复杂工具,一张按周更新的表就够。
记录的作用是区分不同解释。比如某周合同任务没有按时完成,可能是因为救火插队,也可能是任务本身工作量估计不足,还可能是等待需求方确认耽误了时间。只有把插队记录和顺延记录放在一起看,才能判断问题出在排期结构还是执行环节。如果没有记录,很容易把执行问题误判为排期问题,或者反过来。
当记录显示合同任务顺延主要来自插队,下一步就是收紧插队判断标准或扩大缓冲;当记录显示顺延主要来自任务本身估计不足,下一步就是调整合同任务的粒度,而不是继续压缩救火响应时间。排期调整的方向,应该由记录指向的原因决定,而不是由当天最紧急的任务决定。