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

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

• 如何在技术债和特征工作之间取得平衡？

• 应当在技术债上多花点时间。何时才是解决问题的最佳时机？

• 如果领导团队连我们的技术栈都不了解，我又如何说服他们投资解决技术债的问题？

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

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

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

1. 确认并努力解决围绕技术债的负面假设。

2. 分类和区分技术债的类型。

3. 评估技术债。

4. 在公司更广泛的产品工作组合和阶段中确定优先次序。

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

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

• 假设 1：技术债 = 坏账

• 假设 2：所有技术债 = 复杂的工作

• 假设 3：技术债 ≠ 产品工作

• 假设 4：个体痛苦 = 组织痛苦

假设 1：技术债 = 坏账

毋庸置疑，技术债有着坏名声。解决技术债的一个难题是，你面对技术债的类型可能差异很大：一次小规模的实验性推广在本质上无害，但由于依赖多个服务，一种产品的重新设计可能会变得棘手。然而，由于未知的原因，大部分技术债都归为“不良”或“累赘”。其中一些未知因素的例子包括：业务影响可能缺乏 / 不明确 / 很难阐明，或者仍然无法确定其所需的工程时间。

现在，为了反驳“技术债 = 坏账”的假设：

• 不应将所有技术债归为单一的“坏账”类别。将所有的技术债归入同一类别，会使人们感到解决优先级的问题很单调，因为这（看上去）和问题完全相同。那就像把所有的产品工作都归入“特性”。最好是把技术债分类，通过命名和评估痛苦来“打破”技术债，这样每个项目都可以独立存在，并且有机会被解决。在本文后面，我们将讨论命名和评估的问题。

• 有些技术债很好，每个团队都需要有技术债。这样做很有必要，因为这表明团队并没有盲目关注技术债，而是同时强调核心业务领域（如新产品开发、实验、合作伙伴支持等等）。每一家成功的公司都会在积累债务的同时扩大业务规模。把技术决策放在业务决策之前常常意味着组织不会活着看到自己的成长。

从战略角度来看，Twitter 上有一个关于技术债的具体例子：

• 自 2006 年成立至 2014 年，Twitter 通过公开可用的存储系统来扩展其产品和平台。

• 与早期建立内部系统不同，他们依赖并贡献于开源数据库。最有可能的原因是团队在其他关键业务方面取得了惊人的进步（获得用户、交付功能、盈利、IPO 准备）。

• 2014 年，Twitter 发布了下一代分布式数据库Manhattan，该系统能在实时环境下以极低的延迟处理每秒数百万次的查询。

• 由于推迟了投资（并积累了各种技术债），Twitter 在运营的第一个 8 年里取得了显著进步，随后就需要 Manhattan 从核心存储角度来支持下一阶段的发展。

“在 Headspace 团队，我们同时或快速连续地进行实验。开发者和项目经理将一起做出一个折衷的决定，即暂停清理实验。我们基本上是偷工减料来启动实验，然后留出一周清理一堆死代码。事实上，我认为这种技术债是积极的，因为：[1] 它使工程师们可以集中精力于清理和维护，而不必在新的开发工作中进行环境切换，[2] 如果最新的实验结果出现，提供了一些新的信息，从而改变作出决策的可能性。

——Keya Patel （Reforge OIR，Headspace 的前产品发展总监）

要解决假设 1 的问题：技术债 = 坏账：

• 既然积攒技术债，留待下个月解决，我们能得到什么？

• 哪些情况下管理团队会对该领域的技术债感兴趣？有什么信息可以提供给 CTO 来帮助他们更有效地宣传？

• 这一举措是怎样转化成一个更大的企业愿景或战略方向的？

假设 2：所有技术债 = 复杂的工作

正如其他具有挑战性的工作一样，不仅仅是技术债，有几种方法来处理复杂性。特别是技术债，有几种处理已定义和未定义的问题的方法。

已定义= 工作有明确的开始和结束。

• 通往终点的道路可能无痛，也可能艰辛（取决于技术债的类型和规模），但有明确的结论和方法。

• 这种假设在技术债可以被定义的情况下会被推翻。

未定义= 工作有开始，终点却没有明确。

• 与“盒子里”定义的技术债相比，这更难解决和管理预期。

• 由于在 Reforge 的“扩大产品交付”项目中进行了深入的讨论，在这种情况下，由于预先加载了一些工作，很有可能转到一个更明确、不太复杂的状态。

• 可预加载的工作包括：定义问题，从高层定义所有可能的解决方案，以及确定如何 / 何时实际进行修复或实施。需要注意的是，预加载的工作并没有涉及任何执行，而是有助于了解可能的前进方向。

