外包把系统交给你时，源代码要不要全部拿到

一、钱付完了，这套系统到底归谁

不少老板以为钱付完，系统就是自己的。实际归谁要看合同怎么写，付款记录本身不能决定归属。

归谁要分三件事看：你能不能用这套软件，代码的所有权归谁，服务器和账号挂在谁名下。这三件事经常被混在一起谈，最后一个都没写清。

合同里最好有一句明确的话：验收合格并付清款项后，本项目全部交付物的所有权归你公司。缺这句话，文件放在你手里，也不等于你能随便改、随便交给别人维护。

二、合同里写的“源代码”，到底包括哪些东西

很多合同只写“提供源代码”这几个字。交接那天，这几个字往往会被解释成最省事的那种：只给业务代码。

你需要一份清单，而不是一个名词。清单至少包括：前端页面代码、后端服务代码、定时任务和批处理脚本、配置文件模板、数据库建表与初始化脚本、构建和打包脚本、第三方依赖清单。

上面每一项都要单独列一行，写清交付形式和交付时间。少列一项，后面就得单独再谈一次。

三、只给业务代码，算不算交付完成

不算。业务代码只是一批源文件，没有建表脚本，数据库是空的；没有构建脚本，改一行字也不知道怎么发布出去。

有一个简单的判断办法：把对方给的全部文件拷到一个空目录里，照着说明能不能把系统跑起来。跑不起来，就不算交付完成。

这条判断要写进验收条款，不要停留在口头确认。

四、代码拿到手，为什么在自家机器上跑不起来

代码能打开，不等于能运行。运行还需要三样东西：运行环境，就是跑程序的那套软件底座；依赖包，别人写好的现成组件；配置项，数据库地址、账号密码这一类参数。

这三样常常留在原团队手里，因为他们电脑上早就装好了，没人觉得这是个事。

对策是加一条验收动作：在你公司的服务器或云账号上，由你方人员操作、对方只在场不动手，从零部署一次。成功才算通过。

五、编译、依赖和配置，分别由谁负责

编译是把人写的代码变成机器能跑的程序。这一步需要工具，工具版本对不上就编译不过。

合同里要指定责任人：谁提供构建脚本，谁写清工具版本，谁负责第一次在你方环境里把程序构建出来。

依赖包有个容易忽略的问题：有些包是从对方公司内部的私有仓库装的，外面装不到。这种包要连同配置文件一起交给你，或者换成公共来源。

六、数据库脚本由谁交，交到什么程度

数据库脚本包括建表语句、索引、初始数据，还有后续每次升级用的变更脚本。

只给当前的表结构不够。系统以后要加功能，需要知道每次改了什么，所以变更脚本要按顺序交全。

验收办法很简单：在一个空数据库里，按顺序执行你拿到的脚本，表能建出来，系统能登录进去。

七、第三方组件和开源库，授权查过没有

系统里通常大量使用别人写的现成组件。有的是开源库，就是别人公开出来、可以免费拿来用的代码；有的是花钱买的商业组件。

开源库要看授权协议。有的协议要求：谁在自己的系统里用了这个库，就要把自己的代码也公开。这种库用在内部系统里问题不大，用在对外销售的产品上要谨慎。

商业组件按用户数或服务器数收费，采购合同和授权凭证要一并交接，以后续费由谁出钱也要写明。

八、云账号、域名、证书和短信通道，怎么过户

这些东西不在代码里，少了任何一样，系统当天就停。

清单包括：云平台账号、域名注册账号、网站证书，就是让地址栏出现小锁的那个东西、短信签名和模板、支付商户号、地图或实名认证这类外部接口的账号。

原则只有一个：账号主体是你公司，绑定你公司的营业执照和对公账户。对方是代为开通，还是新建账号再迁移，要写清做法和完成时间。

九、哪些密码和密钥必须在交接当天换掉

交接时最容易被跳过的一步，是改密码。对方团队里知道密码的人，离开项目之后依然知道。

