「技术债」遗留的技术债务问题怎么解决？

如果你曾在一家高速增长的软件工程公司待过，你可能会听过类似这样的一段对话，是关于技术债务的：
张三：“如果我们只做 X 的话，那么我们可以更快地交付……”李四：“说得挺有道理的嘛，那你为什么还不去做呢？”张三：“哎！我们要做这么多功能，哪有时间啊，根本做不过来。 ”
或者是类似这样的评论：
“我们真的需要这么做。我们应该停止所有的功能开发工作，直到解决这个问题为止。 ”
对于这种情况，我一直持观望态度。当我站在李四的立场来看，解决问题几乎总是合乎逻辑的，但并不总是能得到所需的支持！那么，问题究竟在哪儿呢？为什么偿还技术债务明明是一个很明显且合理的举措，但是却很难说服大家来做呢？
我们对技术债务的定义正确吗？
“技术债务” （Technical Debt 或 Tech Debt），这一古老的流行语通常被当成一个包罗万象的术语，用来描述我们希望我们所构建或正在开发软件更好的东西。由于在开发早期阶段所做的一些捷径或权衡，软件通常并不会达到预期的状态。
凡是被贴上技术债务标签的东西，几乎都是软件的非功能性更改。比如，重构代码来消除全局代码，从而支持依赖项输入、修复（或添加）测试、改进文档、甚至让测试套件在 CI 中运行，或者最终实现部署的自动化之类的事情。
因为这些东西都不是功能性的改变，也不会改变软件的行为，所以对客户来说，这些改进他们很可能看不到。因此，如果客户并不会看到你在这个技术债务上所耗费的时间以及软件的任何变化，那你提交的价值又在哪儿呢？又为什么要在技术债务上投入时间呢？
如何向别人阐述解决技术债务的价值
向客户阐述解决技术债务的商业价值，是获得解决债务所需时间的关键。通常来说，人都会抱有一种固定思维模式（ “我们也想解决这个问题啊，但我们没有得到允许去解决这个问题呀” ）。记住，在任何组织中，人们都会作出决策，决策是关于权衡的，是可以受到影响、被推翻或改变。更重要的是，组织也在不断变化，昨天做出的决策方式，到明天可能就行不通了！
如果说沟通价值是关键，那么技术债务的偿还价值应该如何沟通呢？对于这一问题，没有一个放之四海而皆准的答案：但我写下本文的初衷是勾勒出这么一个框架，帮助产品团队或工程团队对问题进行分类、时间分配，并明确为什么每段时间都应根据它将提供的价值进行适当的调整。
我希望本文勾勒出的框架能够帮助你与利益相关者保持一致，让你能够更有效地沟通价值，并让你最终解决你一直想解决的技术债务问题。
解决技术债务的最简单方法
“解决问题的最简单方法就是否认它的存在。 ”——Isaac Asimov当我们遇到技术债务问题时，要先问问自己：这里真的有问题吗？很可能不值得付出，除非：