利用 DX 和 AI 管理技术债务

每家公司，无论大小，都会担心技术债务。 Gartner估算 大约40%的基础设施系统存在这个问题。麦肯锡对CIO的一项调查显示，近三分之一的受访者认为 以上20％ 他们的新产品预算中有 100% 用于解决与技术债务相关的问题。但与许多人的想法相反，这不仅仅是一个编码问题，也是一个开发者体验 (DX) 问题。因为当开发人员不得不面对不完善的架构、过时的工具和低劣的开发工作流程时，生产力、性能和士气都会受到影响。

优先考虑开发人员的技术债务，关注他们的工作方式、使用的工具以及可以获得的职业发展机会，有助于团队集中精力并更快地交付产品。正因如此，在数字化转型 (DX) 和对人工智能工具日益关注的推动下，企业管理技术债务的方式正在发生变化。

支持 DX

开发人员的入职方式往往不尽如人意。一个人可能需要几周时间才能开始为项目做出贡献。当他们终于能够添加一些小功能或补丁时，经常会看到持续集成 (CI) 服务由于与他们所做的更改完全无关的原因而失败。这基本上是由于质量问题导致测试套件失败，而开发人员没有提交更改导致测试套件中断。这是一个不稳定、编写糟糕的测试，只有 90% 的时间有效。现有团队可能对此没有意见——它只是减慢了进程——但对于组织外部的任何人来说，工具可能已经过时并且令人沮丧。

这只是众多阻碍正确 DX 的因素之一。避免这种情况的一种方法是在软件工程和开发团队中指定一位负责人。许多小型组织没有 DX 负责人，但大型成功组织却有。这些专业人员会跟踪诸如新开发人员搭建环境所需的时间等信息。如果两周时间过长，他们会想办法将时间缩短一半。

市面上有一些工具可以提供帮助，例如 CircleCI，它本身就具备追踪测试套件不稳定性的功能。我们需要有人来牵头，并在每次冲刺后停下来，处理一些改进，使代码更易于维护和未来使用。归根结底，需要一位对改进 DX 感兴趣的领导者。为了实现这一点，我们需要一位高级工程师，并配备一位能够就可能存在的差距提供反馈的相对较新的员工。

此外，IDC 预计人工智能驱动的软件测试自动化市场将继续 到 31.2 年，复合年增长率将达到 2027%，因此请确保您充分利用这项技术。

指标和警告信号

在评估技术债务对团队的影响时，有很多指标可以追踪。一些基本的指标是“修复时间”或“功能发布时间”。假设您发现了一个 bug 并知道如何修复它。一些工具可以追踪从代码编写到生产所花费的时间。例如，您会发现一个非常小的补丁需要两个工作日才能修复并发布，而您的团队需要在几个小时内完成。您还可以追踪比率，例如 bug 修复数量与功能完成数量的比例。

还有一些方法可以识别士气问题何时会影响团队绩效。数字化转型领导者可以每季度进行一次调查，了解开发人员在某个项目或某个部分工作中的满意度。他们可以深入探讨具体领域，例如持续集成 (CI) 流程。此外，您还可以随时跟踪团队的人员流失或周转情况。如果您发现有人不断离职，他们可能会觉得自己的担忧没有得到重视。

利用人工智能

人工智能工具的兴起本应提高开发人员和工程师的生产力，加快产品交付速度，但技术债务却拖慢了这一进程。假设你使用 GitHub 或 Copilot 之类的工具来帮助修改代码，然后提交拉取请求，而持续集成 (CI) 需要几个小时才能回复你。在此期间，开发人员是否在做其他事情？查看电子邮件？这不仅会造成上下文切换，还会严重影响生产力。

开发人员希望开发的产品能够让他们专注于代码。工具可以帮助他们将代码投入生产，而不是成为持续的障碍。人工智能可以节省时间，但工程团队需要自行定义可接受的复杂度标准。为此，首先要确保添加到主分支的所有代码都具有可接受的技术债务水平。在此之前，应就技术债务和代码质量的可接受阈值进行公开讨论，并获得工程团队的认可。确保每个人都知道，超过该标准就需要立即进行补救。一旦定义了这些标准，人工智能就可以发挥作用了。

人工智能代理确实存在，工程师可以充当协调者。凯捷咨询公司对1,100名大型企业高管的调查显示， 82% 的企业计划整合人工智能代理 在未来三年内，它们已经影响到 工作的未来您可能正在查看错误报告，并发现它足够小，足以让 AI 代理从初始阶段到代码审查阶段进行处理，从而节省团队时间，让他们有时间处理更复杂的工作。然而，有时当我们盲目遵循这些工具时，AI 会难以权衡利弊。

这时候，人类的观点就成为决定性因素。

将技术债务与目标保持一致

如何将技术债务的减少与你试图实现的目标或可衡量的成果结合起来？这又回到了可接受的技术债务问题上，在商业领域，有时你必须快速交付。你当然知道产品无法扩展，而且随着时间的推移，可能会出现性能问题。通常，开发人员会记下来，等有时间再处理这些问题，但这种情况很少发生。而当这种糟糕的文化占据主导地位，你总是不得不明天就交付产品时，债务的影响就变得非常明显。

对于初创公司来说，这尚可理解，但对于一家运营了十年的公司来说，情况就完全不同了。你需要尽早积极地转变企业文化，以管理技术债务；否则，你将花费大量资金修复生产环境的 bug，或担心安全和合规性问题。

最后，有一些指标可以帮助向利益相关者传达重构或偿还技术债务的价值。时间可以是从项目启动到生产环境，或者从提交拉取请求到合并并交付到生产环境的时间。另一个指标是平均修复时间 (MTTR)。在这种情况下，您可能发现了一个 bug 或构建失败，您可以衡量团队修复它所需的时间。您还可以跟踪生产环境中的 bug 数量。如果您发现该数字上升，则可能存在与技术债务相关的问题。

有利息的技术债务

每个组织都可以每周花几个小时来改进其数字化转型 (DX)，以减少技术债务。否则，您以后可能会为此付出代价，例如性能下降、开发速度大幅放缓或出现安全问题。例如，您的工程师和开发人员团队可能已经推迟了十年才升级到 Ruby on Rails。突然之​​间，由于 Ruby 版本落后了四代，项目成本增加了 50 万美元，留下了大量代码和过时的依赖项。

如果你循序渐进地升级，就不会遇到这种情况。所以，支持你的软件开发团队，并按需付费。否则，这些技术债务会连本带利地回来困扰你。