技术尽职调查不是一场代码质量比赛，而为它做准备的团队，往往把时间花在了完全不重要的地方。没有哪个买家是为了给你的抽象层打分才来收购公司的。买方想弄清楚的只有两件事：持有这套系统要花多少钱，以及在钱易手之后，事情可能糟糕到什么程度。

这个视角的转换很重要，因为它会改变你应该优先修哪里。丑陋但能跑、团队看得懂、可以安全修改的代码，只是一条轻微的发现。相反，写得优雅却只有一个人看得懂的代码，是一条严重的发现，而真正会让价格发生变化的，恰恰是后者。

所有问题背后的那个问题： 如果创始工程师在交割后的第二周离职，这套系统还能继续运行、并且继续被修改吗？几乎每一条压低报价的发现，都是对这个问题的具体回答。知识集中在一个人的脑子里、没有文档的部署流程、从来没人核对过的许可证、只存在于某个人记忆中的凭据，反复出现的就是这几类。

技术尽职调查真正评估的是什么

买方看的是四类风险，大致按照它们影响估值的顺序排列。

关键人员依赖风险。 也就是系统究竟依赖有据可查的流程，还是依赖某几个具体的人。这一条始终是杀伤力最大的发现，因为它事后最难补救，而且直接威胁到被收购的东西本身。如果某个人离开开发就停摆，买方拿到的与其说是资产，不如说是一份人质合同。

继续运营的成本。 让系统持续运转并继续演进需要什么：基础设施支出、许可证义务、必须配备的团队规模，以及产品路线图里有多大比例会被维护工作吃掉，而不是用在新功能上。这些数字在交割之后会原封不动地落到损益表上，所以买方查得比多数人预想的要细。

法律责任。 与商业用途相冲突的许可证、以经不起一次投诉的方式处理的个人数据、安全上的暴露面，以及公司实际上并未履行的监管义务。这些负担在交易完成后会一并转移给买方。

改变的能力。 新功能能否以可预测的节奏交付，还是每改一处都要承担弄坏另一处毫不相干功能的风险。既然收购的目的通常是把产品做大，这项能力直接关系到未来的收入预期。

代码质量只有通过第四点才产生意义。这也是为什么评审人花在读代码上的时间远比创始人预期的少，而花在追问部署到底是怎么完成的时间要多得多。

会压低价格的发现

除了一个人以外没人会部署。 只存在于某人脑子里、或者某人笔记本电脑上的发布流程，无论今天运行得多顺畅，都会被当成严重的运营风险。流程能跑通和流程能交接，是两回事。

关键路径上没有测试。 这里说的不是覆盖率百分比，评审人基本不看那个数字，而是这套系统还能不能带着哪怕一点点信心去修改。收入路径周围没有测试的代码库，会把一份更慢的路线图折算进价格里。我们关于软件测试策略 的文章讲了哪些测试真正值得写。

许可证污染。 专有产品里混入了带传染性的开源代码，也就是 Copyleft 代码，是少数几类不只是重新定价、而是能够直接终止交易的发现，而且扫描工具通常几分钟就能查出来，根本瞒不住。

没有合法依据的个人数据。 在没有清晰合法性基础的情况下收集的数据，无限期保留的数据，或者存放在公司自己都列举不出来的地方的数据。GDPR 技术合规 一文讲到的那些机制，正是评审人会逐条核对的内容。

对个人或供应商没有记录在案的依赖。 与某家没有签订合同的供应商之间的关键集成，或者跑在个人账号上的基础设施，两者都会被读成未受管理的风险。凡是拿不出公司层面合同或所有权凭证的东西，在买方眼里等同于不存在。

缺少安全的基本项。 需要的不是渗透测试报告，而是三个具体问题：密钥是否躺在版本控制里，人员离职时访问权限是否被及时收回，以及此刻是否还有未打补丁又对公网开放的东西。

评审人并不在意什么

这一点值得专门写出来，因为准备时间有限，而且通常被用错了地方。

