"项目做到一半发现交付遥遥无期"——这是很多企业第一次做软件外包时都会撞上的现实。本文不讨论为什么会延期(那是另一篇长文),而是聚焦更有用的问题:已经发现苗头后,该怎么办?以及下一次怎么提前避免?

先判断:是真延期还是节奏偏差

并非所有"延期"都需要紧急挽救。一周以内的偏差,在敏捷迭代中属于正常波动。但如果出现以下三类信号,基本可以认定为真延期:

• 关键里程碑(原本确定的中间节点)整体推后 2 周以上;
• 团队每周可演示的产出持续缩水,或质量明显下滑;
• 核心岗位频繁换人、需求频繁推倒重来。

识别出真延期后,真正能救项目的不是"催",而是下面 3 步。

紧急挽救第 1 步:开一次"裸奔会"

别再开例行周会,开一次"裸奔会":双方把当前真实进度、各自困难、未完成项摊开来说。甲方承认需求变更频次,乙方承认人力/技术债问题。务实地列一张表:已交付/在做/未做/可砍/必保。这是后续一切动作的事实基础。

成都做软件开发的团队,真正有经验的项目经理在延期信号出现时会主动约这场会议;反之,越是回避沟通的乙方,越要警惕。

紧急挽救第 2 步:砍需求、定优先级

原计划 50 个功能,先砍到能真正上线的 20 个核心功能。每砍一项都要经过"不做会怎样"的拷问。剩余时间按"必保 15 项 + 尽量做 5 项"两档分配,必保项优先用最优资源。

这种取舍本身对软件外包前要做的5项准备中所提的需求文档有反作用——下次做需求时,要主动分级:P0 必做、P1 尽量、P2 迭代期。先做 P0,后做 P1,P2 视情况。

紧急挽救第 3 步:换关键人、加投入、找外援

三种救火路径,根据项目情况选其一或组合:

• 换关键人:项目经理或某核心开发力有不逮时,与外包公司协商更换,要求新人 1 周内交接完毕;
• 加投入:把交付压缩期增加 2-3 名熟手短期冲刺,但要做好代码规范统一,避免后期合并灾难;
• 找外援:从外部借调某模块的资深工程师,只做关键模块。前提是代码托管权在甲方手中。

预防机制 1:立项阶段把"延期高发点"写进合同

常见延期高发点包括:需求变更未约定流程、原型未冻结、第三方接口不稳定、审核周期未预留。把每一条对应的责任/工时评估方式写进合同,可直接减少 60% 以上的争议。

预防机制 2:里程碑付款,不用大尾款

"上线后付 30%" 是一颗定时炸弹:乙方没动力收尾。建议把里程碑切成 4-6 个:原型验收 20%、UI 验收 15%、主体功能验收 25%、测试通过 20%、上线稳定 20%。这种结构下,乙方每个节点都有收益,延期每多一周,损失会立刻显化。

预防机制 3:每周一次 30 分钟视频同步

不开 2 小时周会,每周固定时间 30 分钟视频,只看三样:本周做了什么、本周遇到什么阻碍、下周要做什么。30 分钟的会议反而比周报更能看到真实进度。

预防机制 4:任何变更走书面流程

口头变更最容易引发延期争议。微信说一句"加个打印按钮",3 周后乙方说"这不在原需求里,要加钱"。建议建立一张变更单(变更内容/工时评估/费用/双方确认),所有变更走单子。

预防机制 5:每个里程碑做"用户可演示版"

别等全部做完再演示。每 2-3 周产出一个"可用版本",甲方在自己手机上跑一遍。早期问题暴露得越早,延期风险越小。

预防机制 6:复盘文档,写给未来的自己

每个里程碑结束后写一份 1-2 页的复盘:实际工期 vs 计划工期、偏差原因、改进项。下次立项时翻一翻,你会避开至少一半常见的坑。

小结

延期不是世界末日,但需要正确的处置流程:先识别真伪,再"裸奔会"对齐事实,然后砍需求/换关键人/加投入。最后记住:每一次延期都是下一次立项的礼物,把复盘写到能搜到的位置。

中方互动科技在成都软件外包服务中,把 6 项预防机制嵌入合同模板,已交付的项目延期率明显低于行业平均水平,欢迎企业客户咨询交流。

延伸阅读:成都软件外包 · 外包前5项准备 · 外包vs自建