使用DX和AI管理技术债务

每家公司，无论大小，都担心技术债务。根据Gartner的估计，大约40%的基础设施系统都存在这个问题。在麦肯锡对CIO的调查中，近三分之一的受访者认为，他们的新产品预算中有超过20%用于解决与技术债务相关的问题。但与许多人认为的不同，这不仅仅是一个编码问题，也是一个开发者体验（DX）问题。因为当开发者必须与不充分的架构、过时的工具和次级的开发工作流一起工作时，生产力、性能和士气都会受到影响。

通过优先考虑技术债务并关注开发者的需求，关注他们的工作方式、使用的工具以及可以获得的职业晋升机会，团队可以更好地专注并更快地交付产品。这就是为什么公司管理技术债务的方式正在改变，驱动这一变化的是DX和对AI驱动工具的关注。

倡导DX

开发者通常的入职流程令人不满。一个人可能需要几周时间才能开始为项目做出贡献。一旦他们终于能够添加小功能或补丁，不奇怪会看到持续集成（CI）服务由于他们工作无关的原因而失败。这基本上是由于质量问题导致测试套件失败，而开发者没有提交任何改变测试套件的代码。它是一个脆弱、写得不好的测试，仅在90%的情况下有效。现有的团队可能已经习惯了它——它只是减慢了流程——但对于组织外部的人来说，工具可能已经过时且令人沮丧。

这是阻碍正确DX的一个例子。防止这种情况的一种方法是在软件工程和开发团队中有一个指定的倡导者。许多小型组织没有DX领导者，但大型成功的组织有。这些专业人员跟踪诸如新开发者设置环境所需的时间等指标。如果两周太长，他们会想办法将时间减半。

有工具可以帮助，例如CircleCI，它具有原生的功能，可以跟踪测试套件的脆弱性。需要有人带头，在每个冲刺阶段结束后停止并解决一些问题，以使代码在未来更容易维护和使用。这归结为拥有一个对改善DX感兴趣的领导者。为了实现这一点，寻找一位高级工程师，并让一位相对新加入的员工提供有关可能的差距的反馈。

此外，IDC预计，AI驱动的软件测试自动化市场将继续以31.2%的复合年增长率增长，直到2027年，因此请确保您充分利用了这一技术。

指标和警告信号

评估技术债务对团队的影响时，有很多指标可以跟踪。一些基本指标是“修复时间”或“功能时间”。假设您发现了一个错误并知道如何修复它。一些工具可以跟踪从编码到生产的时间。例如，您可以看到一个很小的补丁需要两个工作日才能修复和交付，而您的团队需要在几个小时内完成它。你也可以跟踪比率，例如错误修复次数与完成的功能次数。

还有一些方法可以确定何时团队的士气问题会影响他们的表现。DX领导者可以每季度进行调查，以确定开发者在项目或项目的一部分中工作时的满意度。他们可以深入研究并询问特定领域，例如CI过程。你也可以跟踪团队的离职率或人员流动率。如果你注意到人们不断离开，他们可能会觉得自己的担忧没有被听到。

使用AI工具

AI工具的兴起应该使开发者和工程师更高效，产品也能更快地交付，但技术债务减慢了这一进程。假设你使用像GitHub或Copilot这样的工具来帮助代码更改，然后提交拉取请求，CI需要几个小时才能反馈。在此期间，开发者会不会在其他事情上工作？检查电子邮件？这是一个上下文切换和生产力杀手。

开发者希望在他们可以专注于代码的产品上工作。工具的作用是帮助他们将代码交付到生产环境中，而不是成为一个持续的障碍。AI可以节省时间，但由工程团队定义可接受的复杂性标准。为此，首先确保添加到主分支的任何代码都具有可接受的技术债务水平。在此之前，与工程团队进行公开讨论，并在技术债务和代码质量的可接受阈值上达成一致。确保每个人都知道，超过该标记需要立即补救。一旦您定义了这些标准，AI就可以发挥作用。

有一个案例是AI代理与工程师作为编排者。Capgemini对1,100名大型企业高管进行的调查显示，82%的受访者计划在未来三年内将AI代理集成到业务流程中，他们已经开始影响未来的工作。你可能会看到一个足够小的错误报告，AI代理可以从开始到代码审查处理它，节省你的团队时间，并让他们能够处理更复杂的工作。然而，有时当我们盲目地遵循这些工具时，会有AI难以考虑的权衡。

这就是人类的意见成为决定因素的时候。

将技术债务与目标对齐

如何将技术债务减少与您试图实现的目标或可衡量的结果对齐？这归结为可接受的技术债务，有时在业务中，您必须快速交付产品。您可以知道产品不具备可扩展性，并且可能会出现性能问题，但您仍然可以快速交付。通常，开发者会记下稍后再解决这些问题，但这种情况很少发生。当这种文化占据主导地位，即您必须不断地快速交付产品时，技术债务的影响变得非常明显。

这对于初创公司来说是可以理解的，但对于已经运营了十年的企业来说，这种做法是不可接受的。您需要尽早开始转变您的文化，并积极地管理技术债务；否则，您将花费大量资金来解决生产环境中的错误或担心安全性和合规性。

最后，还有一些指标可以帮助您向利益相关者传达重构或偿还技术债务的价值。时间可以是一个指标，从开始到生产，或者从打开拉取请求到合并和交付到生产。另一个指标是平均修复时间（MTTR）。在这种情况下，您可能已经发现了一个错误或一个破损的构建，并且您可以测量您的团队需要多长时间来修复它。您还可以跟踪生产环境中的错误数量。如果您看到这个数字增加，可能与技术债务有关的问题出现了。

带有利息的技术债务

每个组织都可以每周花费几个小时来改善DX并帮助减少技术债务。如果不这样做，您可能会后悔，可能会以性能变慢、开发速度大幅减慢或安全问题为代价。例如，您的工程师和开发人员可能已经推迟了十年对Ruby on Rails的升级。突然，一个项目的成本增加了50万美元，因为Ruby的版本已经落后四代，留下了大量代码和过时的依赖关系。

如果您逐渐升级，就不会陷入这种情况。因此，请支持您的软件开发团队，并随时付款。否则，技术债务将会以利息的形式回来困扰您。