一、9 项必备条款与执行要点
| 条款 | 必须写清楚的内容 | 不写的风险 |
|---|---|---|
| 需求确认书 | 功能清单、页面数、接口清单，双方签字确认 | 范围无边界，验收无依据 |
| 里程碑与验收 | 阶段划分、各阶段交付物、可量化验收标准 | 进度与质量无法客观判定 |
| 付款节点 | 比例、触发条件（如「UAT 通过后 7 日内」） | 付款与验收脱钩 |
| 源码与文档 | 完整源代码、数据库设计、接口文档、部署手册 | 后续无法自主运维 |
| 知识产权 | 著作权归属、第三方组件授权说明 | 成果归属争议 |
| 变更计费 | 基线后新增需求按 X 元/人天计价 | 变更无价，争议不断 |
| 保密与数据 | 保密义务、客户数据处理与销毁要求 | 商业信息泄露风险 |
| 售后维护 | 免费维护期、响应时限、维护计价方式 | 上线后无人负责 |
| 违约与终止 | 逾期责任、解除条件、费用结算方式 | 合作关系破裂无依据 |
二、可直接采用的验收标准写法
验收条款要能被双方客观执行。推荐写成「功能项 + 可测条件 + 通过标准」三段式，例如：
- 「订单提交功能」——在 iPhone 14 / 小米 13 两类机型、微信 8.0 以上环境下，从商品详情页加入购物车并完成下单，操作链路无阻断，结果写入后台订单表，判定为通过。
- 「微信支付回调」——支付成功后 3 秒内订单状态更新为「已支付」，回调日志可查，判定为通过。
- 「后台权限控制」——以普通角色账号登录，无法访问财务结算菜单，直接访问对应 URL 返回无权限提示，判定为通过。
- 「数据迁移」——历史 Excel 数据导入后，记录总数与业务系统一致，抽样 30 条字段值逐项核对无差异，判定为通过。
关键点 避免使用「系统功能完整」「运行正常」这类无法验证的表述。每条验收项都应能在 10 分钟内由非开发人员判定通过或不通过。
三、需求变更计费的常见约定
建议在合同中约定基线机制：需求确认书即基线，基线内的功能属于交付范围；基线外的新增需求按人天计价。
| 变更类型 | 计价方式参考 | 需不需要重新排期 |
|---|---|---|
| 小功能调整（文案、样式、字段增减） | 按小时或小额度计费 | 一般不影响总工期 |
| 中等变更（新增表单页、业务规则调整） | 按人天计费 | 需要，顺延交付日期 |
| 重大变更（新增模块、改变架构） | 重新评估工作量与报价 | 需要，重新排期 |
实践中争议最少的做法是：所有变更走书面确认（邮件或项目系统），注明人天与交付影响，双方确认后再执行。
四、容易被忽略但风险较高的三处
- 第三方组件与素材授权：若项目用到商业字体、图库素材或闭源 SDK，授权归属需明确，避免上线后收到侵权函。
- 客户数据处理：若涉及个人信息，需在合同中明确处理目的、存储期限与销毁方式，并约定不得将数据用于其他项目。
- 账号与资产归属：服务器、域名、代码仓库、应用商店账号、支付商户号，均登记在客户主体名下并在合同中列明清单。
常见问题
签订软件开发合同前需要准备什么？
建议准备四样东西：一是明确的功能清单文档（可以先列主流程与关键页面，不必过细）；二是期望的交付时间与预算范围；三是对方要求提供的资质与项目案例清单；四是贵方内部的项目负责人与决策人（用于确定验收人）。功能清单不成熟可以先做原型阶段，不必一步到位。
合同金额和付款节点怎么安排比较合理？
常见且对双方都相对稳妥的方式是签约预付 30%–40%、中期功能验收付 30%–40%、上线验收付 20%–30%、余下 5%–10% 作为质保金在免费维护期结束后结清。关键是把付款与可验证的交付物绑定，而不是与日期绑定。
交付时一定要拿到源代码吗？
要。无论是否额外付费，完整可构建的源代码、数据库设计与部署文档都应作为交付物写进合同。这既是后续自主运维、换服务商或二次开发的基础，也是对交付质量的检验——不愿意交源码的服务商，通常也难以保证代码质量。
项目延期了怎么办，责任如何划分？
建议在合同中区分延期原因：因需求变更或客户方未及时确认导致的延期，按约定顺延；因开发方原因导致的，按日承担约定比例的违约金。同时设置延期超过一定天数（如 30 天）时客户方有权解除合同并结清已完成工作量。
验收不通过但双方各执一词怎么办？
关键是验收标准要事先量化，并约定「不通过项」的判定方式。如果合同里写的是「功能完整、运行正常」这类主观表述，验收必然扯皮。推荐做法是：每条验收项写明测试步骤、预期结果、实际机型环境，当场记录不通过项与责任归属，给出明确的整改期限后复验。