上周在邯郸丛台区见了一位做餐饮连锁的老板，他拿着一份小程序外包合同让我帮忙看。合同三页纸，需求描述只有半页，验收标准写的是“功能正常使用”。我问他：什么叫正常使用？他愣了一下，说“就是能用吧”。这种合同一旦出问题，基本没法维权。
在邯郸做小程序开发这些年，我见过太多因为合同没写清楚而扯皮的项目。今天不谈技术，就聊聊签合同这件事。
需求附件比合同正文更重要
很多甲方把注意力放在价格和工期上，对需求清单反而随便。实际上，合同正文是通用条款，真正决定项目成败的是那份需求附件。
一份能用的需求附件，至少要包含：
- 每个页面的功能点，精确到按钮点击后发生什么
- 角色权限说明，比如管理员、普通用户、商户分别能看到什么
- 数据来源和流向，哪些数据是用户填的，哪些是后台配置的
- 第三方对接清单，支付、地图、短信、物流分别用哪家服务商
我通常建议客户把需求写成“用户故事”的形式，比如“用户下单后，商家在5分钟内收到微信模板消息提醒，消息里包含订单号和金额”。这种描述可验证，后期验收时不会各说各话。
验收标准要可量化
“功能正常使用”是最危险的表述。什么叫正常？页面加载3秒算正常还是1秒算正常？并发100人会不会崩？
建议在合同里写清楚：
- 功能验收：对照需求附件逐条勾选，全部通过才算完成
- 性能验收：首页加载时间、接口响应时间给出具体数值
- 兼容性验收：列出需要适配的机型或微信版本范围
- 验收期限：甲方收到交付物后几个工作日内反馈，逾期视为通过
最后一条特别重要。我遇到过甲方拖了两个月不验收也不提意见，最后说“再改改”，工期和尾款都卡住了。约定验收期限，对双方都是保护。
付款节奏与知识产权归属
常见的付款方式是 3:4:3 或 4:3:3，即预付款、中期款、尾款。这里的关键不是比例，而是每笔款对应的交付节点要明确。
预付款对应合同签订和需求确认，中期款对应核心功能演示通过，尾款对应上线验收。每个节点都要有可交付的成果物，而不是“做到一半了”。
知识产权条款容易被忽略。要写清楚：源码、设计稿、数据库结构在尾款结清后归甲方所有；乙方保留通用组件和框架的使用权。这样既保护甲方，也不至于让开发方把每个项目都从零重写，成本最终还是会转嫁到报价里。
变更条款：给需求加个出口
几乎没有项目能完全不变更需求。问题不在于变不变，而在于变了怎么算。
合同里应该约定变更流程：书面提出、评估工作量、双方确认工期和费用调整后再实施。小额变更可以设个阈值，比如累计不超过2人天的调整不额外收费，超过部分按约定单价计算。这样既保持灵活，又不会让项目无限膨胀。
邯郸本地项目的一个实际建议
上个月帮邯郸永年区一位做标准件的客户梳理合同时，我建议他把“服务器和域名归属”单独列一条。很多外包合同默认服务器由开发方代购代管，项目结束后甲方想迁移数据才发现账号不在自己手里。
正确做法是：服务器、域名、微信小程序账号、支付商户号全部用甲方主体注册，开发方只拿子账号或协作权限。合同里写明项目交付时移交全部账号和密钥。这一点在本地传统企业客户里尤其常见，提前说清楚，后面省很多事。
合同不是用来防着谁的，是把双方对“做完”的理解对齐。写清楚的需求、可量化的验收、明确的变更流程，比任何口头承诺都可靠。
我是知码客，在邯郸做小程序和 APP 开发。如果你正准备签外包合同，或者手里已经有一份拿不准的，欢迎拿来一起看看。用代码改变生活之前，先把规则定明白。
评论 (0)
还没有评论，快来抢沙发吧~