前面一家软件公司做了一半停了，或者做完了人联系不上，换个团队接着做，这在中途接手的项目里很常见。接手比自己从头做还麻烦，事前要谈的东西也更多。
一、先评估上一家留下的东西
接手之前，得先看清手里是什么货。这一步不做，报价就是瞎报。
要看的东西有几样。源码有没有、全不全、能不能跑起来。数据库结构清不清晰，有没有注释。代码是谁写的，风格统不统一，是不是拼凑的。原来的技术选型现在还流不流行，找不找得到人接手。
还有一种情况是上一家只做了设计稿，或者只做了原型，代码一行没有。这种其实接近于从零开始，报价方式要按新项目算，别被当成续做。
二、把责任边界划清楚
接手项目最容易扯皮的地方，是出了问题算谁的。
上一家留下的 bug，接手方修不修、算不算在报价里。这个必须提前说清楚。合理的做法是先做一轮代码审查和测试，把现有问题列个清单，双方确认。清单内的问题算在本次报价里，清单外的按变更处理。
如果没有这一步，后面系统一出问题，就是相互推。甲方说不该我出钱，接手方说是原来就这样。扯到最后，项目停摆，损失最大的是甲方自己。
三、数据和账号怎么交接
这部分是硬骨头，涉及原来的客户和合作方。
服务器、数据库、第三方账号，这些要在接手前确认能不能拿到。尤其是第三方接口的密钥，比如短信、支付、地图这些，往往绑在上一家的账号上。拿不到就得重新申请，有些还要重新走资质审核，时间成本不小。
数据迁移要单独评估。原来系统里积累的数据，要完整迁到新系统里，字段对不上、格式不一样的情况很常见。这块工作量经常被低估，谈的时候要专门列出来。
四、能不能找到上一家配合
如果上一家还联系得上，最理想的是让他配合交接。哪怕付一点费用也值得。
需要他配合的包括，交付源码和数据库、说明账号密码、介绍系统里那些没有文档的设计意图。有些代码看着奇怪，其实是有原因的，这些背后的原因只有写的人知道。花几天时间做交接，能省掉接手方大量的摸索时间。
如果上一家彻底联系不上，那就只能靠接手方自己啃代码。这种时候报价要留足余地，因为逆向理解别人写的系统，比重新做还费劲。
五、接手方案里要写明的东西
梳理完上面这些，接手方给的方案里应该有这几项。
- 现状评估结论，现有代码什么水平，能改还是要重做
- 工作范围，这次做什么，不做什么
- 问题清单，已知的缺陷有哪些，哪些本轮修
- 数据迁移方案，怎么迁、迁什么、风险在哪
- 工期和里程碑，中间能不能停下来看效果
有了这份东西，接手项目就从一件模糊的事变成了能管的事。该谁干的活清清楚楚，后面出问题也找得到依据。
一句话判据，接手项目最重要的一步是先把上一家留下的问题列成清单双方签字。清单没确认之前就开工，等于给自己埋雷。