• 例如，团队可以设置临时里程碑来降低技术债的复杂性。或者，团队通过获得更多的历史信息，或花时间创造一个解决方案，从而从未定义转变为已定义。

为了反驳“技术债 = 复杂的工作”的假设：

• 要清楚手头的技术债是否被定义。假如已定义，要知道完成该工作预计需要的时间或天数，并给一些缓冲时间。假如未定义，尽可能多地列出不清晰的地方，以说明为什么该工作比较复杂，并且没有明确的结束日期，然后再与利益相关者沟通，获取关于如何推进工作的最佳方法。

• 把未定义的技术债分解为更易于消化的工作，从而减少复杂性。如果你从大面积的复杂工作转移到小块、复杂但又容易操作的工作中，团队在一次 Sprint 或季度的规定时间内解决技术债方面的问题上更有动力。

“我们在 5 年内重写了 Credit Karma 的机器学习数据系统 3 次。每次重写的时候，技术负责人都相信这是很长一段时间内的最后一次重写。当时，他们做出了最好的决定，将重写作为定义工作，这是必须完成的。但如果你想一想，这项工作是没有定义的，因为公司和数据系统的发展和变化，你都无法预料。如果我们真的把它看作未定义的、不断发展的工作，那么，因为没有固定的终点，也许就更容易有新的想法了。”

——Matt Greenberg（Reforge CEO，前 Credit Karma 的工程副总裁）

要解决假设 2 的问题：技术债 = 复杂的工作：

• 对于该系统，我的哪些假设可能是错误的？

• 假如我邀请对该领域更有经验或更熟悉的人，我应该问他们哪些最重要的问题？

• 我的团队是否有合适的人员和知识来完成该工作？如不能，我如何重新安排信息，以及什么时候才能最适合解决该问题？

• 对那些对复杂情况一无所知的人，如何最好地分解这种技术债？

假设 3: 技术债 ≠ 产品工作

组织非常清楚他们所进行的产品工作将如何推动公司的指标——将每项实验、功能或改造与核心业务目标或 OKR 改进联系起来。技术债通常缺乏这种明确性，因此它与产品工作不正确地脱钩。解决技术债问题对于在合适的时候促进增长非常重要，即使它不会被立即量化。这有助于提高用户对软件的体验，或者帮助公司开启未来新功能。

为了反驳“技术债≠产品工作”的假设：

• 即便技术债的某一特定领域并非直接与指标挂钩，也要广泛地考虑它可能对未来用户和产品体验有帮助。同时强调这些用户和产品的好处，而非仅仅强调技术上的好处，将有助于其他人描绘出为什么团队需要关注这项工作。

• 分配时间来验证业务线索和技术线索是否一致。实现这一目标的途径是，产品与技术主管进行两周一次的对话，即产品与技术领导者之间的对话；建立联合的 Slack 渠道来展示技术债和影响；或者直接邀请合适的技术代表参加季度路线图预览。技术与产品之间的联系更为密切，让我们有机会在解决技术债的新实验中，哪些地方可能会出现中断，或者工程副总裁关于前 2 个基础设施相关请求如何整合。

“在 Airbnb，我们围绕面向服务的架构对我们的整个技术栈（1000 多万行代码）进行了大规模的重构，其重要原因之一就是实现一个能够启动多种其他业务的平台。在此之前，我们讨论的重点是开发者的生产力、团队士气以及其他以技术为中心的投资理由。我们意识到重构对解锁业务线也很重要，并且这一工作最终被列为公司上市前 S-1 文件中的六大优先事项之一。”

——Zainab Ghadiyali (Reforge OIR，Airbnb 平台的前产品主管)

要解决假设 3 的问题：技术债 ≠ 产品工作：

• 现在开展工作的最大理由是什么？

• 谁都需要理解它的影响？为什么要关心这个？

• 我想说的是什么？它符合利益相关者想听到的东西吗？如果不是，我如何解决他们的忧虑呢？

• 我 / 团队认为该工作的合理的结果与伟大的结果是什么？

• 对预期的结果承诺是否过高？为确定期望，能把结果分成好的和伟大的吗？

假设 4: 个人痛苦 = 组织痛苦

工程师或者其他技术债关系密切的人常常会反复说，技术债对他们来说是痛苦的。他们可能会为纠缠于某些史前代码的 QA 而苦苦挣扎，或因为团队花太长时间采用一种新的编程语言而想放弃。对于他们来说，这位员工可能会觉得这是世界末日，而组织中其他成员可能也不会感到同样的痛苦（如果他们注意到的话）。这对那些在职业生涯早期的人来说尤其普遍，因为缺乏更广泛的战略背景，他们的痛点似乎是最重要的。

