上线后的软件维护：缺陷与变更请求的区别，以及维护合约应包含什么

新业务系统上线两周后，老板在 WhatsApp 里留言：“这份报表不对，我还想让它显示去年的数字。”开发者回复说后半句是新功能，需要另行报价。老板却认为整份报表本来就应该正常。两边都有一半道理，却都拿不出证明，因为没有人写下“这份报表”应当做什么，也没有写下问题该如何归类。

本指南写给已经定制（或即将定制）系统或应用的企业主，帮助您了解上线之后会发生什么。内容包括缺陷与变更请求的区别、如何提交才能让对方立刻着手处理、维护合约应当包含和排除什么，以及每月怎样复查。这是一般性指引，不是法律意见，也不代表任何一家供应商的条款。

缺陷、变更请求，以及两种容易混淆的情况

上线之后的投诉几乎都落在以下四类之一。归类正确很重要，因为每一类的处理方式（往往还有收费方式）都不同。

• 缺陷（bug）。系统没有按约定运作。约定的行为写在已签署的范围说明、报价单或验收清单里，而上线的系统与之不符。
• 变更请求。您想要约定之外的东西，例如新字段、新报表或新的审批步骤。系统是按规格运作的。
• 使用问题。系统按约定运作，但有人不知道怎么用，或输入有误。解决办法是培训，或把界面改得更清楚。
• 外部变化。系统周边的东西变了：支付服务商更改了接口，浏览器更新改变了表现，或者主机续费过期。

最后一行说明了为什么界线有时模糊。当约定没有提到或含糊不清时，老实的标签是“不明确，待决定”，而且决定应当记录在案，不要在聊天里争论。

一分钟判断法：这是约定过的吗？

归类问题不需要技术知识，只需要约定的基准和几个问题。

1. 找到基准。已签署的范围说明、报价单中对工作的描述，以及您在用户验收测试时勾选的清单。验收通过的版本，是之后一切的起点。
2. 基准写明了该怎么运作吗？如果写明了而系统不同，就提交缺陷，并引用您依据的那一行。
3. 基准没提到吗？那就是变更请求，无论您觉得多么理所当然。“理所当然”正是争执的开端。
4. 基准含糊吗？请开发者提出原本的预期行为，并在动工前以书面确认。

为什么要在开发之前约定好定义

这个标签往往决定谁来付钱，而钱会把中性的问题变成争吵。最省事的办法，是在双方还没有利害冲突时就定好规则。

• 用文字定义缺陷。例如“与已签署的规格或验收清单不符的行为”，再附上三四个贴近您业务的例子。
• 定义变更。任何新增内容，或对已批准行为的修改，须先报价再动工。
• 写明灰色情况由谁决定、多快决定。双方各指定一位负责人，并规定例如“不明确的事项一周内决定并记录”。
• 写明基准。在某个记录在案的日期验收通过的系统，并附上验收清单。
• 写明免费修复期。常被称为保修期或缺陷修复期。供应商网页提到的期限大约从一个月到几个月不等，但没有统一标准，所以关键是白纸黑字、从何时起算（上线还是验收），以及到期后怎么办。

这些内容应写进报价单或合同，所以比较报价时也该看各家对上线之后怎么说。变更如何计价，与固定价格还是按小时计费相关；上线前后的时间安排，则见定制系统需要多长时间。

如何提交缺陷，才能被修复

开发者没办法修复“它坏了”。一份好的报告，能让对方几分钟内重现问题，而不必打电话给您：

• 您做了什么。精确的步骤：“打开报价单，选择 Q-0231，点击转为发票。”
• 您预期什么，最好附上与之矛盾的那条约定。
• 实际发生了什么。提示信息请逐字复制。
• 证据。能看到整个浏览器窗口的截图，或一段简短的录屏。
• 何时发生、多常发生。何时发现，每次都出现还是偶尔，只有一个人还是所有人。
• 设备和浏览器。手机还是电脑，用的是哪个浏览器。
• 谁受影响、有多紧急。使用事先约定好的等级。

