接手半成品项目怎么评估

接手半成品项目风险高，要先评估再报价。 这一篇讲清评估要点、判断逻辑和报价方法。

接手半成品的痛点

接手别人做了一半或做完但维护不下去的项目，是软件外包里最容易出纠纷的场景。原因在于信息严重不对称：

• 代码质量未知：原作者的编码水平、规范程度、是否有规范都不清楚，可能要花大量时间理解。
• 完成度未知：表面功能"看起来能用"，但深层逻辑、异常处理、边界情况可能根本没做。
• 技术栈可能老旧：用了 5 年前的框架版本，升级困难、招人困难、安全补丁不再更新。
• 文档往往缺失：没有需求文档、没有架构说明、没有接口文档，全靠代码本身和原开发者记忆。
• 原作者往往不在：原作者已经离职或联系不上，出问题没人能解释。
• 隐性问题多：数据库脏数据、历史 bug 绕过去的 hack、安全漏洞、性能瓶颈——这些不接手根本看不见。

所以接手半成品最大的成本不是"继续开发"，而是理解旧代码 + 修复旧问题。

评估要点（代码体检）

接手前必须做一轮系统性的代码体检，要点如下。

1. 代码质量

• 可读性：命名是否规范、是否有注释、文件结构是否清晰。
• 规范性：是否遵循编码规范、是否有 lint 检查、是否有 code review 痕迹。
• 重复度：是否存在大量复制粘贴的代码，重复代码意味着改一处要改多处。
• 耦合度：模块之间是否高度耦合，改一个功能会不会影响一堆其他功能。

如果代码可读性差、规范混乱、耦合严重，后续改动成本会非常高。

2. 完成度

• 表面完成度：UI 看起来能用的功能占多少。
• 真实完成度：完整流程能跑通的功能占多少，异常处理、边界情况、权限控制是否做了。
• 核心功能完成度：业务主流程是否完整，而不是"每个页面都能打开"。

很多半成品表面完成度 80%，真实完成度只有 40%——剩下的 40% 是隐性的"看起来能用但实际不能用"。

3. 技术栈

• 框架版本是否现代（例如后端用 Spring Boot 2.x 还是 3.x，前端用 Vue 2 还是 Vue 3）。
• 是否还能找到对应技术栈的开发者。
• 框架/库是否还在维护、是否还有安全补丁。
• 升级到现代版本的难度和成本。

老旧技术栈（例如 PHP 5、Node.js 早期版本、已经停止维护的框架）会让后续开发困难重重。

4. 文档情况

• 是否有需求文档、设计文档、接口文档、部署文档。
• 文档是否和代码一致（很多文档写完后再没更新过，已经过时）。
• 数据库是否有 ER 图、字段说明。

5. 依赖和第三方

• 用了哪些框架和库，版本是否过时。
• 是否有付费组件、授权问题。
• 是否绑定了某个云厂商的专有服务（迁移成本高）。

6. 隐性风险

• 技术债：绕过去的 bug、临时方案、性能 hack。
• 数据库脏数据：历史遗留的脏数据、不完整数据。
• 安全漏洞：未修复的已知漏洞、明文密码、SQL 注入。
• 数据迁移难度：如果决定重写，旧数据怎么迁过来。

评估后的判断

报价逻辑

接手半成品的报价新手最容易踩的坑是"按剩余功能报"。但实际成本是：

• 理解旧代码的成本：阅读、调试、画清楚架构，这部分可能占总工时的 30%-50%。
• 修复旧问题的成本：接手后冒出来的 bug、性能问题、安全漏洞。
• 剩余开发的成本：真正还没做的功能。
• 风险溢价：隐性问题不可预见的部分，通常加 20%-30%。

所以接手半成品的合理报价 ≈ (理解成本 + 修复成本 + 剩余开发成本) × (1 + 风险系数)。代码差的项目，这个数字往往比新开发还贵——因为新开发至少不用花时间理解别人的烂代码。

别踩的坑

• 不评估就接手：盲接，做到一半才发现代码烂得改不动，进退两难。
• 以为接手便宜：直觉上"已经做了一半，应该便宜"，实际上代码烂的半成品比新开发还贵。
• 代码差硬改：在烂代码上继续堆烂代码，越改越乱，最后还是重写。
• 该重写还改：评估已经显示要重写，客户不愿意，硬着头皮改，最后双方都不满意。
• 不报价风险：报价不含风险溢价，做到一半发现问题大，要么亏本要么加价扯皮。

成本参考

怎么接手

1. 要求客户提供源码、文档、数据库结构、原开发者联系方式（如果还在）。
2. 安排 1-3 天做代码体检（视项目规模）。
3. 评估完成度、技术栈、文档情况、隐性风险。
4. 判断接手 / 部分重写 / 全部重写。
5. 报价含理解成本、修复成本和风险溢价。
6. 风险高的部分明确写进合同，由客户决定是否接受。

广州市汉诺雷斯（HNREIS）接手半成品前先做代码评估，风险和报价透明。把你的项目情况告诉我们，我们先评估再报价。