软件外包项目的技术尽调：代码、过程与交接的三层工程评估

选外包团队时，工程侧能核验的不是公司规模，而是三个层面的工程信号——代码层、过程层、交接层。规模数字会注水（销售与行政都算人头），但提交记录、测试产物、文档完整性这些很难临时伪造。本文不谈商务，只谈甲方在签约前后能落地的工程评估方法。

图 5：代码层、过程层、交接层各自要看什么、防什么

一、代码层：看产物，不看宣言

| 评估项 | 看什么 | 说明 |

|---|---|---|

| 代码规范 | 规范文档 + 抽样代码片段 | 命名、分层、注释密度是否一致；临时拼凑的代码在命名与目录结构上会露馅 |

| 测试产物 | 单元测试目录与覆盖率 | 有无测试、测试是否与业务代码同步演进；全是 assert true 的测试等于没有 |

| 提交记录 | 提交频次、作者数量、消息质量 | 讲得出技术细节的人才真做过；作者数量与合同人员名单能交叉验证 |

| 技术选型 | 框架版本与理由 | 用停维护框架且说不出理由的，直接扣分 |

| 数据层设计 | 表结构与迁移脚本 | 有无版本化迁移（migration）、索引设计是否讲得清 |

其中提交记录是转包识别的关键证据：正常开发是持续的小步提交，转包链路常表现为「长期无提交、临近节点批量上传」。交付验收时要求一并移交代码仓库（含历史记录），这个动作成本很低，证据价值很高。

二、过程层：把「进展」变成可验证的东西

工程上判断一个团队可不可控，看它能不能把「进展」从形容词变成产物：

| 环节 | 应有产物 | 防什么 |

|---|---|---|

| 需求边界 | 功能清单文档（SOW），逐条编号 | 无边界的需求在后期变成无限返工 |

| 变更管理 | 书面变更记录 + 计价规则 | 口头加需求、口头减功能，验收时互相扯皮 |

| 里程碑 | 阶段演示（可操作的环境，不是 PPT） | 「进度 80%」说了三个月，看不到可点的东西 |

| 测试报告 | 功能用例清单 + 缺陷记录 | 只演示正常路径，异常路径从未测过 |

| 进度同步 | 固定节奏的书面同步 | 只在催的时候有回复 |

技术侧的对应动作：要求每个里程碑结束提供可访问的演示环境，演示时随机点几个边界场景（空输入、重复提交、权限外访问），能当场处理的团队，工程素养通常过关。

三、交接层：验收不是「能跑」，是「能接手」

交接质量决定系统第二年还能不能维护。完整的交付物清单：

| 交付物 | 内容 | 常见缺口 |

|---|---|---|

| 源码仓库 | 全部代码 + 历史提交记录 | 只给压缩包、不留历史 |

| 部署文档 | 环境要求、依赖、部署步骤 | 缺依赖清单，换台机器就装不起来 |

| 数据库说明 | 表结构、字段口径、初始化脚本 | 字段含义只有写代码的人知道 |

| 第三方账号 | 服务器、域名、证书、推送 / 短信 / 对象存储账号 | 账号注册在服务商名下，续费与迁移被卡 |

| 质保口径 | 缺陷定义、修复时限、免费范围边界 | 「免费维护一年」没有缺陷分级，什么都算新需求 |

工程侧的验收动作是环境重建：拿部署文档在一台干净机器上把系统从零跑起来。能一次跑通，文档才算合格；跑不通，缺口就是文档的缺口，交付前补齐。

图 6：需求边界、书面变更、里程碑演示、测试报告、环境重建的控制链

四、两个常被忽略的工程信号

1. 变更的书面化程度。司法实践里，因委托方频繁变更需求导致的延期，法院可能认定开发方不构成违约；反过来，变更没有书面记录，开发方也无法证明延期另有原因。变更单（改了什么、影响几个人天、双方确认）是双向保护，签约时把它写进流程，比事后争论有效。
2. 「转包不免责」的合同落点。裁判口径已明确名义开发方对成果的质量、进度与交付承担直接责任。合同侧的对应动作是：列明开发人员名单、约定禁止转包条款与违约责任、验收时移交含历史的代码仓库。三个动作都做完，外包项目的「人的风险」就收敛成了可举证的合同风险。

图 7：提交记录、演示质量、响应方式三类信号的两面对照

小结

技术尽调的目的不是找到「没有风险」的团队，而是把风险从「不可见的信任」变成「可核验的产物」：代码层看产物、过程层看里程碑、交接层看文档与环境重建。三层都能给出具体物件的团队，规模大小反而是次要信息。