软件外包怎么避免做到一半烂尾

外包项目烂尾，很少是因为技术做不出来。 更常见的是范围失控、验收标准模糊、源码不在自己手里、内部没人能拍板。这四件事，都能在开工前处理掉。

一、范围：把「先做着看」换成一张清单

「先把框架做出来，细节再补」听起来灵活，实际上是给后面所有争议留了一个口子：细节的边界由谁定，没有说清。

做法很简单： 合同附一份功能清单，每一项写清输入、输出和验收方式。清单之外的需求走变更流程，单独计价。这不是不信任对方，是让双方对「做完了」有同一个定义。

二、付款：绑里程碑，不要一次性

常见比例是 3:4:3 或 3:3:3:1（尾款留质保）。比例不是重点，重点是每个节点都对应一个可验收的产物：原型确认、核心功能可运行、整体验收。

如果对方要求开工付八成的款，这是一个信号。 要么现金流紧张，要么不打算给你留议价空间。两种情况都值得重新考虑。

三、源码：交付即入库，不要等到最后

最容易被绑架的地方是源码。 建议约定：代码从第一天起就放在双方都能访问的仓库里，交付时移交完整权限。这样即使中途换人，项目也不会归零。

同理还有域名、服务器、第三方账号——微信支付、短信、对象存储，全部用需求方的资质注册。这些账号在谁名下，决定了关键时刻谁说了算。

四、对接人：必须有一个能拍板的人

需求方内部意见不统一，是项目延期最常见的原因，而且这个原因通常不会被写进任何文档，只会表现为「再改一版」。

指定一个决策人，所有需求变更经他确认。 其他人可以提意见，但不直接对接开发。这一条能省掉后面一半的返工。

怎么判断一个外包方靠不靠谱

• 愿不愿意在合同里把验收标准写清楚，而不是含糊说「做到满意为止」
• 会不会主动提出分期和里程碑，还是只想要一笔预付款
• 能不能说清「这个需求我们不建议做」的理由
• 交付物里有没有文档和部署说明，还是只给一个能跑的包

最后

外包不是把活扔出去，是把边界定清楚。 边界清楚的合作，双方都轻松；边界模糊的合作，最后往往两败俱伤——甲方觉得钱花了没结果，乙方觉得改了无数遍还没完。