沟通技术债务

商业视角

代码分析

与业务利益相关者沟通的技巧

结束语

许多开发者觉得，当我们谈论技术债务时，产品管理和高管领导层并不“理解”。与此同时，如果你问开发者，项目长期成功的关键因素是什么，偿还技术债务肯定名列前茅。那么，我们该如何沟通技术债务，才能弥合这一差距呢？

作为一名开发经理，我的核心工作之一就是充当产品管理和开发团队之间的桥梁。让我来分享一下我目前为止行之有效的方法。

这篇文章的灵感部分来自 bob.js关于技术债务会计的精彩文章，并旨在作为该文章的配套文章。

技术债务会计

bob.ts ・ 2019年9月30日

#webdev #technicaldeb #development #programming

定义技术债务

让我们从韦氏词典对债务的定义开始：

债务：有义务向某人或某物支付或偿还以换取所收到的东西的状态：欠债的状态

在这种情况下，我们暂时利用某些东西，同时承担偿还义务，从而产生技术债务。

技术债务的本金和利息

进一步说，随着时间的推移，我们会为债务支付额外的利息，这意味着一小块技术债务会随着时间的推移变得更大。

举个例子，如果我们在实现某个功能时偷工减料，复制一个方法并进行轻微修改，那么每次我们需要对这两种方法进行修改时，我们都会对该决定产生兴趣。

即使实际上只修改了一种方法，未​​能修改重复的方法也可能构成一个错误，从而以等待遇到的隐藏错误的形式将一种质量债务引入应用程序。

在这个例子中，技术债务的原则是初始实施期间节省的时间，而利息是该决策直到解决为止所产生的额外时间、质量和风险成本。

在谈论技术债务时，我特别喜欢用金融类比，因为它将一些对业务导向的专业人士来说隐藏且未知的东西，用他们日常工作中接触到的术语来表达。

这也凸显了虽然技术债务在短期内可能是有利的（当支付的利息低于借入的本金时），但从长远来看可能是毁灭性的。

技术债务的惩罚

上面我提到了，当技术债务生效时，未来项目所付出的开发时间惩罚会增加。这可能是我们开发者所谈论的最大形式的技术债务。

此外，我们还讨论了质量债务，它是由脆弱且难以维护的代码、缺乏单元测试以及代码重复导致的修改行为不一致而产生的。在处理技术债务繁重的代码时，我们会承担这种风险，并以利息的形式偿还。

我们为技术债务付出的另一种代价是应用程序性能不佳。这通常是在技术债务处于设计层面时付出的代价，因为大多数性能问题最终都会被证明是系统流程设计不良造成的。没错，你可以连续数天甚至数周对代码性能进行战术性改进，但到了一定程度，除非你重新设计时充分考虑性能，否则很难再获得进一步的改进。

安全漏洞是另一种风险，我们可能会以技术债务利息的形式承担。然而，独特的是，这种风险不仅仅体现在代码更改上，而是从漏洞出现之日起就一直存在，直到漏洞被解决为止。

最后，如果开发人员编写的代码不达标，我们会对他们的士气造成打击。然而，这种情况通常不仅限于开发人员，因为许多开发人员会大声说出他们发现的更有趣的代码片段，这会影响到任何听到的人。

我进一步指出，代码库中的糟糕代码会鼓励项目进行不合格的工作，因为它被证明是可接受的工艺水平，所以这种形式的债务会鼓励未来的债务。

与企业讨论技术债务

好的，现在我们已经讨论了什么是债务以及在债务解决之前我们要支付的利息，让我们来讨论如何将这些事情传达给业务利益相关者。

首先，产品管理和业务利益相关者不是你的对手。他们是你的关键合作伙伴。任何与业务部门就代码进行的讨论都需要以信任和尊重为核心——双方都要如此——否则必然会产生摩擦，成功的可能性也会大大降低。

我想更进一步说，与业务伙伴建立信任、合作和尊重的关系对于项目的长期成功来说比技术债务更为重要。

