如何将技术债务纳入路线图

多年来，Honeycomb 稳步增长，吸引了更多客户的同时也面临着扩展的挑战。伴随着成长的阵痛，Honeycomb 学习、适应，克服了一个又一个的障碍。这其中也伴随着各种各样的副作用，每一种都不一样，每一种都不可预测，每一种都将公司的系统推向了极限。尽管面临着这些挑战，该组织的基础设施仍然保持稳健，虽然我们在遇到新的意外情况时也会有点紧张。

在 2023 年 QCon 旧金山大会的演讲中，我介绍了我们如何应对业务翻番的挑战。

首先要做的是确定如何阐述一个有说服力的业务案例，以保证技术项目被优先安排。

理解优先级

与完成工作的能力相比，工作量一般都是过剩的。工程师会聚焦于产品路线图上的事项（新功能或功能增强），他们经常面临的挑战是如何安排必要工作的优先级以维持当前的运营。

产品经理安排的工作可能与维持基础设施的直接需求并不一致。从产品经理的角度来看，将技术需求置于路线图任务之上似乎会搞乱工程团队的关注点。例如，在创业公司的环境中，节省成本的措施，如减少 20% 的托管费用，可能会被忽视，他们更看重的是为最终用户或潜在客户提供更多的价值。

优先级排序过程

有一些先进的工具可以帮助产品经理将众多的想法和输入整合成提案以供工程评估。这些输入包括客户反馈、不断出现的想法、特定的业务评价等，必须把它们合并成业务服务、解决方案或待解决的问题。将每个反馈或想法重新定义为业务要解决的问题，形成一个全面的数据集。这样就可以突出反映业务面临的各种挑战，它们对客户的影响，以及增长或改进的机会，所有这些都是由产品组织策划。

在理解了这些想法之后，就可以将它们分成三类：好处明显的、好处不明显的和模棱两可的。在一次由 Jeff Patton 主持的研讨会上，我接触到了一个名为 Constable 事实曲线（Truth Curve）的图表。这张图表曾在 2013 年 QCon 旧金山大会 上出现过。

对于大多数落在中间蓝色区域的想法，有必要利用工具进一步理清，从而做出更具体的决策。有一些有效的框架，如机会画布和学习画布，可以帮助我们构建对问题的理解，确定谁受益或没有受益以及评估成本。借助这些框架，我们可以方便地围绕这些方面展开讨论。

这里的主要目的是通过评估项目对用户的影响、用户对变更的重视程度以及项目是否增强了用户经常使用的特性，来明确项目的投资回报。这个过程是产品管理的核心，其目标是彻底地回答这些关键问题。

软件的成本更高

处理技术债务的成本很高，它强调超越个体贡献层面来看待工程工作。通常，公司使用每个员工创造的收益作为标准来衡量每个员工为公司所做贡献的价值。粗略估计，每名工程师（通常占公司员工总数的 30-35%）可带来大约 100 万美元的收入。对于业绩最好的公司来说，这个数字可以飙升到每个工程师 200 万到 500 万美元。

重要的是要承认产品组织在功能策划和优先级决策方面所做出的重大努力。在评估技术债务（例如数据库升级）的业务价值和潜在回报时所使用的标准要与评估其他特性时所使用的标准相同。

一个特定的方法是围绕这项工作和优先级构建一个可信赖的业务案例。这包括在开展工作所获得的好处与所支付的费用之间取得平衡。这样的决策必须在业务当前的优先级和总体目标的框架内来做出，以确保我们的努力任何时候都与业务最重要的事情保持一致。

什么是技术债务？

技术债务的识别很复杂。它包含面向客户的特性，例如新功能和 Bug 修复，以及一些幕后工作，例如工具链、测试和法规遵从性，只有在出现问题时它们才会显现出来。此外，CI/CD 流程、培训和事件响应等运营方面的工作也是系统管理中至关重要的非代码组件。

Honeycomb 工程副总裁 Emily Nakashima 在“Anything But Tech Debt”一文中展示了下面的图表。

通常，狭义上讲，技术债务是指代码重构或依赖项升级，但实际上，它包括使产品适应新业务需求的各种任务。术语“技术债务”存在不同的解释，这有时会妨碍清晰的沟通。或许，根据业务影响来讨论工作是更有效的方法，这有助于将其整合到产品路线图中。

转换语言

在确定工程任务优先级和时间表的过程中，我们要把注意力从任务的细节（例如数据库升级）转到深入理解为什么要完成这些任务，并将它们与业务目标联系起来，这至关重要。例如，工程师可能会主张升级数据库，因为它的生命周期即将结束。然而，如果考虑到业务影响，比如托管提供商拒绝支持过时的数据库，这将威胁到产品的连续性，紧迫性就变得清晰起来。

