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

技术债不是负担，而是成功的战略杠杆 本节将引见导致技术债管理不善的 4 个基本假设：技术债被定义为具有历史意义的工作，它在功能、稳定性或速度等方面形成问题，假如以当现眼光来看待。 假设 1：技术债 = 坏账 假设 2：全部技术债 = 简单的工作 假设 3：技术债 ≠ 产品工作 假设 4：个体苦痛 = 组织苦痛 假设 1：技术债 = 坏账 毋庸置疑，技术债有着坏名声。处理技术债的一个难题是，你面对技术债的类型可能差异很大：一次小规模的试验性推广在本质上无害，但由于依靠多个服务，一种产品的重新设计可能会变得麻烦。然而，由于未知的缘由，大部分技术债都归为“不良”或“累赘”。其中一些未知因素的例子包括：业务影响可能缺乏 / 不明确 / 很难阐明，或者仍旧无法确定其所需的工程时间。 现在，为了反对“技术债 = 坏账”的假设： 不应将全部技术债归为单一的“坏账”类别。将全部的技术债归入同一类别，会使人们感到处理优先级的问题很单调，由于这（看上去）和问题完全相同。那就像把全部的产品工作都归入“特性”。最好是把技术债分类，通过命名和评估苦痛来“打破”技术债，这样每个项目都可以独立存在，并且有机会被处理。在本文后面，我们将争辩命名和评估的问题。 有些技术债很好，每个团队都需要有技术债。这样做很有必要，由于这表明团队并没有盲目关注技术债，而是同时强调核心业务领域（如新产品开发、试验、合作伙伴支持等等）。每一家成功的公司都会在积累债务的同时扩大业务规模。把技术决策放在业务决策之前经常意味着组织不会活着看到本人的成长。 从战略角度来看，Twitter 上有一个关于技术债的具体例子： 自 2006 年成立至 2021 年，Twitter 通过公开可用的存储系统来扩展其产品和平台。 与晚期建立内部系统不同，他们依靠并贡献于开源数据库。最有可能的缘由是团队在其他关键业务方面取得了惊人的进步（获得用户、交付功能、盈利、IPO 预备）。 2021 年，Twitter 发布了下一代分布式数据库Manhattan，该系统能在实时环境下以极低的延迟处理每秒数百万次的查询。 由于推迟了投资（并积累了各种技术债），Twitter 在运营的第一个 8 年里取得了显著进步，随后就需要 Manhattan 从核心存储角度来支持下一阶段的进展。 “在 Headspace 团队，我们同时或快速连续地进行试验。开发者和项目经理将一起做出一个折衷的打算，即暂停清理试验。我们基本上是偷工减料来启动试验，然后留出一周清理一堆死代码。现实上，我认为这种技术债是乐观的，由于：[1] 它使工程师们可以集中精力于清理和维护，而不必在新的开发工作中进行环境切换，[2] 假如最新的试验结果消灭，供应了一些新的信息，从而转变作出决策的可能性。 ——Keya Patel （Reforge OIR，Headspace 的前产品进展总监） 要处理假设 1 的问题：技术债 = 坏账： 既然积累技术债，留待下个月处理，我们能得到什么？ 哪些情况下管理团队会对该领域的技术债感爱好？有什么信息可以供应应 CTO 来挂念他们更有效地宣扬？ 这一举措是怎样转化成一个更大的企业愿景或战略方向的？ 假设 2：全部技术债 = 简单的工作 正如其他具有挑战性的工作一样，不只仅是技术债，有几种方法来处理简单性。特殊是技术债，有几种处理已定义和未定义的问题的方法。 已定义= 工作有明确的开头和结束。 通往起点的道路可能无痛，也可能艰苦（取决于技术债的类型和规模），但有明确的结论和方法。 这种假设在技术债可以被定义的情况下会被推翻。 未定义= 工作有开头，起点却没有明确。 与“盒子里”定义的技术债相比，这更难处理和管理预期。 由于在 Reforge 的“扩大产品交付”项目中进行了深化的争辩，在这种情况下，由于事后加载了一些工作，很有可能转到一个更明确、不太简单的形态。 可预加载的工作包括：定义问题，从高层定义全部可能的处理方案，以及确定如何 / 何时实际进行修复或实施。需要留意的是，预加载的工作并没有涉及任何执行，而是有助于了解可能的前进方向。 例如，团队可以设置临时里程碑来降低技术债的简单性。或者，团队通过获得更多的历史信息，或花时间制造一个处理方案，从而从未定义转变为已定义。 为了反对“技术债 = 简单的工作”的假设： 要清楚手头的技术债能否被定义。假如已定义，要晓得完成该工作估计需要的时间或天数，并给一些缓冲时间。假如未定义，尽可能多地列出不清楚的地方，以说明为什么该工作比较简单，并且没有明确的结束日期，然后再与利益相关者沟通，猎取关于如何推动工作的最佳方法。 把未定义的技术债分解为更易于消化的工作，从而削减简单性。假如你从大面积的简单工作转移到小块、简单但又简约操作的工作中，团队在一次 Sprint 或季度的规定时间内处理技