请如实使用这个等级。如果什么都是“停摆”，那就等于什么都不是。一份好的报告大致是这样：“11月12日10:40，笔记本电脑，Chrome。我在报价单 Q-0231 上点击‘转为发票’，预期生成明细相同的发票。屏幕出现红色提示 ‘Something went wrong’，没有生成任何发票。已附截图。连续出现三次，同事也一样。今天无法给这位客户开单，所以属于高。”

如何描述变更请求

请描述问题，而不只是您想象中的界面。“加一列去年数据”会让开发者去猜。“我们的销售经理每周一用电子表格把每个月和去年同月对比”，则能让对方找到最简单的满足办法。请写明您需要的结果、谁使用及使用频率、它取代的变通办法、怎样判断它做对了（一句可以检查的话），以及任何截止日期。

动工前，应得到书面答复：是否可行、会影响什么、需要多久、费用多少，或者会用掉多少含在合约内的工时。如果聊天里只回了一句“可以”，也请把它记进清单。口头批准是日后出现没人记得同意过的账单的主要来源。

保留一份持续更新的清单

问题、想法和疑问会堆积在 WhatsApp、电邮和电话里。选定一份清单，例如共享的电子表格，把一切都放进去。它也能为每月复查和日后的任何分歧提供事实依据。

您这边由一个人负责这份清单，并阅读每一条新记录。只有您亲自测试过修复结果，事项才算关闭，这与验收前的最终检查是同一个原则。

为什么看似没有变化，软件仍需要维护

您不去碰的系统，也不会原地不动。浏览器和手机会更新，系统所用的软件组件会发布安全修复，所连接的服务会改变规则，您的数据也在增长。工程师通常把这类工作分为四种：纠正性（修复故障）、适应性（跟上环境变化）、完善性（改进已有功能）和预防性（安全更新、检查备份、监控）。维护合约应说明包含哪几种。忽视并不是免费的，因为累积的小故障会让之后的每次改动更慢、风险更高。

维护合约应当包含什么

维护合约（retainer）是一种通常按月计的协议，供应商负责让您的系统保持健康，并在您需要时给予响应。好的合约很具体。请确认以下每一项都以书面写明：

• 缺陷修复。故障是否在合约内修复、从何时起，以及如何应用“这是约定过的吗？”的判断。
• 小改动。写明工时数量、较大的请求如何报价，以及未用完的工时会作废还是顺延。
• 安全与平台更新。谁负责更新框架、程序库和服务器软件，多久一次，上线前如何测试。
• 备份与恢复测试。备份什么、多久一次、副本存在哪里，以及已经试过恢复的证据。没人恢复过的备份只是希望，不是保障。原则可参考网站备份指南。
• 监控。监控什么（可用性、错误、磁盘空间、证书到期），通知谁，之后怎么办。
• 续期事项。主机、域名、SSL 证书和任何付费的第三方服务：谁跟踪日期、谁付款，各自登记在谁的名下。续期失误是可以避免的故障的常见原因。
• 指定联系人。一位负责人、一位后备，以及处理紧急事务的渠道。
• 响应预期。服务时段，各紧急等级的确认时间和开始处理时间，以及“已解决”的含义。确认收到不等于修好。
• 工时与额外工作。每月包含多少，额外工作如何报价并在开工前获批，已用工时如何汇报。
• 交接与退出。文档、访问权限和源代码，详见定制软件源代码归谁所有，让终止合约时您不至于陷入困境。

同样重要的是合约排除什么，而且在您签字之前就应该看得到。常见的排除项包括新功能和较大的改动（另行报价）、由第三方故障或他人改动系统造成的故障、新员工培训和数据清理、重新设计或重大平台迁移、您自己的设备和网络，以及第三方的许可费用（除非按写明的金额转嫁给您）。

