签IT研发外包合同，别在交付和验收上被“坑”了

说真的，每次看到朋友或者客户拿着一份几十页的IT研发外包合同来找我，问我“有没有什么问题”的时候，我最怕看到的就是他们在“交付标准”和“验收条款”这两块大笔一挥就过去了。很多人觉得，哎呀，技术的东西太专业，看不懂，就让法务或者技术负责人去把关吧。但最后出问题，往往是老板自己掏腰包补窟窿。

这事儿跟装修房子有点像。你跟装修队说“我要装得好看点”，最后装出来，你觉得丑，他觉得有设计感，钱都付了，扯皮能扯半年。IT项目也是一个道理，甚至更复杂，因为你看不见摸不着。所以，今天咱们就抛开那些法律条文的晦涩劲儿，像朋友聊天一样，掰开揉碎了聊聊，合同里关于交付和验收的那些“坑”，到底该怎么躲过去。

一、 交付标准：别让“差不多就行了”害了你

很多合同里关于交付标准，就写一句：“乙方应按时交付符合甲方要求的软件系统”。我的天，这句话基本等于没说。什么叫“符合要求”？标准太模糊了，最后就是一笔糊涂账。

1.1 功能清单，得是“死”的，不能是“活”的

最核心的，就是要有详细的《需求规格说明书》或者《功能清单》作为合同附件。这份清单不能是大概的描述，得是具体的、可量化的。比如，不能写“实现用户注册登录功能”，得写成：

• 用户可通过手机号+验证码方式注册，验证码有效时间5分钟。
• 注册时需设置6-16位密码，包含字母和数字。
• 登录失败次数超过5次，账户锁定30分钟。

你看，这样一来，标准就立住了。验收的时候，测试人员就拿着这个清单一条条测，通过了就是通过，没通过就是没通过，扯皮的空间就小了很多。我见过最离谱的合同，附件里就是个脑图，功能点就几个词，最后上线了，甲方说“这个搜索功能怎么不能模糊查询”，乙方说“合同里没写啊”，最后只能加钱。所以，功能点越细越好，颗粒度越小，争议越少。

1.2 非功能需求：性能、安全这些“隐形”指标

除了功能，还有很多看不见但至关重要的东西，我们叫“非功能需求”。这部分最容易被忽略，也最容易在项目后期引发大问题。

• 性能指标： 系统能扛住多少人同时在线？页面加载要几秒？数据库查询不能超过多久？这些最好写清楚。比如，“核心页面在1000并发用户下，平均响应时间应小于2秒”。不然，系统做出来，慢得跟蜗牛一样，你也没法说它“不能用”。
• 安全要求： 特别是涉及用户数据的，得明确。比如，“不能有SQL注入漏洞”、“用户密码必须加密存储（如BCrypt）”、“关键接口需要做防刷处理”。这些是底线，不能含糊。
• 兼容性： 要支持哪些浏览器？Chrome、Firefox、Safari的哪些版本？要不要兼容移动端？这些都得写清楚。

把这些东西白纸黑字写下来，大家心里都有底。不然，最后你想要一个能跑得飞快的法拉利，他给你造了个能开但随时可能熄火的拖拉机，你还不能说他没交付。

1.3 源代码和文档，也是交付物的一部分

很多人以为，软件上线了，能用了，就算交付了。其实不然。源代码、技术文档、用户手册、测试报告，这些都得是交付物。

特别是源代码，一定要在合同里明确，项目验收通过后，完整、无瑕疵、可编译的源代码所有权（或使用权）要移交给甲方。我听说过有公司，外包团队交付了系统，但没给源代码，结果后期想自己维护或者加功能，发现根本动不了，外包团队要么失联要么坐地起价，那真是欲哭无泪。

文档也是一样。没有设计文档，后续开发人员看不懂逻辑；没有用户手册，你的员工不会用。这些都是要写进交付清单里的。

二、 验收流程：怎么才算“过关”？

交付标准定好了，接下来就是怎么“验收”了。这就像考试，得有明确的考试大纲（交付标准），也得有考试流程和评分标准（验收流程）。

2.1 验收阶段怎么划分？

一个项目很少能一次性全部交付验收，通常会分成几个阶段。合同里最好明确这些阶段。

• 初验（Alpha/Beta版）： 一般是核心功能开发完成，部署到测试环境。这时候主要是看功能有没有实现，大体的逻辑对不对。初验通过，意味着项目主体没问题，可以进入下一阶段。
• 试运行（UAT - User Acceptance Testing）： 这是最重要的环节。把系统部署到模拟的生产环境，让甲方的实际用户来操作。这是最接近真实使用场景的测试。很多隐藏的问题，比如操作流程不顺、界面反人类、某些边缘情况没考虑到，都是在这个阶段暴露出来的。
• 终验（Final Acceptance）： 试运行一段时间（比如1-2周）后，没什么大问题了，就可以进行最终验收。终验通过，通常意味着项目的主要款项要结清了，维保期开始了。

每个阶段的验收标准可以不一样，但都得写清楚。比如初验可能只看功能，终验就要结合试运行期间的Bug修复情况来定。

2.2 验收主体和流程，谁说了算？

谁来验收？是老板看一眼说“行”就行吗？当然不是。合同里要明确验收的主体和流程。

