软件开发合同注意事项：甲方和乙方各自负责什么

软件开发合同注意事项这类问题，很少在签约前被认真讨论。真正被翻出来的场景通常是验收会：甲方说这个功能没做，乙方说合同里没有，双方把合同副本摊在桌上，翻到附件那一页，发现只写了「详见需求文档」，而需求文档有三个版本。

软件开发合同注意事项的核心，不是把条款写得多严，而是把三组权责写成可执行的动作：做什么、交什么、什么算完成。范围与边界、源码与授权、验收与付款，这三组写清楚，八成的争议不会发生。

下面用反面教材的方式展开。每组先看一个真实出现过的错误写法，再看它带来的代价，最后给出可以替换的表述。这些写法在长沙与湖南本地的定制项目里都遇到过，不是个别现象。这样比罗列条款更容易对照自己的合同。

范围与边界：写得越抽象，后面越贵

结论先说：需求范围必须以可核对的形式附在合同里，不能只写「按需求文档执行」。

常见的错误写法是合同正文只写一句「乙方按甲方需求完成系统开发」，附件放了十几页 PPT。代价是项目中期一旦出现理解差异，双方都拿不出依据。甲方认为 PPT 上那个流程图代表全部流程，乙方认为那只是示意。

可执行的替代做法是把范围拆成三层：功能清单列到模块与子功能，业务流程图画到决策分支，边界清单明确写出「本期不包含」的内容。第三层最容易被省略，却最能减少争议。写清不做什么，等于提前回答了后期最常出现的追加请求。

还有一条容易被忽略：需求变更的处理方式要写在范围条款同一节里，而不是塞到最后的补充条款。放在一起，双方读范围时就会想到变更，预期更容易对齐。

源码与授权：交付清单与著作权要分开写

结论先说：源码交付和知识产权归属是两件事，合同里必须分成两条写，不能合并成一句「源码归甲方所有」。

错误写法常见于模板合同：「项目完成后，乙方将源代码交付甲方，著作权归甲方所有。」这句话看起来很干净，实际留下了两个空白：交付的源码包含什么、乙方能否复用通用组件。

代价出现在两个时点。交付时，甲方发现只拿到一份压缩包，没有数据库脚本、没有部署文档、没有第三方组件清单，想让别人接手要重新读代码。两年后，乙方想用同一套基础框架服务另一个客户，才发现著作权条款把自己锁住了。

可执行的写法是把两件事拆开。交付条款列明交付物清单与交付时间，逐项可验收；著作权条款约定业务代码归甲方、通用框架与自研组件保留乙方复用权、复用不得包含甲方的业务数据与业务逻辑。云迈科技在合同附件里就按这个结构列清单，把「交付什么」和「保留什么」分开写，双方签字时都清楚自己拿到的是哪一部分。

条款主题	常见模糊写法	可执行写法
需求范围	按甲方需求完成开发	附功能清单、流程图与不包含清单，三方签认
源码交付	交付源代码	代码仓库、数据库脚本、部署文档、组件清单，约定交付日
著作权	著作权归甲方	业务代码归甲方，通用框架保留复用权，复用范围写清
验收标准	满足甲方使用要求	按功能、性能、数据、文档四类列验收项与判定方式
变更处理	双方协商解决	变更单格式、评估时限、工期与费用调整规则

验收与付款：标准不量化，节点就变成拉锯

结论先说：验收标准要写到能被第三方判断的程度，付款节点要与验收节点一一对应。

错误写法是「系统上线且甲方确认无误后支付尾款」。这句话把判断权完全交给了主观感受，甲方可以因为一个界面细节不满意而无限期不确认，乙方也没有催款的依据。

代价是双方都受损。项目拖着不结项，乙方没有动力做后续优化，甲方的系统带着已知缺陷继续运行。真正的问题往往不是钱，而是没有一个公认的「完成」定义。

可执行的替代是把验收拆成四类判定：功能验收按功能清单逐项勾选，性能验收给出并发数与响应时间的具体阈值，数据验收核对关键报表与实际业务数据的一致性，文档验收检查交付物清单是否齐全。每一类都写明判定方式与不通过时的整改期限。付款节点跟着这四类走，完成一类付一段，双方都有推进的抓手。

变更与工期：没有变更流程，工期一定会失控

结论先说：变更不是坏事，没有变更流程才是。

错误写法是把变更交给「双方友好协商」。协商本身没错，问题在于没有时限、没有评估口径、没有书面确认，最后变成口头答应、事后不认。

代价通常以工期形式体现。项目中期插入三个「小改动」，每个改动都说不影响进度，累积起来就是一个月。上线日期不变，测试时间被压缩，质量问题在上线后集中爆发。

