技术债不是负担，而是成功的战略杠杆

在产品与工程之间最常见的矛盾之一是优先处理技术债。何故、何时以及如何处理技术债对组织和独立团队来说，都特别具有挑战性。常听到的问题有：

如何在技术债和特征工作之间取得平衡？
应当在技术债上多花点时间。何时才是解决问题的最佳时机？
如果领导团队连我们的技术栈都不了解，我又如何说服他们投资解决技术债的问题？

很多这类问题都是出于这样一个信念：技术债应该尽可能地低到零。但公司和产品绝不会因为拥有尽可能少的技术债而取胜。快速交付，率先进入市场，以及不断地为产品增加价值，这些都是取胜的因素。而要想取得更多的胜利，大部分技术债的积累都有意义，是一种交换。

正如现实生活中的债务一样，如果你现在承担技术债，那么今天你就能得到有价值的东西，并且在一段时间内偿还。这就是说，你应该将技术债视为组织长期成功的战略杠杆。

要把技术债视为战略杠杆，你需要：

确认并努力解决围绕技术债的负面假设。
分类和区分技术债的类型。
评估技术债。
在公司更广泛的产品工作组合和阶段中确定优先次序。

阻碍真正谈论技术债的成见

本节将介绍导致技术债管理不善的 4 个基本假设：技术债被定义为具有历史意义的工作，它在功能、稳定性或速度等方面造成问题，如果以当现眼光来看待。

假设 1：技术债 = 坏账
假设 2：所有技术债 = 复杂的工作
假设 3：技术债 ≠ 产品工作
假设 4：个体痛苦 = 组织痛苦

维护债务

这是什么？团队没有跟上技术工作的更新。这包括在实验启动/特性推出/取消发布事件后，没有在正确时间删除死代码，更新库，注释上下文中的代码片段，并记录实现决策。

维护债务的例子：

没有为“使用 Spotify 登录”帐户创建实验清理数月前的代码。
带领一位新工程师将 Spotify 登录纳入了他的第一轮功能工作的技术范围和文档中，因为他认为实验已经开始了。
实际上，最初的实验结果是负面的，团队没空清理他们的代码，因为他们必须继续进行新的实验。
新工程师感到很沮丧，因为 (a) 在他开始调查时，没人告诉他这是由于死代码造成的维护债务；(b) 没有制定团队流程来清理或至少注意到需要删除的代码。

开发者效率债务

这是什么？组织在产品上没有正确的测试、监控和 / 或警报。这是一种常见的债务类型，其中工程工作流效率很低，部署和构建时间可能要花费数小时或数天，而开发者缺少可以在产品上线之前发现技术问题的工具。

开发者效率债务的例子：

如果组织的工程师在一年内从 15 名增加到 50 名，由于在过去半年里在表面区域做了大量的实验，所以没有为新的购买体验设置全面的测试和警报。
结果，至少有 2~3 个版本的产品在生产中发现了 bug，团队必须迅速跟进并修复它们，因为它们被优先列为高严重性 bug。
具有采购流程所有权的团队将留出时间，在 Staging 中对关键业务进行适当的测试和修改。

稳定性债务

这是什么？当组织建立不同类型的技术债时，又会影响其基础设施的稳定性。这就导致了这样的情况：你不是主动去管理待命人员，而是必须通过找主题专家或者间接地让整个团队待命，以被动的方式来管理待命人员。对于工程师和待命轮换团队来说，这成了很大的痛点，但公司其他人并不了解这个问题。稳定性债务还会影响产品的可靠性，使之成为面向客户的问题。

稳定性债务的例子：

如果是移动应用（iOS、安卓），团队会优先考虑 iOS，因为在工程团队中 iOS 开发者较多。
因此，安卓应用缺少围绕关键业务流程（和需要到位的测试）的基本产品指导，并且还有 kryptonite 代码，这是由第三方供应商开发的初始功能。
当用户试图访问旧的功能时，安卓应用会崩溃。最后，这个产品在 Google Play 商店因其质量不可靠和经常出错而受到差评。

安全性债务

这是什么？当技术堆栈中存在问题时，使得公司暴露在安全漏洞之下，比如暴力获取密码信息、数据泄露，或者竞争对手知道如何收集机密信息。这是因为人类很难计划和评估可能（或不可能）发生的假设，所以大多数组织都有大量安全性债务。