为了与业务利益相关者进行健康、富有成效的对话，您至少需要做以下事情：

• 对话时，务必增进彼此间的理解。你需要告知他们当前和未来的障碍，以及过去决策所付出的代价，你需要倾听并理解他们的需求。
• 你需要具备极高的专业素养。开发人员喜欢享受乐趣，但当我们的行为与业务脱节时，不难理解为什么业务部门可能会认为我们没有能力思考他们所思考的事情。
• 有数据和轶事证据来支持你的主张。
• 已经确定了几个关键的优先技术债务项目。
• 制定灵活的计划来解决问题，可以根据业务需求进行修改。
• 了解解决问题需要多长时间。
• 有想法确保技术债务在未来不再成为问题。
• 随着技术债务的偿还，准备好提供进展状态报告。

当你与业务利益相关者讨论严重的技术债务问题时，你本质上就像一位医生，向病人发出健康并发症及其未来后果的警告。你需要实话实说，切勿危言耸听，并且需要提供补救措施并持续监控的方案。

我们稍后会详细讨论这些事情。

“技术债务不是开发人员的错吗？”

我有时会听到企业问这个问题。他们通常并非出于恶意，有时甚至会很不情愿地提出来。大多数企业人士不了解软件开发或软件项目的本质，因为他们没有为这些项目开发过代码。因此，完全有理由认为技术债务是开发人员的错。

不幸的是，这个假设的真相是，有时技术债务是我们的错。有时我们在做决定时没有对其后果发出警告，有时我们注意到它时已经太晚了，有时开发人员会偷懒、犯错，或者仍在不断提升他们所需的全部技能。

然而，我选择相信，大多数技术债务不是我们的错，或者发现得太晚而无法改变，否则会危及关键业务目标。

在与那些将技术债务归咎于开发的业务利益相关者打交道时，我喜欢用农业做类比。

在农业生产中，如果一季又一季地重复耕种同一块土地，就会系统性地消耗土壤养分，导致土地的肥力和产量下降。正因如此，农民们采取了诸如轮作（在非耕作季节让田地休耕或空置以补充养分）或不时用肥沃土壤的作物替代耗损土壤的作物等技术，以帮助田地恢复养分。

这个比喻清楚地表明，虽然开发人员一个接一个地致力于满足企业的需求，但由于缺乏时间除草，让土壤重新恢复活力，最终导致作物产量下降。最终，你遇到的不是糟糕的农民（开发人员），而是以牺牲长期生存能力为代价，追求最初几季产量的耕作策略和计划。

商业视角

有时牺牲代码库的长期健康实际上是可以接受的。

有时，你迫切需要完成一个项目才能维持业务。有时，你计划彻底重写一个应用程序，或者在多次迭代后将其淘汰，并采用其他替代方案。在这种情况下，短期生产力应该是首要考虑因素。

其他时候，业务人员根本就不明白。他们总是关注利益相关者的需求、销售目标、成交量、风险合同、支持事件、bug 数量以及其他具体易懂的事情，所以当他们听到技术债务时，很容易认为这只是“我不太喜欢的代码”，而不是“一个巨大的质量风险，等待着向用户释放大量缺陷”。

这就是为什么他们需要我们将我们的日常生活翻译成他们能够理解的内容。

这意味着我们必须关注指标。利用来自问题跟踪系统、时间跟踪系统、源代码控制、代码分析工具、测试覆盖率结果、CI/CD 流水线、性能监控工具和其他来源的数据，你可以整理出一些有趣的数据，例如：

• 按应用领域划分的缺陷
• 完成单个功能所需的时间（特别是随着时间的推移，这表明生产力有所损失）
• 开发与支持活动所花的时间
• 随着时间的推移，单元测试覆盖的代码百分比
• 源文件的“代码异味”
• 随着时间的推移，“代码异味”
• 导致错误的传入请求的百分比

要有创造力。适合您代码的具体指标将取决于您的组织和您当前的技术债务情况。如果您需要一些分析问题和提出表达方法的想法，请查看我关于软件质量的 7 个基本工具的文章。