他们不在意你选了哪个框架，只要还能招到会用它的人就行。他们也不在意架构上的流行风向：一个能持续交付的单体不构成任何发现。代码风格、命名习惯、有没有采用互联网上某个人推荐的设计模式，同样不影响结论。

他们更不会指望技术债务为零。每家公司都有，存在本身完全正常。真正重要的是团队知不知道它在哪里，能不能说清它的代价。能拿出一份清晰的已知问题清单的团队，会被读成有能力。声称自己一个问题都没有的团队，会被读成对现状缺乏认知，评审人只能自己去找，耗时更长，最后写出来的报告也更难看。

不重写任何东西的准备方式

真正有用的事情大多以天计算，而不是以月计算，而且没有一项需要动到架构。

把部署过程写下来。 从一台空白机器写到系统跑起来为止。仅这一份文档就正面回应了杀伤力最大的那一类发现，一个下午就能写完。

列出你的依赖及其许可证。 自动化工具很快就能生成这份清单，而抢在评审人之前知道答案，比清单本身有多干净重要得多。

把密钥从版本控制里拿出来，并盘点谁拥有哪些访问权限。然后撤销所有已经离职的人的权限。

把你已知有问题的地方写成文档。 一份简短诚实的已知问题登记表，附上大致的修复成本即可。主动交出这份表，是少数能稳定改善评审语气的做法之一。

确认基础设施归公司所有，而不是挂在个人账号下，并且域名、证书和代码仓库都处在公司控制之下。

这些发现最后会变成什么

它们很少会让交易告吹，它们会变成条件。

发现通常收敛为三种结果之一：反映修复成本的价格调整、写进协议的保证条款或赔偿条款，以及必须在交割之前满足的先决条件。真正会让交易彻底停下来的，基本只有许可证污染，以及被长期搁置的严重数据保护风险。

也就是说，实际目标从来不是一套完美的系统，而是一套问题已知、边界清楚、能够用语言描述出来的系统。因为被量化过的问题会被计入价格，而没有量化的问题，只会被默认为比实际情况更糟。

Mecanik 在软件开发 业务中承接这类技术评审，多数时候站在买方一侧。规律相当稳定：评审结果好的系统往往不是技术上最精巧的那些，而是有人愿意把事情写下来的那些。

相关文章: 软件源代码托管：谁真的需要它 、英国金融科技软件开发：FCA、支付通道与成本 、固定价格合同还是按工时计费 、英国定制软件开发：完整买方指南 。

常见问题

什么是技术尽职调查？ 它是对持有一套软件系统需要付出多少成本、以及在收购或投资之后事情可能糟糕到什么程度所做的评估。它考察的是关键人员依赖风险、继续运营的成本、法律责任，以及继续修改系统的能力，而不是为代码质量本身打分。

哪些发现最会压低价格？ 知识集中在个别人身上，尤其是只有一个人能执行的部署流程。其次是收入路径上没有任何有意义的测试、专有产品中混入 Copyleft 代码造成的许可证污染、缺乏可辩护合法依据的个人数据，以及被提交到版本控制里的密钥。

评审人会在意我们的技术债务吗？ 他们默认它存在。每家公司都有，存在本身并不构成发现。重要的是团队知不知道它在哪里，能不能说清修复它需要多少代价。一份清晰的已知问题登记表会被读成专业能力，而声称完全没有问题会被读成缺乏认知，并让评审结论变差。

我该如何准备技术尽职调查？ 写下如何从一台空白机器把系统跑起来，列出依赖及其许可证，把密钥从版本控制中移除，复核还有谁保留着访问权限，确认基础设施和域名归公司而不是个人所有，再准备一份诚实的已知问题登记表，附上大致的修复成本。

一条技术发现会彻底终止交易吗？ 很少。绝大多数发现最终变成价格调整、协议中的保证条款，或者交割前必须满足的条件。真正会终止交易的例外，是专有产品中的 Copyleft 许可证污染，以及被长期搁置的严重数据保护风险。