针对网站的维护合约是相关但不同的产品。马来西亚网站维护费用和网站为什么需要持续维护谈的就是这类，测试站点在那里也有帮助。定制系统有自己的数据库、登录、业务规则和系统对接，所以它的清单不同。

签约前要问的问题

• 你们如何定义缺陷和变更请求？请用我的业务举三个例子。
• 免费修复期多长，从何时起算，到期后会怎样？
• 包含多少工时，未用完的工时怎么办，额外工作如何获批？
• 各紧急等级的响应时间是多少（按工作时间计），我的联系人不在时由谁接手？
• 更新如何进行、多久一次？最近一次备份恢复测试是什么时候？
• 谁跟踪并支付续期费用，登记在谁的名下？
• 谁能看到我的在线数据，访问权限如何限制？
• 合约结束时我能拿到什么，包括源代码和文档？哪些不在范围内？

维护合约太单薄或太含糊的迹象

• 没有定义。“支持”和“维护”被随意使用，缺陷与变更之间没有界线。
• 没有响应预期，或者只承诺“尽快”回复。
• 什么都“无限”。固定月费下无限次修改，又无法看到做了什么，通常会在什么算合理的问题上起争执。
• 没提更新，或者有备份却没有恢复测试。
• 没有指定联系人，只有一个通用邮箱或聊天群。
• 账户登记在供应商名下，例如您的域名、主机或应用商店账户。
• 没有排除项，也没有退出条款。限制和绑定被藏在别的文件里。

简单的每月复查流程

设定一个每月重复的 30 分钟时段；如果有月度摘要，就邀请供应商的联系人参加。每次使用相同的议程。

1. 读清单。有什么新增、什么还没解决、什么等得最久？重新归类“不明确”的事项，并记录谁做了决定。
2. 核对工时。比较已用工时与包含工时，并留意最大的几项。
3. 找重复。同一个投诉出现三次，说明可能需要变更、培训或从根源修复。
4. 查日期。未来 90 天内的续期、即将到期的证书、快要结束的修复期。
5. 要证据。更新做了吗？最近测试过恢复吗？
6. 决定下个月的工作。选定工时用在哪里，并记下您拒绝的事项。

每年一两次，问问系统是否仍然适合您的工作方式。如果不适合，那是更大项目的讨论。

常见错误

• 把每个愿望都当成缺陷。这会损害信任，也拖慢真正故障的处理。
• 只用语音留言报告。没人能搜索语音，细节也会丢失。
• 不知不觉让修复期过去。把截止日期记入日程，并在此之前测试一遍所有功能。
• 在聊天里答应改动，却忘了账单。请先拿到书面报价。
• 关闭自己没有测试过的事项。

Gotka Technologies 的角色

Gotka 的应用与系统开发服务可开发手机应用、网络应用和业务系统，网络应用和仪表板起价 RM8,000，业务系统和系统对接起价 RM12,000，手机应用起价 RM15,000（均为参考起价），待需求明确后以书面报价为准。本指南不介绍 Gotka 的任何支持条款、修复期或维护合约，因此请要求任何供应商（包括 Gotka）在您签字前以书面写明。如果您还在选择开发方，请参阅自由职业者、内部开发者还是软件公司和第一次沟通前要准备什么。Gotka 另提供针对网站的可选每月 Care 方案，详见网站 Care 页面；它们并非软件系统的维护合约。欢迎通过联系页面与我们团队联系。

本指南中的关键术语

• 缺陷（bug）：与约定不符的行为。
• 变更请求：要求增加或修改约定之外行为的请求。
• 基准（baseline）：已验收的系统版本及其已签署的范围。
• 保修（缺陷修复）期：合同所定义的一段时间，其间开发方不另收费修复缺陷。
• 维护合约（retainer）：通常按月计、用于维护和支持系统的持续协议。
• 恢复测试：真正还原一份备份，以证明它可用。
• 变通办法：修复故障期间，暂时完成工作的方法。
• 排除项：协议写明不包含的工作。