安全性债务的例子：

如果一家公司因为内部流程的失误，并且没有分配正确的时间进行更新，未能修补某个已知漏洞，就会发生数据泄露。这导致了数以百万计的客户个人资料被泄露。
这种情况一直都在发生，其中有一些不知名公司的小事件，也有像 2017 年 Equifax 这样的重大违规事件（影响到 1.4 亿多人）。

技术产品债务

这是什么？当产品受到明显的负面影响时。这项工作最容易解决，也最有说服力，因为它对用户有明显的影响，而且是向外的，组织中任何团队都能看到对客户和销售 / 收入的影响。

技术产品债务的例子：

当用户在产品中加载某个特定动作时，明显需要额外的几秒钟。
虽然这可能是由开发者效率债务、稳定性债务或维护债务等潜在原因造成的，但它显然会影响到对核心产品的体验。

决策债务

这是什么？当过去的技术决策在 X% 是错误的，或者在范围、时间或资源方面存在一些权衡，而现在团队要为此付出代价。它通常是最常见的技术债形式。

决策债务的例子：

最初，有个团队决定用第三方供应商在他们的网站进行实验。经过几年的蓬勃发展，这个产品的网站每天都有数百万的独立访客。
因此，工程、数据和产品团队很难同时进行复杂的实验，因为供应商在流量、受众细分和排除等方面不能轻松地支持团队。
该问题是因为团队在选择供应商和建立内部实验工具时做出了权衡的决策，所以出现了决策债务。当时，这也许是正确的决策，但现在对了解团队的受众和流量需求对实验结果的影响很大。

评估技术债：急性与系统性

当你了解了将要承担的技术债的类型，需要确定它的成本，这样你就能将它与将得到的回报相比较。当团队问“我们什么时候才有时间处理技术债？”这一合理问题时，在时间、思想和努力方面，你很难知道这些问题涉及的是小事还是大事。

评估技术债有个范围，从急性到系统性。

信心：这样做有可能给团队造成严重问题吗？
时间：这将在什么时候成为一个问题？
对用户的影响：不这么做是否会导致速度和质量问题影响用户体验？
次序：这是否会妨碍团队完成重要的里程碑？
累积的债务：你选择累积的债务有多少？

在此基础上，每个向量应该按照低优先级到高优先级的标准进行分类：

从上图来看，很明显，需要尽早解决系统的技术债，因为出现重大问题的可能性很大，问题很快就会迫在眉睫，债务会对达到既定的里程碑产生巨大的影响，而且已经产生了大量的累积债务。

若某些向量（如对用户和顺序的影响）较小，而且在左侧，则可以通过快速解决或在接下来几个月中解决问题的方法来补修问题。

若更多的向量（如对时间的影响、对用户的影响和顺序等）都比较小，而且在左侧，就有可能使这个领域的技术债在将来有意义的时候积压起来。

对于每一种情况（解决、补救、积压），都必须认真考虑技术债问题，跨越每个向量和从低到高的优先级范围。用这种方式评估技术债能够使团队作出最佳的战略决策，以决定如何向前推进，而其他公司的举措也在考虑之中。

你的战略技术债组合，基于公司的成长阶段

另一个战略性地解决技术债问题的方法是基于技术债类型和组织规模来确定技术债组合。在 Reforge，我们将它归类为基于公司 S 型曲线的四个成长阶段：

在成长的每一个阶段，都要注意以下关键点：

牵引

切记这是在产品上市前的市场契合度。
此时，你的团队应该对速度作出决定，而非准确性、稳定性、流程等方面的决定——因此，开发者效率债务很大。
一般情况下，选择 Django、Rails 或 PHP 等全栈框架，然后快速开发，尤其是因为大部分早期产品都是粗糙的应用，需要很好地集成在 Web 和移动设备上。

拐点

此时，有迹象表明产品适合市场，而产品正在向可扩展的增长循环过渡。
团队意识到某些过程是必要的（因此开发者效率债务开始得到解决），并且仍然在寻找平衡内部过程和用户体验的最佳方法，因此技术产品债务增加。

规模

