“技术债务终将反噬我们”：如何让非技术利益相关者真正关心技术债务问题

由 Mux 赞助的 DEV 全球展示挑战赛：展示你的项目！

我们需要重构这段代码。

茫然的眼神。

“建筑风格越来越杂乱了。”

更多茫然的眼神。（甚至还有一丝“别烦我，我们还有功能要发布”的意味。）

“如果我们现在不解决这个技术债务，以后会拖慢我们的速度。”

他礼貌地点了点头，然后问道：“我们能先发布这个功能吗？”

我已经数不清跟人讨论过这个问题多少次了。多年来，我一直把责任归咎于产品经理。

他们根本不明白。他们只关心功能。他们无视地基，却要求我们再盖一层。

后来我意识到：问题不在于他们，而在于我的沟通。

翻译差距

我当时是这么说的：“我们需要重构这段代码，因为架构越来越混乱，技术债务也在不断累积。”

他们听到的是：“我宁愿花两周时间把东西做得更漂亮，也不愿去做客户要求的事情。”

我们当时说的根本不是同一种语言。我谈的是代码质量，他们谈的是客户价值、收入和产品路线图承诺。

我们俩都没错，只是彼此之间没有沟通。

一切改变的那一刻

我当时正在开会，试图解释为什么我们需要暂停功能开发来解决技术债务问题。

产品经理眼神迷离。我能看出她正在心里盘算着如何礼貌地结束这场谈话。

于是我停下话说到一半，尝试用另一种方式表达。

“想象一下，你刚刚切掉了半根手指。你可以好好清洗并包扎，也可以置之不理。如果你一直对切掉一半的手指置之不理，会发生什么呢？”

她看着我，好像我疯了一样。但后来她明白了。

“他们会被感染。”

“没错。最终，你甚至连那只手都用不了了。这就是技术债务对我们代码库的影响。”

突然间，我们不再讨论代码架构，而是讨论化脓的伤口、扩散的感染和丧失功能的双手。

她把技术债务可视化了。而可视化能产生紧迫感。

为什么技术术语会失效

• 当我们说“重构”时，非技术利益相关者会听到“可选的润色”。
• 当我们说“技术债务”时，他们听到的却是“开发人员想要完美的代码”。
• 当我们说“架构”时，他们听到的是“不影响用户的抽象问题”。

我们彼此之间使用这些术语并没有错。但是，对于那些以已发布功能、产生的收入和客户满意度评分来衡量成功的利益相关者来说，我们需要一套不同的词汇。

并非因为他们智力较低，而是因为他们追求的是不同的结果。

产品经理并非出于恶意而忽视技术债务。

他们关注的重点是：

• 向客户交付承诺的功能
• 实现营收目标
• 保持领先于竞争对手
• 让利益相关者满意

“我们需要重构”与这些目标都不符。所以我们需要向他们展示重构是如何实现这些目标的。

搭建桥梁

这种改变不是为了降低难度，而是为了找到共同的语言。

以下是我觉得有效的比喻：

创可贴治感染伤口

任何权宜之计都像是用创可贴掩盖没有彻底清理的伤口。任何捷径都像是粉饰墙面裂缝，而不是从根本上解决问题。

乍一看还不错：墙面看起来像是刷过漆的，切口也被遮盖住了。

但创可贴会脱落，油漆会剥落，而底下的情况比一开始更糟。

原因在于：人人都明白，忽视感染只会让情况恶化。没人会质疑“这会被感染”这句话。

地基开裂：
你可以在开裂的地基上继续盖楼，一开始或许还能撑住。但每盖一层楼都会增加压力，裂缝会不断扩大。总有一天，整个房子会坍塌——而这恰恰是你最需要它的时候。

它的作用原理：它将技术决策与风险管理联系起来，这是每个企业领导者都会考虑的问题。

用他们的语言

比喻固然有用，但你知道真正有效的方法是什么吗？那就是将后果转化为商业语言。

而不是：“这段代码很难维护。”

尝试这样说：“由于结构的原因，该领域的每个新功能都需要花费三倍的时间才能完成。这意味着每个迭代周期我们都要额外花费 20 个小时来开发新功能。”

而不是说：“我们这里有技术债务。”

可以这样说：“这让我们每个季度损失15000美元的开发人员时间。如果我们现在投入两周时间，以后每个季度就能节省这笔钱。”

而不是：“建筑风格杂乱无章。”

尝试说：“我们这个模块的错误率比其他地方高 4 倍。”

