挽救停滞的软件项目并安全更换供应商

项目开始时充满热情。双方约定了进度，支付了预付款，第一次演示看起来很有希望。几个月后，进展汇报越来越少，截止日期一再推迟，号称已完成的功能漏洞百出，每个问题得到的回答都是“下周就好”。这种情况比许多人愿意承认的更常见，也常让企业主陷入两难：继续、停止，还是换一家供应商？

本文是一份实用指南，帮助您评估停滞的软件项目、做出正确决定，并在必要时更换供应商，同时不丢失已付费完成的工作。我们将介绍危险信号、如何进行客观评估、可选的决策、交接准备，以及如何避免下一个项目重蹈覆辙。

要点

• 尽早识别危险信号：无法验证的进度、不断推迟的截止日期以及下降的质量
• 做决定之前，先对代码、基础设施和文档进行独立的技术评估
• 选择不只有继续或停止；还可以共同整改、由新团队接手救援，或部分重来
• 在与原供应商关系恶化之前，先确保掌握代码、服务器、域名和第三方账号的访问权
• 救援项目要成功，必须专注于稳定和现实的优先级，而不是追赶全部原定计划

软件项目出问题的迹象

问题很少突然出现。通常会有一些小迹象，若能及早识别，就能争取到行动时间。请留意以下模式。

• 进度只用百分比或文字汇报，没有可以亲自试用的应用版本
• 截止日期一再推迟，却没有具体说明原因
• 已宣布完成的功能在新增其他功能后又出故障
• 您没有代码仓库的访问权，甚至不知道代码存放在哪里
• 供应商团队成员频繁更换，每来一个新人都要从头解释
• 技术问题得到的回答含糊或被转移，风险从未被公开讨论
• 在范围没有明确变化的情况下出现追加账单

单一迹象并不一定意味着项目失败。每个项目都会遇到延误。真正需要警惕的是多个迹象同时出现且持续存在。

第一步：保护好您的资产

在做出重大决定之前，也在与供应商的沟通变得紧张之前，请确保您的数字资产安全。这不是敌对行为，而是任何项目都应有的谨慎。

• 源代码：要求获得代码仓库的访问权，或至少拿到包含变更历史的完整代码副本
• 基础设施：云账号、服务器和数据库应以贵公司名义开设，管理员权限掌握在您手中
• 域名与证书：确保域名注册在公司名下，并掌握域名注册商的访问权
• 第三方账号：应用商店、支付网关、邮件服务、地图以及应用使用的其他服务
• 凭证：列出所有密码、API 密钥和其他机密信息，并计划在交接后全部更换
• 文档：需求、设计、会议纪要以及现有的任何技术文档

查阅合同，了解关于代码归属、交接义务和终止合作方式的条款。如果合同不明确，请先咨询法律顾问再采取行动。这也说明了为什么在任何项目开始时，都应重视合同中关于归属和交接的条款。

进行客观的技术评估

好的决定需要对项目状况有诚实的认识。评估最好由未参与项目的一方进行，例如技术顾问或潜在的新供应商，以避免偏见。充分的评估涵盖以下几个方面。

代码状况

代码结构是否清晰、其他开发者能否看懂？有没有自动化测试？所用技术是否主流且仍受支持？是否存在把密码直接写在代码里或明显安全漏洞等危险做法？糟糕的代码不一定非要丢弃，但会影响继续开发的成本。

真正可用的功能

把需求清单与测试环境中真正可用的功能进行对比。将每个功能归类为：已完成且稳定、存在但有问题，或尚未实现。结果往往与进度百分比报告相差甚远。

基础设施与发布流程

应用如何运行、部署和监控？开发、测试和生产环境是否分开？发布流程能否由其他人重复执行，还是只有一名开发者知道？自动化测试与 CI/CD 以及可观测性等实践是成熟度的指标。

数据与安全

如果应用已经投入使用，请检查数据状况、备份和访问安全。无论接下来做何决定，这方面的问题都必须优先处理，因为它们直接威胁企业和客户。还要检查过时的第三方库，详见我们关于软件供应链安全的文章。