为了反驳“个人痛苦 = 组织痛苦”的假设：

• 如果你已进入高优先级技术债领域，那就花一点时间来评估这是个人还是组织层面的痛点。一般来说，组织层面上的痛点可以直接影响到客户或者业务。

• 从比你更有组织背景的人的角度考虑问题。你甚至可以向不同团队的人表达痛点。假如你的个人观点适用于更广泛的领域，在其他受影响的同行和团队的支持下继续展示它。

“在我职业生涯的早期，我和团队正在准备一场重要的客户演示，这次演示可以带来一大笔销售额。为了做演示，我们偷工减料，时间很紧。在演示开始前的周末，另一个团队的一位工程师对我们的代码库进行了重大改动。他们启用了一项新特性，他们相信这将会是一个令我们高兴的时刻，但我们感到巨大的压力而又要退回。此时此刻，我才意识到背景的重要性，我的首要任务并不是其他人的首要任务。”

——Matt Greenberg（Reforge CEO，前 Credit Karma 的工程副总裁）

要解决假设 4 的问题：个人痛苦 = 组织痛苦：

• 对这些技术债的分类和解决方案有多少表面区域或团队能从中获益？

• 什么时候对承担技术债的个人予以表彰或奖励？那时是什么样的技术债，为什么需要它？能否跟那个人谈谈他们是如何定位这项工作的？

• 经理了解技术债工作的价值吗？在绩效考核中，他们会不会提倡我为这项工作所做的贡献？

技术债的六种类型

技术债通常是个很大的总术语，包括从延迟速度、安全漏洞、重构到其他所有东西。你需要了解你可能承担的不同类型的技术债，将其作为战略杠杆，而非总术语。这种分类将帮助整个组织的个人更好地了解手头的技术债的类型和涉及的内容，而不是含糊地谈论“技术债”。

下面是团队遇到的 6 种主要的技术债类型。值得注意的是，一个技术债可能不仅仅属于一种类别，这使得它有可能成为一个更关键的工作来解决。

维护债务

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

维护债务的例子：

• 没有为“使用 Spotify 登录”帐户创建实验清理数月前的代码。

• 带领一位新工程师将 Spotify 登录纳入了他的第一轮功能工作的技术范围和文档中，因为他认为实验已经开始了。

• 实际上，最初的实验结果是负面的，团队没空清理他们的代码，因为他们必须继续进行新的实验。

• 新工程师感到很沮丧，因为 (a) 在他开始调查时，没人告诉他这是由于死代码造成的维护债务；(b) 没有制定团队流程来清理或至少注意到需要删除的代码。

开发者效率债务

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

开发者效率债务的例子：

• 如果组织的工程师在一年内从 15 名增加到 50 名，由于在过去半年里在表面区域做了大量的实验，所以没有为新的购买体验设置全面的测试和警报。

• 结果，至少有 2~3 个版本的产品在生产中发现了 bug，团队必须迅速跟进并修复它们，因为它们被优先列为高严重性 bug。

• 具有采购流程所有权的团队将留出时间，在 Staging 中对关键业务进行适当的测试和修改。

稳定性债务

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

稳定性债务的例子：

• 如果是移动应用（iOS、安卓），团队会优先考虑 iOS，因为在工程团队中 iOS 开发者较多。

• 因此，安卓应用缺少围绕关键业务流程（和需要到位的测试）的基本产品指导，并且还有 kryptonite 代码，这是由第三方供应商开发的初始功能。

• 当用户试图访问旧的功能时，安卓应用会崩溃。最后，这个产品在 Google Play 商店因其质量不可靠和经常出错而受到差评。

安全性债务

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

安全性债务的例子：

• 如果一家公司因为内部流程的失误，并且没有分配正确的时间进行更新，未能修补某个已知漏洞，就会发生数据泄露。这导致了数以百万计的客户个人资料被泄露。

• 这种情况一直都在发生，其中有一些不知名公司的小事件，也有像 2017 年 Equifax 这样的重大违规事件（影响到 1.4 亿多人）。

技术产品债务

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

技术产品债务的例子：

• 当用户在产品中加载某个特定动作时，明显需要额外的几秒钟。

• 虽然这可能是由开发者效率债务、稳定性债务或维护债务等潜在原因造成的，但它显然会影响到对核心产品的体验。

决策债务

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

决策债务的例子：

• 最初，有个团队决定用第三方供应商在他们的网站进行实验。经过几年的蓬勃发展，这个产品的网站每天都有数百万的独立访客。

