核心做法是把两条排期线分开:合同内任务按里程碑占用固定档期,临时救火任务只进入预留的应急档期,并且先判断它是否属于合同范围。这样做的直接结果是,临时任务不会自动挤掉已承诺的交付日期,同时你也能看清哪些救火其实应该走变更单而不是插队。
排期冲突往往不是时间不够,而是双方对同一件事的理解不同。你说“页面打不开了”,外包方理解成服务器故障;外包方说“本周排满了”,你理解成拒绝处理。把分歧转成可核对的项目,第一步就是让每个临时任务落到具体对象上:哪个页面、哪个表单、哪个账号、什么现象、从什么时候开始。
判断是否属于合同范围,可以按下面几个问题逐项核对:
如果核对下来属于合同内交付物的缺陷,它应当走修复流程,占用的是合同内任务的档期;如果是新增功能或第三方原因,就应按变更或另行安排处理。这个判断动作会直接影响下一步:走修复的进入原排期,走变更的进入应急档期或单独报价,两者不混在同一张时间表里。
合同内任务的排期依据是交付节点,而不是每天做了几小时。常见节点包括:结构确认、视觉确认、模板完成、内容录入、上线前检查。每个节点对应一个可验收的产物,比如一份栏目结构表、一套页面模板、一份检查记录。
假设一个情境:合同约定六周完成企业站,第三周应交付首页和内页模板。到第二周末,甲方临时要求增加一个多语言切换。这个需求没有写在合同里,属于新增。如果把它塞进合同内档期,模板交付节点就会顺延,后续内容录入和上线检查全部受影响。更稳妥的做法是先把多语言切换记为变更项,评估它需要改动导航、模板和内容结构,再决定是并入本轮还是放到上线后。
里程碑排期的关键动作是:每个节点前确认上一节点的产物是否验收。验收通过,下一节点才占用档期;验收未通过,延期责任和补救方式要写清楚。这样临时任务出现时,你能立刻知道它会顶掉哪个节点,而不是笼统地说“往后拖一拖”。
救火任务的特点是突发、优先级高、范围不清。如果它和合同内任务共用同一批时间,排期一定失控。可行做法是在每周或每个迭代里预留一段应急档期,只处理经过判断的救火项,并规定进入条件。
可以按这个顺序处理:
这里有一个取舍:应急档期留得越多,合同内任务的可用时间越少;留得太少,救火就会挤占正常交付。一个可操作的判断方法是看过去几个迭代里真正需要紧急处理的事项有几类。如果多数是第三方服务或账号问题,应该先补的是信息同步和权限管理,而不是无限扩大应急档期。
多个角色对同一事实有不同理解时,争论“谁对谁错”没有意义,要把说法变成可核对的项目。例如运营说“表单提交后没收到通知”,开发说“接口正常”。可核对的项目包括:提交时间、使用的邮箱、通知收件地址、垃圾邮件目录、接口返回记录。核对后可能发现是收件规则问题,也可能是接口配置问题,两者的处理路径完全不同。
建议每次排期前维护一张对照表,至少包含:任务来源、合同内还是合同外、影响页面或功能、期望完成时间、占用哪个档期、验收方式。这张表不需要复杂工具,重点是让双方对同一行文字有相同理解。当临时任务出现时,先填表再排期,能避免“先做了再说”带来的返工。
临时任务插入后,仅仅把合同内任务的日期往后改是不够的。你需要同步说明三件事:被影响的是哪个交付节点、后续哪些任务需要跟着调整、是否需要补充变更确认。如果只改日期不说明影响,下一轮还会出现同样的冲突。
假设应急处理占用了两天,原定本周完成的模板检查顺延。此时应确认:内容录入是否依赖模板检查结果,如果依赖,录入也要顺延;如果不依赖,可以并行推进。这个判断决定了后续是整体顺延还是局部调整。把影响写清楚,再决定是否接受新的完成时间,排期才真正可执行。
最后提醒一点:请求量、工单量或某类任务突然归零,不能单独证明排期处理正确。它也可能是需求本身减少、沟通渠道改变或统计口径变化。判断排期是否有效,要看合同内节点是否按约定验收、临时任务是否有明确归属,而不是只看某一项数字的升降。