软件质量的 7 个基本工具

Matt Eland 为 Pluralsight 撰稿 ・ 2019 年 9 月 1 日

#代码质量 #管理 #测试

代码分析

我绝对会依赖代码分析工具。这些工具可以是编译器或 Linter 警告，也可以是专门用于分析代码库并生成建议的工具。具体使用的工具会因你使用的编程语言而异，但我将分享一些对我而言有效的工具。

我使用SonarQube / SonarCloud扫描多种不同语言的各种代码。

这也可以帮助我以非常直观的方式确定最需要关注的文件的优先级，适合与业务利益相关者进行沟通：

虽然 SonarQube / SonarCloud 适用于开箱即用的简单跟踪，但可能需要更深入和可定制的分析，并且应该来自适合您的编程语言的特定工具。

我使用NDepend来分析 .NET 程序集，并获得有关这些项目的所有错误的详细指标和可视化效果，以便随着时间的推移确定优先级并跟踪代码异味。

特别是 NDepend，它可以根据大小和复杂性、代码覆盖率等来精确定位方法，并生成一些非常有用的图形和图表，用于确定优先级，甚至可能传达技术债务。

免责声明：虽然我之前已经为 NDepend 付费，但我目前的副本是由开发者提供的

与业务利益相关者沟通的技巧

因此，既然您已经掌握了确定优先级和传达技术债务所需的指标和数据，那么让我们来讨论一下吧。

首先，你需要确定这件事有多重要。这可以是30秒的电梯游说，比如“如果我们能修复X问题，我们的效率真的会更高。我可以给你发一封简短的电子邮件，详细说明一下，并把它纳入到未来的冲刺中吗？”，也可以是“我一直在关注我们的代码质量，我有一些顾虑想和你分享。我想在本周晚些时候安排一次会议，讨论这些问题，并探讨一些可能的解决方案。你哪天比较方便？”

其次，你需要组织适当级别的沟通。通常，沟通内容可以是一段长的电子邮件，也可以是一两页的报告，或者一份包含5-10页幻灯片的演示文稿。你的目标是以简洁的方式向他们传达问题，使他们能够理解，并公平地参与讨论，以确定问题的优先级并制定解决方案。

第三，你需要考虑他们的沟通风格。有些人讨厌电子邮件或电话。有些人讨厌正式会议。风格也很重要——有些人喜欢简洁自信的陈述，无需任何铺垫；而有些人则希望在谈正事之前与你进行深入交流，轻松愉快地闲聊。有些人受确凿事实的驱动，而有些人则受个人受影响故事的影响。了解你的受众。如有疑问，请尝试多种方法，或者准备好一些轶事，以便在你的数据不准确时分享。

我强烈建议你的演示内容应尽量简洁，以便充分传达问题。开会前做好功课，但不要让他们感到无聊。如果高管想要了解详细信息，他们会主动询问的。你并非想让自己显得聪明或赢得对方的青睐，而是想让合作伙伴了解一个并非他们强项的解决问题的世界。

作为演示的一部分，向他们介绍你提出的补救计划。他们可能会问你一些问题，例如需要多少资源、需要多长时间、有哪些风险，以及由于资源损失，企业短期内无法开展哪些工作。

我要提醒大家不要参加这些会议的另一件事——无论公平与否——是，许多高管都关注人们的上下班时间，如果你告诉他们，你需要能够花时间解决技术债务，而开发团队每天在下班时间立即离开，迟到，或者吃很长时间的午餐，高管们可能很难集中精力听你说话——无论对错，这往往是这个级别的许多人的想法。

结束语

现在我们知道了如何向业务利益相关者传达技术债务，并希望获得认同，让我们来看看偿还技术债务的一些策略。

偿还技术债务的策略

Matt Eland ・ 19年10月3日

#代码质量 #管理 #架构

在与业务利益相关者沟通时，哪些方法对你有效？除了我上面分享的，你还遇到了哪些障碍？

照片由 Sabine Peters 在 Unsplash 上拍摄