必须换的包括：数据库密码、服务器登录方式、云平台访问密钥，也就是一串用来调用云服务的密码、第三方接口密钥、短信和支付的回调密钥。

还有一类更隐蔽：直接写在代码里的密钥。这类要清理出来，改成从配置文件读取，再统一换新。

十、文档算不算验收项，缺了怎么办

算。但“有文档”这三个字没法验收，要写清是哪几份。

第一份是部署说明：从一台空服务器开始，装到系统能打开，中间每一步都写出来。

第二份是运维手册：日常看哪些指标，出问题按什么顺序排查。

第三份是接口文档：跟外部系统怎么对接，参数和返回值怎么约定。第四份是数据字典：每张表、每个字段分别是什么意思。

验收标准写成一句话：一个没参与过这个项目的人，只靠文档能把系统部署起来。

十一、缺文档能不能扣尾款

能，前提是事先写进合同。钱付完了再谈，就没有谈的条件了。

做法是把交付清单和付款节点绑在一起：尾款支付前逐项确认，缺一项扣一个事先约好的比例。

比例要在合同里写成具体数字，不要写“视情况扣减”。写不清的比例，执行时等于没有。

十二、对方坚持不给源码，托管该怎么约定

有些外包方不愿意交源码，愿意接受第三方托管。托管的意思是：代码放在一个中立的第三方手里，平时你拿不到，触发约定条件才交给你。

要写清四件事：托管哪些内容、更新频率、什么条件算触发、谁来判定触发。触发条件可以是对方停止维护、公司注销、严重违约。

最常见的问题不是不托管，而是托管的还是最初那一版代码。所以要约定每次发版后同步更新，更新完成你要收到书面确认。

十三、定期交付该怎么约定

如果对方不同意一次性交源码，可以接受分期交付：每个版本上线后交一次，或者按固定周期交一次。

关键是交到你的代码仓库。仓库就是存代码、记录每次修改的地方。只给你开一个只读账号不算交付，权限一关，你手里什么也没有。

每次交付要有一张签收单：交付日期、版本号、内容清单、接收人。没有签收单的交付，将来很难证明。

十四、原团队撤走以后，出问题找谁

交接完成不等于关系结束。合同里要留一段维护期，写清四件事：对接人是谁、问题通过什么渠道提、回应时限写多少小时、修复时限写多少小时。

时限要落到具体小时数，不要写“及时响应”“尽快处理”。这两个词在争执的时候没有任何作用。

还要加一条：对方在约定时限内不回应，你有权自行修改或另找第三方修改，对方不得主张侵权。

十五、交接会上，哪些问题必须逐条问

开会前把问题写下来，会上逐条念。答不上来的当场记进待办，写清谁负责、什么时候给答复。

先说交付清单：除了业务代码，建表脚本、初始化数据、构建脚本、依赖清单、配置模板，这次给哪些，不给哪些。

再说运行验证：能不能约一个具体时间，在我们自己的服务器上从零装一遍，我们的人操作，你们的人在场。

账号这一项要问主体：云平台、域名、短信、支付，现在挂在哪家公司名下，什么时候能改到我们名下。

密钥要一张表：交接当天换哪些密码，谁负责改，改完怎么确认。

第三方组件要凭证：用了哪些商业组件，采购合同和授权凭证在哪，以后续费谁出钱。

文档要交付时间：四份文档各交一份，写清哪天交。最后问退出安排：维护期写到什么时候结束，对接人是谁，回应时限写几小时，不回应怎么处理。

十六、哪些事现在不用争，留到后面谈更划算

不是所有事都要在交接会上定死。分清两类，会议会顺很多。

现在必须定的有五件：源码清单的范围、账号主体改到什么时候完成、密钥更换的责任人、在你方环境跑通的验证时间、维护期的回应时限。

这几件一拖，后面每件事都要重新找人谈一次。

可以留到后面谈的：代码写得规不规范、注释写得清不清楚、有没有自动化测试、日志记得细不细。这些决定以后改起来顺不顺手，不影响你接不接得住这套系统。