软件债务的累积会消耗巨大成本

最近有一篇名为《系统变老，仍可交付更多价值》的文章，作者 Chris Sterling 在其中讨论了“软件债务”的概念——“如果只想着编译马上通过，而忽略系统随时间推移本应具有的可变性，软件债务就会不断积累。”在他看来，软件债务要比技术债务影响更为恶劣。

他认为软件债务由以下 5 个部分构成：

• 技术债务：现在不去做、没有完成的事情，将会在未来对开发工作产生负面影响。
• 质量债务：难以验证整个系统的功能和技术质量。
• 配置管理债务：集成和版本发布管理变得更具风险、复杂，而且更易于出错。
• 设计债务：要想加入一般复杂度的功能，其成本不断增加，并超出如果从头开发要付出的成本。
• 平台经验债务：能够开发系统功能的人力资源受限。

他还说到软件债务如何在项目中潜伏下来，还提到项目中如何随时间推移积累软件债务，他指出：债务发生之时，项目经常面临复杂度的不断增加，在这种情况下仍希望产生最好的激励，并维护交付的正常节奏，就会积累债务。

Bill Curtis 以同样的基调讨论了 Muda （即日语中的“浪费”）对软件项目的影响：软件项目中最常见的浪费来源就是返工，这往往是软件债务的结果：

少数对返工的研究指出：在大多数未能成功推行流程改进的组织中，返工所占的项目工作量介入 30% 到 50%。这个数字令人痛苦不堪，不仅在收集数字时如此，而且想让人们承认也是难上加难。没有几个公司高层愿意承认他们在应用开发上浪费了 40% 的投入。

Sterling 提出几种管理和减少软件债务的方法：

• 整理一个工作列表
• 强调质量的重要性
• 不断改善工具和基础架构
• 持续提升系统设计
• 在组织中共享知识
• 最重要的一点：雇佣正确的人来开发你的软件！

他在这篇文章中给出了如何做到上述措施的建议。

在文章的结尾，他说道：

系统使用时间越长，就越难做出调整。当软件债务以技术债务、质量债务、配置管理债务、设计债务和平台经验债务的形式潜入系统之中，软件资产就变成负债了。 应用本文中的 6 原则，就能带来小的改变，随时间推移，这些细微改变就会为团队和组织带来显著的正面影响。管理软件债务的目标是要优化我们行业中软件资产的价值，从而增加客户使用软件时的满意度。

您的组织如何做到降低软件债务、保护他们在软件系统中的投资？