在产品与工程之间最常见的矛盾之一是优先处理技术债。何故、何时以及如何处理技术债对组织和独立团队来说，都特别具有挑战性。常听到的问题有：
很多这类问题都是出于这样一个信念：技术债应该尽可能地低到零。但 公司和产品绝不会因为拥有尽可能少的技术债而取胜 。快速交付，率先进入市场，以及不断地为产品增加价值，这些都是取胜的因素。而要想取得更多的胜利，大部分技术债的积累都有意义，是一种交换。
正如现实生活中的债务一样，如果你现在承担技术债，那么今天你就能得到有价值的东西，并且在一段时间内偿还。这就是说，你应该将技术债视为组织长期成功的 战略杠杆 。
要把技术债视为战略杠杆，你需要：
阻碍真正谈论技术债的成见
本节将介绍导致技术债管理不善的 4 个基本假设：技术债被定义为具有历史意义的工作，它在功能、稳定性或速度等方面造成问题，如果以当现眼光来看待。
假设 1：技术债 = 坏账
毋庸置疑，技术债有着坏名声。解决技术债的一个难题是，你面对技术债的类型可能差异很大：一次小规模的实验性推广在本质上无害，但由于依赖多个服务，一种产品的重新设计可能会变得棘手。然而，由于未知的原因，大部分技术债都归为“不良”或“累赘”。其中一些未知因素的例子包括：业务影响可能缺乏 / 不明确 / 很难阐明，或者仍然无法确定其所需的工程时间。
现在，为了反驳“技术债 = 坏账”的假设：
从战略角度来看，上有一个关于技术债的具体例子：
要解决假设 1 的问题：技术债 = 坏账：
假设 2：所有技术债 = 复杂的工作
正如其他具有挑战性的工作一样，不仅仅是技术债，有几种方法来处理复杂性。特别是技术债，有几种处理已定义和未定义的问题的方法。
已定义 = 工作有明确的开始和结束。
未定义 = 工作有开始，终点却没有明确。
为了反驳“技术债 = 复杂的工作”的假设：
要解决假设 2 的问题：技术债 = 复杂的工作：
假设 3: 技术债 ≠ 产品工作
组织非常清楚他们所进行的产品工作将如何推动公司的指标——将每项实验、功能或改造与核心业务目标或 OKR 改进联系起来。技术债通常缺乏这种明确性，因此它与产品工作不正确地脱钩。解决技术债问题对于在合适的时候促进增长非常重要，即使它不会被立即量化。这有助于提高用户对软件的体验，或者帮助公司开启未来新功能。
为了反驳“技术债≠产品工作”的假设：
要解决假设 3 的问题：技术债 ≠ 产品工作：
假设 4: 个人痛苦 = 组织痛苦
工程师或者其他技术债关系密切的人常常会反复说，技术债对他们来说是痛苦的。他们可能会为纠缠于某些史前代码的 QA 而苦苦挣扎，或因为团队花太长时间采用一种新的编程语言而想放弃。对于他们来说，这位员工可能会觉得这是世界末日，而组织中其他成员可能也不会感到同样的痛苦（如果他们注意到的话）。这对那些在职业生涯早期的人来说尤其普遍，因为缺乏更广泛的战略背景，他们的痛点似乎是最重要的。
为了反驳“个人痛苦 = 组织痛苦”的假设：
要解决假设 4 的问题：个人痛苦 = 组织痛苦：
技术债的六种类型
技术债通常是个很大的总术语，包括从延迟速度、安全漏洞、重构到其他所有东西。 你需要了解你可能承担的不同类型的技术债，将其作为战略杠杆 ，而非总术语。这种分类将帮助整个组织的个人更好地了解手头的技术债的类型和涉及的内容，而不是含糊地谈论“技术债”。
下面是团队遇到的 6 种主要的技术债类型。值得注意的是，一个技术债可能不仅仅属于一种类别，这使得它有可能成为一个更关键的工作来解决。
维护债务
这是什么？团队没有跟上技术工作的更新。这包括在实验启动/特性推出/取消发布事件后，没有在正确时间删除死代码，更新库，注释上下文中的代码片段，并记录实现决策。
维护债务的例子：
开发者效率债务
这是什么？组织在产品上没有正确的测试、监控和 / 或警报。这是一种常见的债务类型，其中工程工作流效率很低，部署和构建时间可能要花费数小时或数天，而开发者缺少可以在产品上线之前发现技术问题的工具。
开发者效率债务的例子：
稳定性债务
这是什么？当组织建立不同类型的技术债时，又会影响其基础设施的稳定性。这就导致了这样的情况：你不是主动去管理待命人员，而是必须通过找主题专家或者间接地让整个团队待命，以被动的方式来管理待命人员。对于工程师和待命轮换团队来说，这成了很大的痛点，但公司其他人并不了解这个问题。稳定性债务还会影响产品的可靠性，使之成为面向客户的问题。
稳定性债务的例子：
安全性债务
这是什么？当技术堆栈中存在问题时，使得公司暴露在安全漏洞之下，比如暴力获取密码信息、数据泄露，或者竞争对手知道如何收集机密信息。这是因为人类很难计划和评估可能（或不可能）发生的假设，所以大多数组织都有大量安全性债务。
安全性债务的例子：
技术产品债务
这是什么？当产品受到明显的负面影响时。这项工作最容易解决，也最有说服力，因为它对用户有明显的影响，而且是向外的，组织中任何团队都能看到对客户和销售 / 收入的影响。
技术产品债务的例子：
决策债务
这是什么？当过去的技术决策在 X% 是错误的，或者在范围、时间或资源方面存在一些权衡，而现在团队要为此付出代价。它通常是最常见的技术债形式。
决策债务的例子：
评估技术债：急性与系统性
当你了解了将要承担的技术债的类型，需要确定它的成本，这样你就能将它与将得到的回报相比较。当团队问“我们什么时候才有时间处理技术债？”这一合理问题时，在时间、思想和努力方面，你很难知道这些问题涉及的是小事还是大事。
评估技术债有个范围，从急性到系统性。
急性技术债
较小规模的技术债。
例子：为了推出新特性，团队跳过了一些事件测量、监控、在较少使用的平台 / 浏览器上的实现等等。团队能够轻松地加入更新，并且可以迅速完成（如果没有其他障碍，则 <1 天）。
系统性技术债
相对较大到巨大的技术债。
例子：CTO / 创始人在 5 年前作出了一项产品（也是间接的技术）决策，从那以后，团队就一直为这个决策的影响而奋斗。更改决策意味着它将会影响到他们以后做出的每一个决策。它可以是关于核心产品设置、关键功能投资或用户体验，以及由此产生的设计 / 技术架构的决策形式。团队不能轻易地解决这种技术债，并且需要数月甚至数年才能完成。
急性 > 系统性的例子：开发者效率债务
值得注意的是，每种技术债都可以从其急性规模到系统性规模来衡量。例如，对于开发者效率的债务来说：
急性开发者效率债务
系统性开发者效率债务
从战略上优先考虑技术债
迄今为止，我们已经历过与技术债相关的假设、分类和规模。当你了解了这些知识后，你就可以在产品决策这一大背景下作出战略决策。
调整技术债的优先次序
战略性地看待技术债，关键是要了解什么时候把技术债扩缩地放到其他产品开发的优先次序中。要正确管理技术债，可以考虑以下几个向量：
在此基础上，每个向量应该按照低优先级到高优先级的标准进行分类：
这取决于技术债在整个综合规模中的位置（如下图所示），就很容易理解如何战略性地使用技术债应对公司的其他举措：
从上图来看，很明显，需要尽早解决系统的技术债，因为出现重大问题的可能性很大，问题很快就会迫在眉睫，债务会对达到既定的里程碑产生巨大的影响，而且已经产生了大量的累积债务。
若某些向量（如对用户和顺序的影响）较小，而且在左侧，则可以通过快速解决或在接下来几个月中解决问题的方法来 补修 问题。
若更多的向量（如对时间的影响、对用户的影响和顺序等）都比较小，而且在左侧，就有可能使这个领域的技术债在将来有意义的时候 积压 起来。
对于每一种情况（解决、补救、积压），都必须认真考虑技术债问题，跨越每个向量和从低到高的优先级范围。 用这种方式评估技术债能够使团队作出最佳的战略决策 ，以决定如何向前推进，而其他公司的举措也在考虑之中。
你的战略技术债组合，基于公司的成长阶段
另一个战略性地解决技术债问题的方法是基于技术债类型和组织规模来确定技术债组合。在 Reforge，我们将它归类为基于公司 S 型曲线的四个成长阶段：
与 S 型曲线相关，每一种技术债都应该根据公司的成长阶段得到适当的平衡。下面直观地显示，随着组织的发展，需要考虑技术债（按技术债类型）的分配的准则，以供参考。
在成长的每一个阶段，都要注意以下关键点：
牵引
拐点
规模
膨胀
管理技术债投资组合的入门技巧
在企业成长过程中管理技术债组合时，有几个关键领域需要特别关注：过程、工具、Sprint 和路线图。当你想减少一种科技债务的数量来平衡它时，你可以随着公司的发展而承担不同类型的科技债，下面就给出了一些快速指南要点：
减少技术债产生的过程
防止某些类型的债务形成的工具
反应性和急性技术债的 Sprint 工作
为主动性和系统性的技术债制定路线图
现在，要从作为负担的技术债过渡到作为战略杠杆的技术债
作者介绍：
Matt Greenberg，Reforge CTO，曾任 Credit Karma 的工程副总裁，也是 Scaling Product Delivery 项目的共同创造者。
Keya Patel，Reforge OIR，曾任 Headspace 的产品发展总监。
原文链接：
