软件开发合同：验收标准没写清，为什么会两败俱伤

软件开发合同纠纷，有一个很典型的结构：开发方起诉要尾款，委托方反诉质量不合格、逾期交付。本诉和反诉并在一起审，最后往往两边都不满意。

这类案件最难的，不是法律适用，而是事实认定。因为合同里常常只有一句“按甲方要求完成开发并通过验收”，没有需求附件，没有验收标准，没有测试方法。到了法庭上，双方对“做完了没有”各说各话，法院只能靠聊天记录、邮件、演示视频去还原。

一、这类合同的性质

软件开发合同，通常属于《民法典》技术合同编里的技术开发合同。《民法典》第八百五十一条规定，技术开发合同是当事人之间就新技术、新产品、新工艺、新品种、新材料及其系统的研究开发所订立的合同，包括委托开发合同和合作开发合同。

它和普通的买卖合同、承揽合同不同：标的是“智力成果 + 载体”，履行过程高度依赖沟通，需求在开发中不断变化。所以，合同写得粗，履行就必然扯皮。

二、验收标准：最该写清楚，最常写不清

验收条款至少要回答四个问题：

• 验收什么：功能清单、性能指标、兼容环境、交付物清单（安装包、源代码、文档、数据库脚本）；
• 怎么验收：测试用例、测试环境、由谁测、测几轮；
• 多久验收：收到交付物后几日内提出意见，逾期不反馈算什么；
• 不通过怎么办：整改期限、整改次数、仍不通过的处理方式。

如果合同没约定，就要回到《民法典》第五百一十条、第五百一十一条：先看补充协议，再看合同相关条款和交易习惯；仍不能确定的，按照国家标准、行业标准履行；没有国家标准、行业标准的，按照通常标准或者符合合同目的的特定标准履行。

问题在于，“通常标准”在软件行业非常模糊。一个系统“能用”和“好用”，中间差着几十个需求。法院很难替双方定义。

三、需求变更：拖垮项目的真正原因

很多项目不是开发不出来，而是需求一直在变。今天加一个报表，明天改一套权限，后天对接第三个支付渠道。每一次都说是“小改”，加起来就是重做。

合同里如果没有变更机制，就会出现两种极端：

• 开发方认为变更超出范围，要求加钱，委托方认为本来就该包含；
• 开发方默默做完，但工期拖了，委托方反过来主张逾期违约。

可行的做法是约定：需求变更须以书面形式提出，双方确认工作量和工期影响，签订补充单后再实施。微信、邮件里的一句“好的”，在诉讼中未必能证明变更范围和价格。

四、著作权归谁

这是很多委托方忽略的一点。付了钱，不等于自动取得软件著作权。

也就是说，合同没写，著作权默认归开发方。委托方可能只拿到一个使用许可，甚至连许可范围都没约定。后续想二次开发、换供应商、申请软件著作权登记，都会卡住。

同理，委托开发完成的发明创造，《民法典》第八百五十九条规定，除法律另有规定或者当事人另有约定外，申请专利的权利属于研究开发人。想拿到知识产权，必须在合同里写明归属、转让、许可范围。

五、源代码和交付物

“交付源代码”这句话，含义也很模糊。是全部源代码，还是编译后的可执行文件？包括不包括第三方组件、构建脚本、数据库设计、部署文档？有没有托管安排？

如果委托方的目的是长期自主维护，合同应当明确：源代码的完整性、可编译性、交付时间、验收方式，以及开发方配合过渡的义务。否则，拿到一堆跑不起来的代码，等于没交付。

六、诉讼里怎么打

这类案件，本诉和反诉通常一起出现。开发方要证明：已按约交付、委托方已接受或视为验收、付款条件成就。委托方要证明：交付物不符合约定、经催告仍未整改、损失具体。

举证重点在过程文件：

• 需求文档、原型、UI 稿及其确认记录；
• 版本发布记录、测试报告、缺陷清单；
• 验收申请、验收意见、上线通知；
• 微信、邮件、会议纪要中的变更确认；
• 付款节点与发票。

软件质量鉴定在实务中并不好做：鉴定机构少、费用高、周期长，而且很多问题不是“有没有 bug”，而是“符不符合需求”。所以，法院更倾向于用合同约定和履行记录来判断，而不是完全依赖鉴定。

七、签约时的几条建议

• 把需求写成附件，逐项编号，作为验收依据；
• 约定验收期限和“逾期未提异议视为验收”的规则；
• 约定变更流程，任何变更书面确认工作量和工期；
• 写清著作权、源代码、第三方组件的归属和许可；
• 把付款节点和可验证的交付物绑定，而不是和“上线”“满意”绑定；
• 约定争议解决方式和管辖法院，避免异地诉讼成本。

软件开发合同的两败俱伤，往往不是谁故意违约，而是签约时把“什么叫做完了”留成了空白。把这个空白填上，很多纠纷根本不会发生。