• 因此，工程、数据和产品团队很难同时进行复杂的实验，因为供应商在流量、受众细分和排除等方面不能轻松地支持团队。

• 该问题是因为团队在选择供应商和建立内部实验工具时做出了权衡的决策，所以出现了决策债务。当时，这也许是正确的决策，但现在对了解团队的受众和流量需求对实验结果的影响很大。

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

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

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

急性技术债

较小规模的技术债。

例子：为了推出新特性，团队跳过了一些事件测量、监控、在较少使用的平台 / 浏览器上的实现等等。团队能够轻松地加入更新，并且可以迅速完成（如果没有其他障碍，则 <1 天）。

系统性技术债

相对较大到巨大的技术债。

例子：CTO / 创始人在 5 年前作出了一项产品（也是间接的技术）决策，从那以后，团队就一直为这个决策的影响而奋斗。更改决策意味着它将会影响到他们以后做出的每一个决策。它可以是关于核心产品设置、关键功能投资或用户体验，以及由此产生的设计 / 技术架构的决策形式。团队不能轻易地解决这种技术债，并且需要数月甚至数年才能完成。

急性 > 系统性的例子：开发者效率债务

值得注意的是，每种技术债都可以从其急性规模到系统性规模来衡量。例如，对于开发者效率的债务来说：

急性开发者效率债务

• 对于只有 10% 的产品用户接触到的 MVP 推荐特性实验，工程师没有编写 Selenium 测试。

• 因为整个团队都承诺要在实验开始之前手工恢复这些特性，所以他们没有编写测试。

• 工程师后来花了数个小时加入测试，准备下一轮推荐实验。

系统性开发者效率债务

• 由于没有编纂测试和警报的实践，他们现在感受到了几年来产品指数级发展的痛苦。每一天至少有几次生产事件会影响用户，而 NPS 得分也在逐月下降。

• 当对新开发进行平衡时，添加所有测试和警报不可能在一夜之间完成。因此，技术主管的次序是：从创建测试和警报准则开始，本季度将这些准则应用到关键表面区域和特性 (P1)，然后是下一季度 P2 区域，再然后是下一季度 P3 区域。

• 在今年底或以后的 7~9 个月内，产品的所有领域都应按照新制定的准则，进行统一的测试和警报。所以，随着 P1 （以及随后的 P2、P3) 领域的解决，每日 / 周事件的数量应该会减少，客户情绪会开始上升。

从战略上优先考虑技术债

迄今为止，我们已经历过与技术债相关的假设、分类和规模。当你了解了这些知识后，你就可以在产品决策这一大背景下作出战略决策。

调整技术债的优先次序

战略性地看待技术债，关键是要了解什么时候把技术债扩缩地放到其他产品开发的优先次序中。要正确管理技术债，可以考虑以下几个向量：

• 信心：这样做有可能给团队造成严重问题吗？

• 时间：这将在什么时候成为一个问题？

• 对用户的影响：不这么做是否会导致速度和质量问题影响用户体验？

• 次序：这是否会妨碍团队完成重要的里程碑？

• 累积的债务：你选择累积的债务有多少？

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

• 信心：技术债由低到高引发重大问题的可能性在哪里？

• 时间：在不紧急到紧急的范围内，这部分技术债什么时候会成为一个问题？

• 对用户的影响：在从低到高的范围内，在什么地方不做这种技术债，会导致速度和质量问题，并损害用户体验？

• 次序：在影响最小到影响最大的范围内，这种技术债会在哪些地方阻碍团队完成重要的里程碑？

• 累积的债务：已累积的技术债的数量在最小到最大的范围内下降到哪里？

这取决于技术债在整个综合规模中的位置（如下图所示），就很容易理解如何战略性地使用技术债应对公司的其他举措：

• 由于技术债持续恶化会损害其他产品和业务计划，需要尽早解决吗？

• 是不是需要临时的补救措施，以便暂时开发更具潜力的项目？

• 由于优先级低，特别是在于公司 / 团队的其他计划重叠的情况下，这实际上是一个可以等待清理期的技术债。

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

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

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

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

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

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

• 牵引= S 型曲线的底部，产品上市前市场契合度。线性的、不可扩展的努力，使成长的引擎运转。

• 拐点= S 型曲线的弯曲部分，产品市场适合小规模的明确信号。由一个不可扩展的增长循环转变为一个可扩展的增长循环。

• 规模= S 型曲线的超增长部分。优化核心增长循环。在有效的方面下双倍的注。

• 膨胀= 接近 S 型曲线的顶部，饱和度开始上升。PMF 膨胀需要考虑，整个流程的重新启动，或者在新的增长循环上分层。

与 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