项目延期后,先不要急着换公司,也不要直接认定是某一方拖延。更有效的做法是把延期拆成“需求变更、等待确认、技术返工、外部依赖”四类,逐项对照时间记录,找到真正消耗工期的环节。下面用一个假设例子说明定位过程。
假设你委托一家建站公司做企业官网,合同约定第30个工作日上线。实际到第44个工作日才交付。项目经理说“你们改需求太多”,你记得只提过两次小调整。这时可以按下面的步骤核对,而不是争论谁对谁错。
如果发现设计定稿后第5天又新增了一个栏目,开发因此重做模板,这属于需求变更导致的延期;如果确认稿早就签字,开发仍按旧版做,那属于执行偏差。两种原因的沟通对象和处理方式完全不同。
方案一:补签变更单,顺延工期。适用于需求确实在确认后新增或修改,且双方都认可变更内容。做法是把新增项、影响天数、是否加费用写进补充确认,避免下次再扯皮。
方案二:要求对方给出追赶计划。适用于需求未变、延期来自对方排期或返工。可以要求列出剩余任务、每日可投入人力、关键节点日期。如果对方只能给“尽快”这类答复,说明其内部没有可执行的排期。
判断用哪种方案,关键看一条:变更是否发生在对应环节确认之后。确认前提出的调整属于正常协作,确认后提出的才计入变更;反过来,确认后对方仍做错,责任在执行方。
还有一类容易被忽略:第三方依赖。比如域名解析、服务器备案、支付接口审核,这些环节的耗时往往不在建站公司控制范围内。定位时要单独列出,并记录提交时间和对方反馈时间。
下次沟通前,先填完这张表,再决定是补签变更还是要求追赶:
填完后通常能看出延期集中在哪一段。如果集中在确认环节,优先改沟通节奏;如果集中在开发返工,优先谈排期和验收标准;如果集中在外部审核,只能调整上线预期。
把上面这张表发给建站公司的项目负责人,约定一次30分钟的复盘,只讨论“哪一天卡住了、下一步谁在什么时候交付什么”。复盘后如果对方仍给不出具体节点,再考虑是否更换合作方,而不是在延期初期就仓促换人,那样往往把已完成的进度也浪费掉。