采访200名工程师的教训：管理技术债务的完美过程

我发现了许多公司缺少的东西，并将我的经验汇编成一个简单但强大的框架，与你们分享。

作为我们新的Step Size产品客户开发工作的一部分，我需要了解那些技术债务得到控制的软件公司和那些没有得到控制的软件公司之间的区别。

科技债务是一个情绪化的话题，它让人们谈论得无与伦比--而且它的争议性比政治小得多。只要问问你当地的工程师有关技术债务的事，你就会明白。但是你可能想先把你的日程安排清空。

在许多情况下(如果不是大多数情况下)，科技债务会不断积累，直到它造成无法忽视的问题。所以，你解决了这些问题，继续你的生活。而你也接受了这一点，也许这就是它是如何做到的。

但我们真的应该接受斯利普的研究结果吗？研究发现，在普通公司，工程师花了33%的时间处理技术债务，这会打击团队士气，并让公司每年花费约850亿美元？我们是不是该做点什么？

Gartner和其他许多人已经向我们展示了我们应该这样做。他们的研究显示，积极管理科技债务的组织发货速度至少会快50%。

幸运的是，我确实遇到了拥有坚实科技债务管理战略的公司。在这些采访中有很多令人兴奋的时刻。我最喜欢的例子之一是Everlan的工程经理詹姆斯·罗森(James Rosen)告诉我：

考虑一下PM花了多少时间来策划要处理的功能集。现在，将这与工程师们致力于为科技债务制定商业案例的时间和精力进行比较。几乎为零的工程产能被配置到科技债务上，这有什么令人惊讶的吗？

然而，我也遇到了很多团队，他们花了大量的时间和精力管理科技债务，但仍然一无所获。

我所有的研究都指向一个简单的事实。成功管理科技债务的公司已经制定了适当的流程，这些流程完全融入了他们通常的敏捷仪式，并已成为习惯。

这些工程团队控制着他们的技术债务。它们的运输速度更快，更容易预测。他们的工程师更高兴，他们的客户更高兴-见鬼，他们都赢了。

去那里真的不需要花太多时间。你只需要清楚你将如何处理大大小小的科技债务。

这是一种只要工程师在代码中发现就可以解决的技术债务类型，而且这在他们正在处理的罚单范围内。它可能像重构函数或重命名某些变量一样简单。试着遵循罗伯特·C·马丁的童子军规则：

这些琐碎的工作不需要任何形式的计划，每个工程师都应该感到有权在没有任何人批准的情况下解决这种债务。我们已经写了一个健康的代码库所需要的一个文化特征，但请确保它存在于您的工程团队中。如果没有，现在就采取措施解决它。

在这方面有很多工具可以帮助你。我们自己针对VSCode的技术债务指标扩展将直接在您的编辑器中给出代码质量评分和细分。其他代码质量工具，如Code Climate或Codacy，可以包含在您的CI管道和代码审查过程中，对此也很有用。

这种类型的科技债务可以在短时间内解决。它应该像任何特性工作一样经历相同的冲刺计划过程，并且应该被同样严格地考虑。这就是大多数工程团队失败的地方--还记得詹姆斯·罗森(James Rosen)的评论吗？他说：“几乎为零的工程能力被分配到科技债务上，这有什么令人惊讶的吗？”

企业正确地优先处理为客户带来价值的工作。而且，乍一看，摆脱科技债务并不能做到这一点。

要明确说明这是如何发生的，请找出阻碍关键计划的债务，或在工程师工作效率方面使企业损失惨重的债务，或者是影响客户体验的错误的原因。

记录科技债务并量化其成本，可以让你优先处理那些债务，如果得到解决，这些债务将为客户带来价值-就像新功能所做的那样。这家工程组织拥有科技债务。他们有责任解决这一问题，并最终为其制定业务案例。

JIRA是一个管理项目的好地方，但却是一个跟踪和监控科技债务的糟糕地方。

代码质量的工具有助于将科技债务的一个方面浮出水面，但它们不能捕捉到大多数其他方面。

幸运的是，这正是我们新产品的用途。工程团队处理科技债务的时间有限，他们需要让这些时间变得有价值。Step Size帮助他们从工作流程中捕获和跟踪技术债务，这样他们就可以量化其对企业的成本，并最终确定最重要的债务的优先顺序。

每个工程师都可以直接从他们的工作流程(包括编辑器、拉请求和松弛)报告技术债务及其成本。这些报告都被送到Step Size网站，在那里它们被整理成“技术债务项目”，描述并记录代码库中的问题。最后，每张吉拉门票都装饰着相关的技术债务项目，这些项目可能会被解决，以更有效地为客户提供价值。不再有从来没有优先考虑的孤独的重构票据-技术债务和商业价值变得真正一致。

我们建议工程团队领导承担管理这一过程的责任。在他们团队拥有的代码库中，他们是控制技术债务的合适人选，当需要解决债务问题时，他们也是与首相沟通的合适人选。

这是技术债务，不能立即解决，甚至不能一蹴而就。我采访过的最好的公司都有季度技术规划会议，所有的工程主管都会参加。工程经理的任务是强调向他们报告的大量科技债务，并为他们认为最重要的人提出商业案例。

这一过程听起来很费力，但对于分步大小的用户来说却变得非常容易。他们的个人贡献者已经定期报告了前线的债务。这些数据由每个团队及其领导始终如一地审查和培养，他们将大笔债务以及了解业务成本所需的数据传达给他们的工程经理。Step Size甚至为你的每一部吉拉史诗都带来了科技债务。然后，领导层可以利用他们对公司更广泛的优先事项和愿景的理解，相应地对大笔债务进行排序。

一旦每一大笔债务都获得批准，就可以将其安排到路线图上，就像专题工作一样。然后，工程领导层就拥有了监控每个科技债务项目进展所需的所有数据。

任何现代软件公司都应该能够对小型、中型和大型技术债务应用这一过程。然而，每家公司有一件事是不同的：业务目标。

妥善管理科技债务意味着解决阻碍您实现业务目标的债务。如果您的业务是建立在正常运行时间和可靠性的基础上，请清除任何会使其处于风险中的债务。如果速度是你的竞争优势，那就摆脱任何浪费工程时间或使新员工难以理解代码的债务。如果你想减少客户流失，解决导致质量问题的债务。

明确处理每笔债务的业务案例。因为当你这样做的时候，你会发布更好、更快的软件--而且你会让你的工程师满意。