PG官网

  很多老板签软件合同时，看到 "免费维护一年" 就觉得省心。真上线出了事才发现，合同里这句话可能就一行字，范围、时效、责任全没写。后面每修一个问题都要重新谈价，扯皮从验收那天就开始了。

  我见过不少项目，维护期内出了 bug，开发公司说这算新增需求要另收钱，老板觉得合同写了免费就该全包，两边各执一词，最后只能翻合同。可合同里偏偏没写清楚，翻也翻不出结果。今天就把售后条款拆开，看看这一年到底值不值。

一、免费维护，到底免费什么

  行业里默认的维护范围，一般只含 bug 修复，也就是程序报错、闪退、功能不正常这类缺陷。这类问题属于开发质量范畴，本来就应该修，写上免费只是约定个时间窗口。

  新增功能、界面调整、业务流程改动，通通算需求变更，不在维护范围内，要单独报价。这一点很多老板没概念，以为 "维护" 就是提什么需求都能免费做，等报价单出来才傻眼。

  还有三样东西合同里经常不写：服务器费用、域名费用、第三方接口费用。这些是外部成本，跟开发公司没关系，但很多老板以为 "维护一年" 就全包了。合同没写范围，就等于没约定，到时候解释权在对方手里。

  签合同前最好把维护范围列个清单，写清楚哪些算 bug、哪些算变更、哪些要另付费。哪怕只是把范围写明白，后面都能少很多麻烦。

二、三个最容易漏掉的细节

• 第一个是响应时效。故障报修后多久有人接、多久给出修复方案、多久修完，不写清楚就是没承诺。有的公司写了 "及时响应"，实际上三天回一条消息也叫及时。

• 第二个是修复方式。远程能修的不算完，核心系统要不要现场处理、修复前要不要备份数据、会不会影响当天业务，这些都得落到合同里。特别是政企项目，系统一停就是事故，光靠远程可扛不住。

• 第三个是验收前后的界限。上线当天发现的问题算不算验收前问题、验收后多久内算 "维护期问题"，最容易吵。双方各执一词，最后往往看谁嗓门大。有的合同把验收和上线混在一起写，出了问题根本分不清责任段。

这三条看起来都是小事，真出事都是大事。合同里写了，是约束对方；没写，就是给自己留隐患。

三、需求变更为什么总能吵起来

  "顺手改一下" 和 "重新开发" 是两码事，边界在哪，合同里得写明白。改个按钮颜色算小事，改个审批流程就是新需求，工作量差出好几倍。很多老板觉得 "就改个逻辑"，程序员得重新梳理上下游，一改就是一两天的活。

  规范的流程是：提需求、开发公司评估工时和费用、书面确认、再开工。很多项目败就败在口头改需求，改的时候不记账，结算的时候全来了，老板觉得被宰，开发觉得白干。

  更要命的是需求变更没有文档记录，改着改着，双方记忆都对不上。半年后复盘，你说改了三次，对方说改了五次，谁也说不清。书面确认不只是保护开发公司，也是在保护老板自己。

四、维护期结束前要做的事

  到期前一个月，让开发公司出一份遗留问题清单和未完成事项，白纸黑字确认哪些已经结清。别等合同自动失效了才发现还有个老 bug 没人管。

  续费方案也要提前谈。按年包干还是按次计费，价格和范围写清楚，别到期那天被临时开价。同时把源码、文档、部署方式都拿到手，真到换人维护那天，新公司接得住，你才不被拿捏。

  最后留个心眼：维护期是 12 个月还是按自然年算，起止日期要写具体。有的合同写 "验收后一年"，验收拖了半年，维护期也跟着缩水，这坑不少人都踩过。

售后条款写得越细，后面越省心。签字前把范围、时效、变更、续费这四件事看明白，能省掉一大半扯皮。