可选的决策

根据评估结果，可以选择以下几条路径，每条都适合不同的情况。

与原供应商共同整改

如果代码质量尚可，主要问题在于沟通或管理，可以尝试整改。重新确定优先范围、可验证的演示节奏、代码仓库访问权，以及未来几周的明确基准。如果达不到基准，您就有了采取下一步行动的充分依据。

由新团队接手救援

如果代码基础仍然可用，但原供应商无力或不愿继续，可以由新团队接手。新团队通常先理解代码、稳定问题区域、补充测试，然后按重新制定的优先级继续开发功能。

部分或全部重来

如果代码极差、不安全，或采用了无法维持的技术，从长远看重建可能更便宜。这个决定很艰难，因为感觉像是丢掉了投资，但之前的工作依然有价值：经过验证的需求、界面设计，以及哪些做法行不通的经验。最佳选择往往是两者结合，例如保留数据库和设计，同时重写问题最严重的部分。

停止或简化项目

有时评估会发现业务需求已经改变，或现成软件如今更合适。停止项目、改用现成软件并不是失败，而是理性的决定。正确的问题不是已经花了多少钱，而是从现在起哪个选择能带来最好的结果。

向新供应商交接

如果决定更换供应商，有序的交接可以节省大量时间和费用。尽量与原供应商保持专业关系，因为他们在过渡期间的配合非常有帮助。

1. 01约定交接时间表，以及与资产交付挂钩的尾款
2. 02接收包含变更历史的完整代码、数据库脚本和环境配置
3. 03请原供应商的开发人员进行技术讲解，最好录下来
4. 04把云账号、域名和第三方服务的所有权转移到贵公司名下
5. 05权限转移后更换所有凭证
6. 06请新供应商验证能否用交付的代码运行并重新部署应用
7. 07记录已知问题和未完成工作的清单

验证这一步至关重要。许多看似完整的交接，事后发现缺少配置文件、脚本或只有原开发者知道的手工步骤。在与原供应商的关系真正结束之前，确保新供应商能够从零构建应用。

开展救援项目

救援项目与新项目不同。初期的重点是稳定和信任，而不是加功能的速度。

• 先求稳定：修复严重缺陷、保护数据、建立基础监控
• 与企业主一起重新排定优先级：上线真正需要哪些功能
• 在修改最常出故障的部分之前先为其补充测试
• 以可定期检查的小批量方式发布
• 用真实演示而不是百分比来汇报进度

向内部相关方坦诚沟通救援计划。说明发现的情况、新的优先级以及附带假设的预计进度。从一开始就建立现实的预期，远好于再次落空的乐观承诺。

可以考虑先上线一个精简版本，再逐步完善。MVP 方法能让已经延误的项目更快产生价值，同时重建内部团队的信任。上线前进行用户验收测试，避免把问题转嫁给客户。

防止同样的问题再次发生

停滞的项目是一堂昂贵的课。用它来改进您今后与任何供应商的合作方式。

• 从第一天起就自己掌握代码仓库、云服务、域名和第三方账号的访问权
• 要求定期演示您可以亲自试用的版本
• 把付款与可验证的成果挂钩，而不是与经过的时间挂钩
• 指定一名积极参与的内部产品负责人
• 在交付大项目之前先做试点项目
• 用[结构化的清单](/checklist)选择供应商，而不是只看价格

如果您考虑选择其他城市或国家的供应商，同样的原则依然适用。我们的指南把软件开发外包到印尼介绍了合作模式，以及如何让跨地点项目保持透明。

结论

软件项目停滞并不意味着走到了尽头。先保护资产，进行客观的技术评估，基于数据选择路径，并执行有序的交接，大部分已投入的资金都可以挽回。

最重要的是尽早行动。问题拖得越久，成本越高，恢复也越困难。如果已经出现危险信号，请现在就申请独立评估，趁您还有很多选择。