公司在快速成长中。
这一阶段中，技术产品债务和开发者效率债务开始下降 / 稳定，这是因为在过程和用户体验上更好的内部实践和平衡。
这一阶段，安全性债务、维护债务和决策债务都在增长，原因是增长速度很快，实际上无法跟上安全更新、清理和“修复”过去的决策。
规模也是测试自动化、部署系统、监控和警报、日志和检测、迁移、测试和临时存储以及 ETL 等领域中变化和纠正最多的地方。

膨胀

在这里，饱和度开始出现。此时，业务已经相当成熟。
因为有大量的历史代码和决策，维护债务和决策债务不断增加。
当团队在寻找新的成长机会时，开发者效率债务又开始增加了（核心增长和现有产品之外）。
技术产品债务、安全性债务和稳定性债务，经过前一段密集扩张期，正在趋于平衡。

管理技术债投资组合的入门技巧

在企业成长过程中管理技术债组合时，有几个关键领域需要特别关注：过程、工具、Sprint 和路线图。当你想减少一种科技债务的数量来平衡它时，你可以随着公司的发展而承担不同类型的科技债，下面就给出了一些快速指南要点：

减少技术债产生的过程

尽管积累技术债是战略问题，但通过实施过程来阻止技术债的产生甚至有时也很有意义。
在公司成长的拐点和规模阶段尤其如此，随着更多的工程师加入团队，开发者效率债务就会减少。开发者效率债务的减少可以让位于决策债务和维护债务的必要增加。
这些过程的一些例子包括代码 /PR 审查，监控标准，QA 签署，以及技术 / 设计审查。

防止某些类型的债务形成的工具

类似于上面提到的过程，基础工具的投资有时也能防止某些类型的债务的形成。
对于组织发展的规模阶段，这一点尤为重要，因为要采取更加一致的办法避免安全问题（安全性债务），防止可能影响用户体验的错误（技术产品债务），并允许代码一致性（开发者效率债务）。
例如 linter 和 CI/CD 管道就是这些工具的例子。

反应性和急性技术债的 Sprint 工作

如果组织的待命职责已经增加，那么待命 Sprint 就应该被用来救火（待命目的）或者与技术债有关的反应型工作（在待命救火的休息时间）。
这样，组织就可以在重大的技术债项目上取得进展，并通过待命团队对当前 / 过去的事件采取实际行动。
在成长的规模和扩张阶段，让那些待命人员从事这种反应性的工作特别重要，因为在解决严重的技术债之后，其他团队可以建立新的功能 / 产品，并承担额外的债务。

为主动性和系统性的技术债制定路线图

与使用待命的时间来处理反应性和急性技术债不同，在路线图中纳入技术债的做法应该适用于需要重大调整路线图和跨团队工作的债务。
在路线图中纳入技术债的例子有：在提出重大重写的建议期间，重新设计数据系统用于用户最重要的产品功能，围绕关键路径定义和实施警报，从一个收入 / 支付平台转移到另一个，以及其他可能需要数月才能成功实施的领域。

现在，要从作为负担的技术债过渡到作为战略杠杆的技术债

要意识到积累技术债能够帮助你的团队围绕要采取的举措作出全面的战略决策。
考虑团队可能会遇到的常见的技术债假设。你反对“技术债 = 坏事”，“技术债≠产品工作”吗？抑或你听说过同行认为“个人痛苦 = 组织痛苦”吗？
别再乱用“技术债”这一总术语了。把你面临的问题命名为维护债务、开发者效率债务、稳定性债务、安全性债务、技术产品债务和 / 或决策债务。
确定你的技术债规模，使其不那么模糊。这是急性的（短时间内解决）还是系统性（长时间内解决）？
从战略上优先考虑技术，而不是公司其他领域。你可以根据信息、时间、对用户的影响等向量来设置优先次序。
根据企业的发展和需要，平衡不断变化的技术债组合。

作者介绍：

Matt Greenberg，Reforge CTO，曾任 Credit Karma 的工程副总裁，也是 Scaling Product Delivery 项目的共同创造者。

Keya Patel，Reforge OIR，曾任 Headspace 的产品发展总监。

原文链接：

https://www.reforge.com/blog/managing-tech-debt

本文文字及图片出自 InfoQ

本文文字及图片出自

技术债不是负担，而是成功的战略杠杆

阻碍真正谈论技术债的成见