突出对业务运营的直接影响（如潜在停机时间），为优先考虑此类升级提供了令人信服的理由。

作为工程团队，我们有在系统中生成和利用数据的独特能力，我们甚至可以为了获得新的见解而修改系统。这项能力使我们能够在讨论中利用数据证明我们的结论，而不是通过推测性的论点。

服务水平目标（Service Level Objectives，SLO）是连接技术指标与业务价值的首选工具。这主要是因为它们封装了用户体验指标，提供了一种具体的方法来阐释技术决策对业务结果的影响。Liz Fong-Jones 曾在 InfoQ 上做过一个关于“SLO 度量陷阱”的演讲。以往的事件也可以提供有用的指标。

工程师还可以访问揭示我们服务能力的指标，使我们能够进行混沌实验。通过有意限制服务，我们可以模拟压力条件，在潜在问题升级为实际事件之前发现它们。

此外，通过工程经验调查来收集定性反馈，特别是关于技术债务的，可以帮助我们获得有价值的见解。例如，由于特别复杂而被视为“闹鬼的墓地”的代码库可能会阻碍进展。解决这些问题不仅可以清理技术债务，还可以促进业务发展。

我们将把上述观点与之前一年半的经验结合起来。由于该组织是一家软件即服务（Saas）公司，所以年度经常性收入（ARR）是他们的核心业务指标。理解 ARR 的重要性——包括客户获取、升级和流失——可以帮助我们设定那些与数据库升级等技术任务不直接相关的行动的优先级。通过与销售和产品团队合作，我们获得了对客户行为和需求的详细见解。将这些信息转化为明确的技术指标，使我们能够将工程工作直接与业务价值联系起来，进而指导我们的基础设施规划和优化。

我们要求每个工程团队评估他们的服务，先全面概述，然后再确定潜在的瓶颈和可扩展性。他们评估了其服务与我们的销售目标的关系，考虑了摄入率等相关因素。在 SRE 团队的支持下，我们获得了一份标准化报告，详细描述了服务功能、依赖关系和可扩展性挑战。

例如，我们对最基本的 API 服务（对客户遥测数据摄入至关重要）进行了分析，揭示了其扩展限制和依赖关系。将这些发现与我们的销售预测结合起来，就确定了为达成增长目标而解决特定可扩展性问题（如数据库负载问题）的紧迫性。这种方法不仅可以确定当前技术工作的优先级，而且还为未来的可扩展性测试和调整提供了依据。

结合商业案例

项目的合理性瞬间变得显而易见。我们很有说服力地告知销售团队，解决数据库负载问题对于实现销售目标非常必要。在这种情况下，所需的技术工作安排直接就获得了批准。

将这种系统化的方法应用于所有服务，就形成了一个非常有条理的 Asana 看板，上面的任务根据紧迫性和相关性做了分类。这种做法还揭示了某些工程挑战，特别是那些被称为“explody”的挑战，突显了关键的可扩展性问题。这样的见解不仅推动制定了即时行动计划，而且还促进了对于更广泛的工程实践和可扩展性事项的讨论，重点阐释了一种平衡系统设计和优先级设定的方法。

完成闭环

通过这种方式，我们有效地利用了业务优先级来解决关键的技术问题，安排必要的修复，同时推迟不太紧急的任务。在这个阶段的计划快完成时，我们还会进行一个额外的步骤：庆祝成就。这样做的目的是通过这些项目的成功的解决方案来突出工程团队在解决业务挑战和促进增长方面的关键作用。这种认可不仅是对我们工作有效性的肯定，而且可以作为未来技术项目的有力佐证。

回顾过去使我们的服务能力实现显著提升的事件，展现工程方面的进步所带来的切实好处，可以提醒我们自己所取得的进展，以及使经常被忽视的技术工作具备可见性所带来的价值，提升组织敏捷性和产品质量。

小结

总之，为了有效地将技术债务解决方案集成到路线图中，至关重要的是，将它们与业务核心需求以及处理此类债务的潜在影响保持一致。必须将这些项目的成功作为业务增长的组成部分，阐明技术修复之外的业务价值。

用数据来证明这些项目的必要性和成果。一旦完成，重要的是要传达所产生的积极影响，并强调克服这些挑战如何推动业务突破了先前的限制。

原文链接：

https://www.infoq.com/articles/getting-tech-debt-on-roadmap/