本文定位：失败复盘。案例来自一次已脱敏的软件项目救火经历，文中不指向具体客户或供应商。我们更关心“为什么会拖”和“怎么止损”，而不是把责任简单推给某一方。
这个项目原计划 10 周上线，实际拖了 3 个多月。刚接触时，甲方老板的判断很直接：“开发太慢，供应商不靠谱。”但我们把需求文档、聊天记录、原型、代码和会议纪要看完后，发现问题没有这么简单。
项目延期 3 个月，表面是开发慢，真实是范围失控、验收缺失、决策拖延和数据迁移低估叠在一起。 如果只换一批程序员，不改项目管理方式，大概率还会再延期一次。
一、表面现象：10 周上线，拖到第 22 周还没法验收
项目是一套面向内部业务的定制管理系统，范围包括客户台账、订单流程、审批、库存扣减、财务对账和基础报表。合同写的是“10 周完成一期上线”，但第 10 周时，系统只能跑通 40% 主流程；第 16 周时，功能看起来多了，但测试一走业务场景就断；第 22 周时，老板已经失去耐心。
甲方看到的是这些现象：
- 页面做了很多，但关键流程跑不通；
- 每次测试都会发现新问题；
- 供应商说“这个需求之前没说”，业务说“这不是常识吗”；
- 数据导入后大量字段对不上；
- 会议纪要里问题越来越多，但关闭率很低。
这种状态在定制开发里很常见。它最危险的地方不是延期本身，而是大家都觉得自己有理：供应商觉得需求一直变，甲方觉得对方连基本业务都不懂，老板觉得花了钱却看不到结果。
二、错误判断：一开始以为“加人就能赶回来”
项目第 12 周时，双方第一次尝试补救：供应商加了 2 个开发，甲方每天开进度会。结果两周后进度没有明显改善，反而 bug 更多。
为什么加人没用？因为当时真正缺的不是代码产能，而是四件事：
- 一期到底必须上线哪些流程；
- 每个流程验收时按什么数据、什么角色、什么边界测试；
- 需求变更由谁拍板，是否影响工期；
- 历史数据哪些必须导，哪些可以不上线后再补。
这些问题不解决，新增开发只会让更多人在不确定范围里写代码。项目管理里有一句老话：向延期项目盲目加人，常常只会让项目更延期。 对企业软件尤其如此，因为很多卡点不是技术问题，而是业务决策问题。
三、真实根因：四个环节同时失守
1. 需求边界没锁，导致“一期”无限膨胀
合同里写了很多模块名，但没有写清每个模块的一期边界。例如“订单管理”到底包括新增订单、订单变更、订单取消、拆单、合单、退货、补差价、导入导出中的哪些？合同没写，原型也没锁。
于是业务测试时不断补充：“我们实际还有这种情况。”供应商如果拒绝，关系紧张；如果接受，工期失控。最后一期变成一个不断扩张的篮子，什么都往里装。
2. 验收标准没写，导致“差不多能用”无法落地
验收标准不是“页面完成”或“功能开发完成”，而是具体场景能跑通。比如订单审批，至少要写清：谁发起、谁审批、金额超过多少走谁、驳回后回到哪一步、审批通过后是否扣库存、是否通知财务。
这个项目没有验收用例，只有一个笼统清单。每次测试都像第一次发现业务规则，导致开发不断返工。
3. 关键人不拍板，导致问题长期悬空
很多争议不是程序员能决定的，比如库存允许负数吗、老客户信用额度怎么算、历史欠款是否导入系统、审批可以跳级吗。这些问题需要老板、业务负责人或财务负责人拍板。
但项目里没有固定决策机制，问题经常在群里讨论几天没人定。开发只能先按一种理解做，后面关键人一看“不对”，再推倒重来。
4. 数据迁移被低估，导致上线前集中爆雷
甲方以为数据迁移就是“把 Excel 导进去”。实际打开表后才发现：客户名称重复、商品编码缺失、历史订单状态不一致、库存数量和财务账对不上。供应商也没有在前期安排数据体检，等到上线前才集中处理。
这类问题我们在 AI Agent 没有业务数据的失败复盘 里也讲过：系统不是魔法，脏数据不会因为换了界面就自动变干净。
四、补救动作：先止血，再重排优先级
救火时，我们没有继续追求“把原合同所有东西做完”。第一步是开一个 2 小时止血会，只做三张清单。
清单一：上线必须项
把所有功能分成三类：
| 分类 | 判断标准 | 处理方式 |
|---|---|---|
| 必须上线 | 不做就无法跑主业务 | 进入 3 周救火版本 |
| 可延后 | 影响体验但不影响主流程 | 放到二期 |
| 先砍掉 | 使用频率低或规则未定 | 不进入当前计划 |
最后原来 60 多个需求点，第一版只保留 23 个。老板一开始担心“砍太多不值”，但我们解释：如果 23 个核心点跑不通，60 个点只会造成更大混乱。
清单二：验收用例
每个必须项都补一条验收用例，格式固定：角色、前置数据、操作步骤、预期结果、异常边界、验收人。例如“销售提交订单—主管审批—库存扣减—财务生成应收”必须用同一组测试数据跑完整链路。
验收用例的价值在于减少争吵。它让“你没做好”和“我没说清”变成可验证的事实。
清单三：决策问题
把所有悬而未决的问题列出来，每个问题只允许一个决策人，给出截止时间。超过截止时间未决，就按默认方案执行，并记录为二期可调整项。
这一步很关键。很多延期项目不是没人干活，而是没人拍板。项目经理的职责不是替老板做业务决策，而是把需要老板拍板的问题推到桌面上。
五、救火后的上线方式：小范围试跑，不再全员切换
我们建议客户不要全公司一次性上线，而是选一个业务小组试跑 2 周。试跑期间旧流程保留，但新订单必须进系统；历史数据只导入试跑范围需要的数据，不追求一次性全量清洗。
试跑看三个指标：
- 主流程是否能从新建订单跑到对账；
- 关键异常是否能记录并关闭；
- 业务人员是否愿意用系统完成当天工作。
两周后，项目没有“完美上线”，但终于从无限延期变成可控迭代。后续又用 4 周补了报表、批量导入和部分自动提醒。相比继续按原计划硬拖，这种方式更快恢复了老板和团队的信心。
六、下次避免：合同前、上线前、验收前分别做什么
合同前：别只看报价，要看范围拆解
签约前至少要求供应商给出模块边界、阶段交付物、甲方配合事项和变更规则。不要只接受“客户管理、订单管理、库存管理”这种模块名。模块名不等于需求边界。
如果你还在选服务商，可以先读 软件定制开发公司怎么选；如果你在比报价，建议看 软件定制开发多少钱。这两篇能帮你把“便宜”和“靠谱”分开看。
上线前：先做数据体检
所有要导入的数据，至少提前 2-3 周体检：重复、缺失、编码、状态、金额、日期、责任人。数据问题越晚发现，代价越高。不要把数据迁移当成上线前一天的杂活。
验收前：用业务场景验收，不用功能列表验收
验收时不要问“按钮能不能点”，要问“从销售接单到财务对账能不能完整跑通”。功能列表适合开发排期，业务场景才适合验收。
复盘时：责任中性，但动作必须具体
复盘不是为了证明谁错，而是为了下次不再错。建议把每个延期原因都落到动作：需求边界怎么写、谁能拍板、变更怎么记录、数据谁维护、验收用例谁签字。
七、软件项目延期救火清单
如果你的项目已经延期，可以直接照这个顺序开会：
- 列出所有未完成需求，标记必须、延后、砍掉；
- 为必须项补验收用例；
- 列出所有悬而未决问题，指定唯一决策人；
- 检查源码、数据库、部署权限是否可控；
- 做一次数据体检，别等上线前；
- 排一个 2-4 周止损版本；
- 小范围试跑，不要全员硬切；
- 每周只看问题关闭率和主流程通过率。
如果源码和数据权限都在对方手里，还要立刻确认所有权。关于这一点，我们在 定制开发 服务页和多篇选型文章里反复强调：源码和数据归属不清，延期项目会变成被动项目。
八、复盘证据表：延期项目先判断还能不能救
| 复盘项 | 本案表现 | 救火动作 |
|---|---|---|
| 表面现象 | 原计划 10 周上线，拖到第 22 周仍无法验收，群里每天都在催“还差一点”。 | 先停止新增需求，把所有事项分成上线必须、延后、砍掉。 |
| 真实根因 | 需求边界、验收标准、关键人拍板、数据迁移四个环节同时失守。 | 为必须项补业务验收用例，为悬而未决问题指定唯一决策人。 |
| 补救动作 | 用 2 周小范围试跑替代全员硬切，历史数据只导入试跑范围需要的数据。 | 每周只看主流程通过率、问题关闭率和数据差异清单。 |
| 下次避免 | 合同前写清范围和变更规则，上线前做数据体检，验收前按业务场景走用例。 | 可以对照定制软件验收标准和需求澄清清单提前补课。 |
| 救火 CTA | 如果源码、数据库、部署权限都不清楚，不要急着换供应商，先判断资产能否接管。 | 带合同、原型、当前系统截图、权限清单来做一次 1-2 周诊断。 |
九、CTA：带当前项目做一次救火诊断
如果你的软件项目已经延期，不建议上来就问“换不换供应商”。更好的问题是：现有成果还能不能用？一期范围能不能收口？哪些数据必须先清？谁能拍板？源码和数据库能不能拿到？
你可以带着合同、需求清单、原型、当前系统截图和最头疼的 10 个问题来聊。我们会先判断项目是适合救火、适合重排，还是应该止损重做。也欢迎先看 客户案例 和 更多失败复盘，对照自己的项目处在哪个阶段。
