采访了200多位工程师，我找到管理技术债的好方法

我们的新产品是客户开发工作的一部分。因此，我需要深入了解软件公司之间的差异，他们的技术债务有哪些可控，还有哪些是不可控的。技术债务是一个感性话题，提起它，人们就会喋喋不休。关于技术债务，你去问问公司的工程师就知道了。

在很多情况下（如果不是大多数情况的话），技术债务会不断累积，像“滚雪球”一样，直到产生严重问题。

Stripe 的一份研究发现：在一般的公司中，工程师们要花费约 33% 的时间来处理技术债务。技术债务不仅打击了团队士气，而且每年给公司造成约 850 亿美元的损失。看到这种情况，我们是不是该做点什么？

https://stripe.com/files/reports/the-developer-coefficient.pdf

Gartner 和许多其他公司让我们知道，应该做点什么。他们的研究显示，积极管理技术债务的组织能将其交付速度至少提高 50%。

幸运的是，我确实遇到一些公司，它们的技术债务管理策略非常可靠。在这些采访中，有很多让人眼前一亮的时刻。Everlane 的工程经理 James Rosen 告诉我：

考虑一下，PM 花了多少时间来策划要开发的特性集。现在，把这个时间与工程师们为技术债务寻找商业理由的时间做个比较。分配到技术债务上的工程能力几乎为零，这还那么令人惊讶吗？

我必须承认，这并不那么令人惊讶。

然而，我也遇到很多团队，他们花了大量时间和精力来管理技术债务，最终却一无所获。

我所有的研究都指向一个简单事实：成功管理技术债务的公司不仅开发出适当流程，而且还将这些流程完全融入了它们日常的敏捷行动中，成为一种好习惯。

这些工程团队控制住了他们的技术债务，因此，他们的交付速度更快，更可预测。结果，不仅他们的工程师很高兴，而且客户也很高兴——双赢！

做到这种程度，实际上无需付出太多。你只需要清楚——如何处理小型、中型、大型的技术债务。

工程师在代码中发现这种技术债务时就可以顺手解决，而且这也在他们正在进行的工作范围内。或许，它就是简单的重构函数或重命名变量。

Robert C. Martin 说道：”总是让代码比你发现它时更好。“

这类小工作不需要任何类型的计划，每个工程师都有权力在没有任何人批准的情况下解决这类债务。在这篇文章中，我们讨论了健康代码库所需要的一个文化特质，要确保你的工程团队具备这样的特质。如果不具备，现在就采取措施解决这个问题。

https://blog.stepsize.com/the-one-cultural-characteristic-you-need-for-a-healthy-codebase/

在这方面，有许多工具可以帮助你，比如 Code Climate、Codacy、Tech Debt Metrics extension for VSCode。

这种类型的技术债务可以在一个冲刺内被解决。它应该像任何特性工作一样经过同样的冲刺计划过程，并被严格地考虑。

大多数工程团队都没有做到——还记得 James Rosen 的评论吗？Rosen 说，“分配到技术债务上的工程能力几乎为零，这还那么令人惊讶吗？”

企业优先考虑为客户提供价值的工作，这是对的。况且，处理技术债务并不能做到这一点。

但技术债务却阻碍了你向客户提供价值的能力。

要明确说明这是如何发生的，请确定哪些债务妨碍了关键的主动性工作，或者在工程师生产力方面让企业损失惨重，或者是导致影响客户体验的 Bug 原因。

记录技术债务并量化其成本，这让你可以优先考虑这些债务，如果解决了这些债务，就会像新功能一样为客户带来价值。技术债务归工程组织所有。他们的责任是解决它，并最终为它提供商业理由。

遗憾的是，这正是我们现有的工具迄今未能做到的地方。

Jira 很适合管理项目，但跟踪和监控技术债务却很糟糕。——Unqork 首席工程师 Jake Peyser

代码质量工具只有助于发现一方面的技术债务，但其他大多数就无法捕获了。

https://blog.stepsize.com/7-examples-of-sneaky-tech-debt-and-how-to-spot-them/

工程团队处理技术债务的时间有限，他们需要充分利用这些时间。

幸运的是，Stepsize 可以帮助他们从工作流中捕获和跟踪技术债务，这样他们就能量化其造成的业务成本，并优先处理最重要的债务。

每个工程师都可以直接从他们的工作流（包括编辑器、PR 和 Slack）中报告技术债务和成本。这些报告都会被送到 Stepsize 网站，它们在那里被整理成“技术债务项”，描述和记录代码库中的问题。最后，每一张 Jira 工单上都会加上相关的技术债务项，解决它们可以更有效地为客户提供价值。

我们建议工程团队负责人承担管理这个过程的责任。他们个人掌握其团队所拥有的代码库中的技术债务，并在需要解决债务的时候与 PM 沟通。

这种技术债务不可能立即解决，甚至不可能在一次冲刺中解决。我采访过的最好的公司每季度都有技术规划会议，所有的工程主管都会参加。工程经理负责重点介绍汇报给他们的大型技术债务，并为那些他们认为最重要的债务提出商业理由。

这个过程听起来很费力，但对于 Stepsize 的用户来说却非常容易。他们的个人贡献者已经定期报告来自一线的债务。这些数据由每个团队和他们的领导者持续地审查和整理，他们将大量的债务——以及理解业务成本的必要数据——传递给他们的工程经理。Stepsize 甚至可以揭示每个 Jira 史诗的技术债务。然后，领导层可以利用他们对公司更广泛的优先事项和愿景的理解，对大型债务进行相应地排序。

每个大型债务经过批准后，就会被安排到路线图中，就像特性工作一样。这样，工程负责人就有了他们需要的所有数据，可以监控每个技术债务项的处理进展。

任何现代软件公司都应该能运用这个过程来处理小型、中型、大型的技术债务。然而，不同的公司之间有一点不同：商业目标。

妥善管理技术债务意味着解决阻碍你实现商业目标的债务。如果你的业务是建立在正常运行时间和可靠性的基础上，那就把任何会让它们处于危险中的债务偿还掉。如果开发速度是你的竞争优势，那么就消除任何浪费工程时间或增加新员工理解代码难度的债务。如果你想减少客户流失，就解决导致质量问题的债务。

明确处理每一笔债务的商业理由。因为当你这样做的时候，你就会更好、更快地交付软件——而且可以让你的工程师们开心。

原文链接：

https://blog.stepsize.com/the-perfect-process-to-manage-tech-debt/