通常，甲方会指定一个“验收负责人”或者成立一个验收小组。这个人或者小组的签字才算数。流程上，应该是乙方提交验收申请和验收材料（比如测试报告、功能清单），然后甲方在约定的时间内（比如5个工作日）组织测试，并出具验收报告。验收报告里要写清楚哪些通过了，哪些没通过，没通过的原因是什么。

这里有个细节，“默认通过”条款。有些强势的乙方会要求，如果甲方在收到验收申请后X天内没有组织验收或者没有提出书面异议，就视为默认通过。这对甲方来说风险很大。最好是约定，甲方在规定时间内未反馈，乙方可以书面催告，催告后X天内仍不反馈，才能视为通过。这样能避免甲方因为内部流程慢或者人员变动导致项目被“被动验收”。

2.3 Bug修复和复验，没完没了怎么办？

测试肯定会有Bug，这很正常。关键是怎么处理。

• Bug分级： 合同里最好对Bug有个分级。比如“致命”（系统崩溃、数据丢失）、“严重”（主要功能无法使用）、“一般”（界面错误、不影响使用的小问题）、“建议”（优化建议）。不同级别的Bug，修复的时限要求不一样。致命Bug必须24小时内解决，一般Bug可以放宽到3-5个工作日。
• 复验流程： Bug修好了，要不要重新走一遍完整的验收流程？如果每个小Bug都要这样，那太耗时了。可以约定，致命和严重Bug修复后，需要甲方确认；一般Bug修复后，乙方自行测试并记录，可以在下一次批量验收时统一确认。

还有一种情况，就是Bug修了又出，或者一直修不好。合同里需要有条款来约束这种情况，比如“同一个Bug连续修复3次仍未通过测试，或者累计Bug数量超过XX个”，甲方有权终止合同或者要求赔偿。这是给乙方的鞭策，也是给甲方的保障。

三、 一个实用的验收条款模板（供参考）

光说理论太空泛，我试着写一个相对完整的验收条款框架，你可以把它想象成合同里的一个章节，这样更直观。

条款模块	核心要点	举例或注意事项
验收依据	明确以哪些文件为准	本合同、附件一《需求规格说明书》、附件二《UI设计稿》、附件三《非功能需求清单》。
验收阶段	分阶段进行，明确各阶段目标	1. 开发完成初验（功能实现） 2. 试运行（用户UAT） 3. 最终验收（稳定运行后）
验收流程	谁发起，谁响应，多久完成	乙方提交申请 -> 甲方在3个工作日内组织验收 -> 验收通过出具《验收报告》。
验收标准	通过/不通过的明确界限	1. 所有“致命”和“严重”级别Bug已修复。 2. 核心功能100%实现，一般功能实现率≥98%。 3. 性能指标达到附件要求。
验收不合格处理	如果没通过怎么办	乙方需在约定时间内修复，修复后重新申请验收。由此产生的延期责任由乙方承担。
交付物清单	除了软件，还要给什么	1. 源代码及编译说明 2. 数据库设计文档 3. 用户操作手册 4. 测试报告

这个表格只是一个骨架，具体内容还得根据你的项目来填充。但有了这个思路，再去跟乙方谈，就不会显得那么被动。

四、 一些过来人的“碎碎念”

写到这里，又想起一些零零碎碎但同样重要的点，可能不够系统，但都是血泪教训，也一并写给你看看。

第一，关于“试运行”。一定要争取把系统部署到自己的服务器上，用真实的数据（或者脱敏后的数据）跑一跑。别在乙方的演示环境里测，那里的环境都是配好的，一到自己这就出问题。还有，试运行期间，要鼓励所有相关人员都去用，多发现问题。别怕问题多，上线前发现问题是成本最低的。

第二，关于“口头承诺”。项目经理在电话里拍着胸脯说“这个功能没问题，后期免费给你加上”，这种话千万别信。所有功能变更、需求调整，必须走书面流程，邮件确认或者签补充协议。口头承诺在验收的时候一文不值，甚至会成为扯皮的焦点——“我没说过”、“你记错了”，这种戏码太常见了。

第三，验收报告的签字权。一定要明确是谁签字。最好是一个人，或者一个小组，避免多头管理。今天技术总监看了说行，明天业务经理看了说不行，最后谁也定不了。签字的人，要对项目有充分的了解，能拍板。

第四，知识产权。这个在交付标准里提到了，但还是要单独强调。除了源代码，还包括项目中使用到的第三方字体、图标、库的授权问题。确保乙方交付的东西是干净的，没有侵权风险，否则以后公司做大了，可能会被人告。合同里要有一条，乙方保证其交付成果不侵犯任何第三方的知识产权，如有违反，一切法律责任由乙方承担。

第五，验收后的维保期。通常验收通过后会有3-12个月的免费维保期。维保期做什么？只修Bug，还是包括小的功能调整？响应时间是多久？这些也要在合同里写清楚。不然，上线后发现个小问题，找乙方，对方说“维保只修致命Bug，你这个是优化需求，得加钱”，又是一肚子气。

其实啊，签合同的过程，也是双方建立信任和明确预期的过程。好的合同不是为了防着对方，而是为了让大家在合作的道路上，知道边界在哪里，遇到问题该按什么规则来处理。把交付和验收这两块想明白了，写清楚了，项目成功的概率至少能提高一半。剩下的，就是看双方团队的执行力和沟通了。

希望这些啰里啰嗦的东西，能帮你避开一些坑。下次再看合同，看到那些关于交付和验收的条款时，心里能更有底气一些。

员工保险体检