软件维护成本：没人做进预算的部分

软件维护成本，就是那个把一个成功项目在十八个月之后变成一场难堪谈话的数字。开发阶段有预算、有审批、也如期交付了。可上线之后会发生什么，被一句「支持服务」轻轻带过，然后配上一个有人凭感觉给出的金额，而那个金额几乎每一次都太小。

原因出在结构上，不是谁不上心。开发有一个可以定价的范围。维护没有范围，因为决定它的是还没有发生的事情：某个依赖库爆出漏洞，某个供应商改掉了自己的接口，某个用户碰上了当初谁都没想到的情形。

人人都在引用的经验法则是每年按开发成本的 15 到 20 个百分点计算，而它之所以危险，恰恰是因为它离正确答案不远。 它对的次数多到让人放心，错的时候又总是朝同一个方向错：它低估了缺陷集中冒出来的第一年，而在有合规义务或者外部集成很多的系统上，它会彻底失效，因为在那样的系统里，推动工作发生的是外部事件，而不是你自己的代码库。

软件维护成本实际包含什么

一共五类性质不同的工作，把它们混在一起算，正是错误数字的来源。

纠正性工作。 修复缺陷。它集中在前期，因为大多数问题会在真实使用的头几个月里浮出来，这也是百分比规则唯一处理得还算像样的一类。但每一件的分量事先都看不出来，本以为只是小修，最后却牵扯到设计的重新审视。

适应性工作。 跟上那些不由你决定的变化。某个依赖发布了安全补丁。某家支付服务商停用了一个接口版本。某个浏览器改了行为。这些都不会给产品增加任何新功能，但每一项都是必须做的。

预防性工作。 在被迫升级之前先升级。跳过它并不能消除开销，只会把开销往后推并且让它继续变大，一次寻常的框架升级最后拖成三个月的工程，走的就是这条路。

日常运维。 托管、监控、备份、证书，以及盯着这些东西的人所花的时间。它常常被单独记账，这没有问题，只要真的有人在记。

小改动。 系统一旦有了真实用户，就会源源不断地产生调整需求。单看每一条都无关紧要，加在一起，在大多数年份里却是最大的一类。每一条看上去十分钟就能搞定，可把核对、上线和回复都算进去，半天也就没了。

人们平时说的维护，只指第一类。预算不够用的原因，在另外四类身上。

百分比规则为何会误导人

因为它锚定错了量。维护的工作量取决于活动部件有多少，以及外部世界改动它们的速度有多快，而不取决于当初开发碰巧花了多少钱。

两个用同样预算做出来的系统，投入可以相差三倍。一个自成一体、只有两个依赖、不受监管约束的应用，维持运转很便宜。一个接入了六个第三方服务、处理个人数据、还要遵守行业规则的系统就不是这样，因为其中每一个集成，都是一处你排不进自己日程的工作来源。

百分比还假设存在一种稳定状态，而第一年根本没有这种状态。真实使用会把缺陷找出来，上线之后的头六个月通常远高于全年平均水平，之后才慢慢落下来。

更好的估算从活动部件开始。数一数集成的数量、需要承担的合规义务，以及会产生咨询和报障的用户规模，再给这些事情实际消耗的时间定价。我们关于定制软件开发成本 的指南，讲的是同一道算术题的开发那一侧。

团队漏掉的开支项

依赖库升级。 这不是可选项，因为没有打补丁的库正是系统被攻破的通道，而工作量真的无法预料，因为它取决于上游维护者做了什么。

第三方接口变更。 供应商停用一个版本，并且给你一个期限。时间不是你定的，你也没法拒绝。

证书与域名续期。 微不足道的小事，直到某一个在周末过期，站点随之打不开。

监控，以及对监控的响应。 没有人去响应，告警就毫无用处，而那份随时能顶上的状态是实打实的成本，无论那个月有没有出事。

知识交接。 人是会走的。下一个人把系统弄明白所要花的代价，就是一笔维护成本，而且当初写下来的东西越少，这笔代价越高。

数据增长。 存储费用往上走，原本很快的查询开始变慢，而处理这些问题的工作，按照你自己成功的节奏找上门来。我们关于数据库性能 的指南，讲的是这件事在实践中的样子。

在英国大概是多少钱

维护一套定制系统的大致年度区间，假设交给外部服务商而不是自己养人。

这些数字不含托管和许可证，二者单独计费，差异极大。它们同时假设系统处在还算过得去的状态。如果要接手的是一套没人写过文档、没有测试、只有一个人看得懂的系统，费用会更高，而且带着任何合同都消不掉的风险。

该怎么安排合作方式

约定工时的包月合同适合工作量大体可预测的情况。你买到的是随时可用的响应能力，而你付的钱大部分正是为此；没用完的工时并不算浪费，因为另一种选择是根本没人可找。

按工时与实际投入结算适合变化很少的系统，但响应速度就是服务商其他承诺所允许的速度，这是你接受的交换条件。

固定价格的支持合同把风险移到服务商那边，服务商则会把这份风险算进费用里。对于可预测性比利润率更值钱的关键系统，这是合理的做法。

无论选哪一种，都要在真正需要之前，先谈好什么算维护、什么算新功能。这条界线是支持关系中几乎所有争执的源头，而在一开始把它定下来不花一分钱。

作为软件开发 业务的一部分，Mecanik 既维护自己做的系统，也维护不是自己做的系统。任何一次接手，第一个月通常都花在文档上：把运行历史、已知缺陷和外部集成清单一条条写下来。因为正是这份文档决定了之后每个月的成本。

延伸阅读： 固定价格合同还是按工时结算？ 、怎样写出能拿到有用报价的软件需求书 、软件源码托管：到底谁真的需要 以及MVP 软件开发：范围、成本与周期 。

常见问题

软件维护每年要花多少钱？ 常见的经验法则是每年按开发成本的 15 到 20 个百分点计算，但它低估了缺陷集中冒出来的第一年，在集成很多或者带合规义务的系统上更是完全失效。英国的大致区间是：集成很少的小型内部工具每年 £6,000 到 £15,000，受监管或高流量的平台则在 £60,000 以上，均不含托管费用。

软件维护实际上包括哪些内容？ 五类：修复缺陷的纠正性工作，跟上依赖与第三方接口变化的适应性工作，在被迫之前先升级的预防性工作，托管与监控这样的日常运维，以及线上系统源源不断产生的小改动。大多数人所说的维护，只指第一类。

按开发成本百分比估算为什么不可靠？ 因为它锚定错了量。维护工作量取决于活动部件的数量，以及外部世界改动它们的速度，而不取决于开发花了多少钱。两个用同样预算做出来的系统，可能因为集成数量、监管约束和报障量的不同而相差三倍。

团队最常漏掉哪些维护开支？ 依赖库升级、第三方接口停用并附上你无权决定的期限、证书与域名续期、监控告警背后那份随时能顶上的人力、人员离职时的知识交接，以及数据增长对存储费用和查询速度的影响。

该选包月合同还是按需付费？ 约定工时的包月合同适合可预测的工作量，买到的是随时可用的响应能力，而你付的钱大部分正是为此。按工时与实际投入结算适合变化很少的系统，但响应速度取决于服务商的其他承诺。无论选哪一种，都要在真正需要之前，先定义清楚什么算维护、什么算新功能。