外包做了一半要换公司？接手项目的7步评估法

接手半成品软件项目这件事，通常发生在项目已经做了一半、钱付了三成、上线日期逼近的时候。此时最危险的不是重新开发要花多少钱，而是没人能说清「现在这套东西到底还能不能用」。有的项目拿回来只有一份部署包，源码在东家手里；有的项目代码在手但跑不起来，因为缺了数据库配置和第三方密钥；还有的看起来能跑，但一加功能就崩，因为底层结构从第一天就是错的。

聚辉软件在十年里接接过不少这类「半成品」项目，也在项目交接时把完整交付物交出去过。下面是接手半成品软件项目的一套评估方法，站在接手方立场：先体检，再决定是续建、重构还是重做——这三个选择的成本可能相差三倍。

一、接手前的第一份清单：你到底拿到了什么

不要先看代码，先清点资产。一份完整的软件资产包括七样，缺任何一样都会变成后续的隐性成本：

• 源代码与版本历史：不只是最终代码，还包括git或svn的提交记录。没有历史意味着你无法知道哪段代码是临时补丁。
• 数据库结构与数据：建表语句、字段说明、索引设计，以及是否包含真实业务数据。只有数据没有结构文档是最麻烦的情况。
• 第三方账号与服务：云服务器、域名、短信、支付、地图、推送、对象存储。这些往往注册在上一家公司的账号下，交接时最容易被遗漏。
• 接口文档：对内对外的API说明，包括与硬件、ERP、支付平台的对接参数。
• 部署与运维文档：环境要求、部署步骤、定时任务、日志位置、备份策略。
• 设计源文件：Figma或Sketch的原始文件，而不是切好的图片。改版时没有源文件等于重画。
• 需求与变更记录：确认过的功能清单与历次变更，它是判断「现在缺什么」的唯一依据。

能拿到几样，直接决定了后续报价的差异。缺少源码的项目本质上不是接手，是重做，报价时不该被当成续建来谈。

二、代码体检看四件事，不必读全部源码

不需要逐行读代码，行数多少也不说明问题。有经验的团队通常用半天到两天做四项检查：

能不能跑起来。这是最基本也最常卡住的一项。把代码拉到本地或测试服务器，按文档部署，看是否能在合理时间内启动。跑不起来的原因往往暴露真实状况：依赖缺失、配置文件缺失、用了已停服的旧版本环境。

架构是否可扩展。看三处：数据表是否有清晰的业务边界（还是几十个字段堆在一张表里）、业务逻辑是否集中在少数文件（还是散落在页面代码里）、有没有基本的分层。这些决定了加一个新功能是两小时还是两天。

有没有明显的技术债。硬编码的地址与账号、被注释掉的整段逻辑、没有版本管理的数据库变更、直接写在页面里的SQL。这些不是绝对不能碰，但每一项都要计入后续维护成本。

测试与文档的覆盖程度。有没有自动化测试、有没有接口文档、关键流程是否有说明。覆盖率低不代表要重构，但意味着每次改动都靠人肉验证。

三、三个选项：续建、重构、重做

体检结果出来后，决策可以规范化，不必靠感觉：

• 续建（成本最低）：架构合理、代码质量可接受、缺失的只是部分功能或部分文档。适合的情况是核心链路已经验证过、要补的是外围模块。这种情况下接手方的报价通常也最低。
• 重构（成本中等）：产品方向对、界面可用，但底层结构阻碍扩展——典型的信号是「每加一个功能要改五处代码」。重构保留业务与数据，重写技术骨架，周期通常是原项目的一半左右，且必须分批进行，不能停机半年。
• 重做（成本最高）：代码无法运行、架构与业务不匹配、或者根本拿不到源码。此时把旧系统当作需求说明书来用，是最有价值的做法——它的字段、流程、页面结构都是现成的调研成果，哪怕代码全废。

判断的关键指标只有一个：加一个典型的新功能，需要多久。如果答案是「一天」，续建；如果是「一周且要动到多处」，重构；如果答案是「做不了，结构不支持」，重做。

四、评估阶段的报价该怎么谈

接手半成品软件项目，第一步不是签开发合同，而是签一份明确的评估工作。合理的形式是按人天计费的「技术尽调」，通常3至10人天，交付一份含资产清单、架构评价、风险项与三条路线成本对比的报告。

跳过评估直接让对方报一个「接着做多少钱」的数字，风险很高：报价只能基于猜测，最终不是超支就是扯皮。花几千到一两万元做一次体检，避免的是几十万的错判。

五、法律与账号层面的三个必查项

技术之外，还有三件事必须在签交接协议前确认，否则技术评估做得再好，法律上也站不住：

知识产权归属。原合同里是否明确约定源码与著作权归甲方。如果约定的是「使用权」而非「著作权」，你拿到代码也未必有权让第三方修改。

第三方组件的授权。系统里是否嵌了需要按年付费的商业组件（地图、报表、推送、OCR），授权是否随项目转移，续费由谁承担。

账号与资质的控制权。域名是否在你名下、服务器账号能否转移、小程序与APP的主体是否是你的公司。这些是纯行政事项，却是上线的前置条件，通常还伴随备案与审核的等待期。

六、交接期怎么安排，才能不停机

如果旧系统正在线上运行，交接期最忌讳的是「一次性切换」。可行的节奏是：新团队先进驻读代码与文档、不动生产环境；然后接管测试环境并修复若干已知缺陷，验证理解是否正确；再接管一个非核心模块上线；最后才全面接手。整个过程通常需要四到八周。

期间要求原供应商提供至少两周的过渡支持，把「谁能回答问题」写进交接协议。很多交接失败的案例，原因不是技术难，而是关键时刻没人能解释某个奇怪的设计为什么存在。

七、一个务实的心态

接手半成品软件项目，最容易犯的错是急于否定前人的工作。实际上，一套已经上线跑了一年、承载真实业务数据的系统，哪怕代码难看，也包含了大量无法从文档中获得的知识——哪些边界情况会出问题、哪个客户有特殊流程、哪个接口会超时。评估时把这些当作资产而不是负债，续建的比例会明显高于重做，成本也就降下来了。