可执行的做法是设一张变更单，包含变更内容、影响范围、工期影响、费用影响四项，约定评估时限与确认方式。金额不必写进合同，规则要写。有了这张单，业务方提需求时会更慎重，开发方也有依据排期。

保密与数据：数据权属比保密条款更关键

结论先说：保密条款保护的是信息不外泄，数据条款解决的是数据归谁、能不能带走。

错误写法是只写保密义务，不写数据权属。项目结束时，甲方想把历史数据导出到自己的系统，发现格式是乙方自定义的，导出功能还要另外开发。

代价是迁移成本。系统用得越久，数据越多，迁移越贵。有些企业因此被锁在原有系统里，明明不满意也只能继续维护。

可执行的写法是三条：数据所有权归甲方，乙方仅在履约期间按授权范围使用；交付时提供标准格式的数据导出能力；合作终止后按约定时间删除或返还数据，并出具书面确认。这三条不影响开发成本，却能决定几年后的选择权。

维护与交接：上线不是终点，是另一段开始

结论先说：维护条款要在签约时谈，不要等到出故障再谈。

错误写法是把维护写成「免费维护一年」，没有范围、没有响应时效、没有边界。结果双方对「维护」的理解不同：甲方认为改功能也算维护，乙方认为只修缺陷。

代价是关系恶化。前三个月还算客气，第六个月开始互相推诿，最后演变成谁都不愿意接手的僵局。

可执行的替代是把维护分成两层：缺陷修复与功能迭代。缺陷修复约定分级与响应时效，功能迭代约定计费方式与排期规则。再加一条交接条款，明确合作终止时乙方需在多长时间内完成代码、文档与账号的移交。这一条在合作顺利时用不上，在合作不顺时是唯一的退路。

会议桌上的三个分歧

观察过多次合同评审会，分歧出现的位置相当集中，几乎每次都在同样三处。

第一处是「这个功能算不算在范围内」。甲方举出需求文档的某一页，乙方翻到功能清单的某一行，两边都觉得自己有理。这类分歧的根因是需求文档与功能清单没有对齐，解决方案不是争论，而是在签约前做一次逐条映射。

第二处是「验收什么时候算通过」。甲方希望多用一段时间观察，乙方希望按节点确认。可行的折中是设置试运行期，期内只修缺陷不加功能，期满按验收项逐条判定。

第三处是「这些数据能不能带走」。这一条往往在项目尾声才被提起，此时双方都没有谈判余地。提前写进合同，成本几乎为零。

签约前对照这八条

把上面的内容收成一份清单，签合同前逐条核对，缺哪条补哪条。

• 功能清单是否列到子功能，并与需求文档逐条对应。
• 是否有一份明确的「本期不包含」清单。
• 源码交付物是否逐项列明，交付日期是否具体到日。
• 著作权与通用组件复用权是否分开约定。
• 验收标准是否覆盖功能、性能、数据、文档四类，并写明判定方式。
• 付款节点是否与验收节点一一对应。
• 变更单是否包含影响范围、工期、费用三项，且有评估时限。
• 数据权属、导出能力、终止后的数据处理是否写入。

常见问答

问：合同里要不要写具体金额和工期天数？

答：要写，但要与范围绑定。脱离范围谈工期没有意义，同一个系统在需求清晰与需求模糊两种状态下，工期能差出一半。建议把工期写成基准工期加变更调整规则，比写死一个日期更贴近实际。

问：对方坚持用他们的模板合同，能改吗？

答：能改的是附件。多数模板合同的正文改动空间小，但功能清单、交付清单、验收标准、变更单格式这些附件通常可以谈。把关键内容放进附件，效力与正文一致。

问：源码交付了，为什么还要约定交接培训？

答：代码能跑和团队能接手是两件事。没有部署文档与一次现场讲解，新团队接手通常要多花几周读代码。把交接培训写进交付清单，是把隐性成本显性化。

写在签字之前

如果这条项目还没启动，先别急着比价。把上述八条对照一遍，尤其看范围清单和验收标准是否具体，这两项不清楚，后面所有条款都会失去着力点。合同写得细，不是为了防着谁，而是让双方在同一个判断标准上工作。

长沙与湖南本地的软件定制项目，甲乙双方往往沟通频繁、关系近，条款容易写得松。关系好时不觉得有问题，一旦人员变动，口头共识就失效了。云迈科技的做法是在项目启动前先做一轮需求访谈与原型确认，把范围与验收口径固化成附件，再进入合同流程。手上有项目正在准备签约的企业，可以把现有合同与需求材料放在一起，围绕软件开发合同注意事项逐条对照自查，把不明确的点标出来再决定下一步；想了解通用交付流程，可以参考软件开发六个关键环节，外包场景的分工边界在技术外包的选型与协作里有更细的说明，服务范围见软件开发服务。