每周都有客户反馈问题。我们可以解决这些问题，但这需要从根本上解决系统架构问题。

时间浪费，金钱损失，漏洞增多，速度下降。

这些都是利益相关者能够理解的指标，它们能够营造紧迫感。

真正有效的对话

这是我目前使用的框架：

1. 认可他们的优先事项：“我知道我们需要在本季度末之前发布 X 功能。这很重要。”

不要一开始就采取对立态度，要从合作开始。

1. 将技术债务与他们的目标联系起来：“问题是，我们需要构建功能 X 的区域非常不稳定。我们每周都会发现那里有 bug，而且每次更改所需的时间都是正常情况的两倍。”

要指出技术问题如何影响他们的目标，而不是你的目标。

1. 量化成本：“目前，我们每个迭代周期都要花费大约 10 个小时来解决该模块中的问题。这相当于半个开发人员的时间。”

让不可见的事物变得可见。给它们赋予数字。

1. 提出投资方案和投资回报率：“如果我们花一周时间清理这个问题，就能将时间缩短一半。此外，功能 X 的构建速度会更快，稳定性也会更高。”

把它看作是一项有明确回报的投资，而不是一项成本。

1. 给他们选择：“我们可以现在解决这个问题，之后进展更快；或者继续绕道而行，接受这个领域的每个功能都需要更长时间才能实现。考虑到我们的优先级，哪种方式更合理？”

赋予他们充分的信息，让他们能够做出决定。

🛠️ 如何应用此方法

在下次讨论技术债务之前：

• 明确业务影响。时间、金钱或风险方面的成本是什么？如果你无法清楚地阐述这一点，说明你还没有准备好进行讨论。
• 选择合适的比喻。什么比喻最能引起这个人的共鸣？金融类人士关注债务和利息，产品类人士关注速度和风险。
• 尽可能量化一切。工时、成本、缺陷数量、速度变化。数字能营造紧迫感。
• 做好投资回报率分析。投资额是多少？回报是多少？多久才能收回成本？

对话过程中：

• 首先要考虑他们的目标，而不是你的。“我知道发布 X 功能至关重要……”
• 将技术问题与业务联系起来。阐明技术问题如何阻碍业务目标的实现。
• 提供多种选择，而不是下最后通牒。“我们可以现在解决这个问题，之后加快进度，或者继续绕道而行。考虑到我们的优先事项，哪种方式更合理？”
• 要坦诚面对权衡取舍。每个选择都有代价，要正视这些代价。

获得买入权之后：

• 说到做到。如果你说需要一周时间，那就花一周时间。信任是通过言行一致的积累起来的。
• 衡量成效。速度提高了吗？bug减少了吗？分享这些成功经验。
• 加强联系。“还记得我们清理 X 模块的时候吗？正因为如此，我们才能如此迅速地发布 Y 功能。”

更深层次的技能

我希望有人早点告诉我：跨学科沟通是一项核心工程技能。

这不是软技能，也不是锦上添花，而是一项核心技能。

我认识的最优秀的工程师不仅技术精湛，他们还能将技术问题转化为商业价值、设计理念或用户体验。

他们明白：

• 后端工程师需要与前端沟通，了解 API 契约和数据流。
• 前端工程师需要与设计师沟通，了解交互模式和限制条件。
• 每个人都需要从客户价值和业务成果的角度来谈论产品。

跨学科融合并非意味着牺牲你的专业知识，而是要让你的专业知识对那些追求不同结果的人有用。

🤔 需要思考的问题

你上一次试图解释技术问题却遭到对方茫然注视是什么时候？你当时使用的是什么语言？

哪些比喻能引起您特定利益相关者的共鸣？

你是在量化技术决策对业务的影响，还是仅仅希望人们信任你？

您多久会从利益相关者的目标出发来展开关于技术债务的讨论，而不是从工程方面的考虑出发？

底线

技术债务终将给我们带来麻烦。但仅仅告诉利益相关者这一点并不能让他们意识到问题的紧迫性。

创可贴可以缓解感染的伤口。信用卡利息会累积。地基开裂也会造成损害。

任何权宜之计都只是用创可贴掩盖我们没有彻底清理的伤口。

任何捷径都如同粉饰墙上的裂缝，而不是从根本上解决问题。

起初看起来还不错。但创可贴会脱落，油漆会剥落，而底下的情况比一开始更糟糕。

你的工作不仅仅是找出技术债务，还要让非技术人员像你一样重视它。

而这一切都始于学习他们的语言。

照片由charlesdeluvio拍摄，来自Unsplash