我如何说服管理层处理技术债务？

与开发人员一起工作时，我经常会问自己一个问题。到目前为止，我已经在四家公司工作，并且我意识到缺乏对保持代码干净和处理技术债务的关注，这些债务阻碍了软件应用程序的未来发展。例如，我工作的第一家公司是从头开始编写数据库，而不是使用MySQL之类的东西，并且在重构或扩展应用程序时给团队造成了麻烦。当经理讨论预测时，我一直试图与我的经理保持诚实和坦率，但是管理层似乎对修复已经存在的问题不感兴趣，并且看到它对团队士气的影响令人震惊。

您对解决此问题的最佳方法有何看法？我所看到的是人们收拾行装离开。然后，公司成为旋转门，开发人员进出，使代码变得更糟。您如何与管理层沟通，以使他们有兴趣解决技术债务？

当我与老板会面讨论此事时，他说我应该在所有估计中都包括重构。他说这不是他想考虑的问题。相反，我应该处理它。

通常，这不是管理层要考虑的问题。他们不是工程师，而是。只需将其作为所有估计的不言而喻的部分，您就会发现技术债务减少了。

它永远不会是完美的。技术债务（如信用卡债务）是一项投资，目的是使客户更快地获得收入，并更快地在竞争对手中获得市场份额。像信用一样，如果管理得当，它可以使您相当成功。

就像甘地在被问及他的策略是否适用于希特勒这样的人时所说的那样。他说：“这将很困难。” 但是我认为有一个公平的论点，答案确实是“不”。可悲的是，我认为您无法做到。这并不是说我要悲观，而是要说实话。

我的问题不是管理者需要说服力。更好的人已经知道，如果不加以控制，债务可以成为杀手。但是，不管他们是否理解，无论他们是好经理还是坏经理，他们都面临着交付的压力，而交付是由老板根据日期来判断的。质量只有在非常糟糕的情况下才重要，在这种情况下是开发人员的错，或者在这种情况下质量是非常好的，在这种情况下，才华横溢的是管理才能。质量只需要“足够好”即可。

我认为我喜欢Renesis在他的回答中所说的话，因为它是少数几个理解管理层与工程学思维截然不同的人之一。而且我认为我们所有人都已经看到公司的发展成为日期驱动型和项目管理型的，而不是以客户和质量为中心。我的意思是说典型的公司，而不是真正勇敢地说“完成后会完成”的坚定公司（例如Apple Computer或id Software-是的，我知道有时候人们没有自由）采取这种方法）。

但这就是问题：采用质量第一方法的公司...您对它们有什么看法？没错，他们是由工程师而不是销售员，营销人员，项目经理或会计师管理的。想想HP，Apple，ID，Google，Microsoft和IBM。所有这些都是由工程师而不是推销员开始并取得成功的，尽管推销员当然起了一定的作用，但我敢肯定，许多人会争论微软是否将其与质量相关联：)。其中，那些走下坡路的人摆脱了工程驱动的领导。但是，在该声明中有很多争论，因为有很多技术公司由于无法适应时代的变化和管理自己的增长而最终失败了。我不认为基于工程的领导能力是导致这些失败的原因，对我来说，一个与开发人员或会计师无关的技能和业务敏锐度问题。但是，我认为一般来说，工程学致力于严格的问责制和纪律性，从而使那些以工程学为核心的公司受益。

认真地环顾四周。严重缺乏IT领导能力。只要足够好，重点始终放在成本和时间上，而很少关注质量。IT领导者很少再向CEO汇报工作，现在一直是CFO。IT部门一直坚持提供生产支持，越来越多地垂青于那些专注于较小，更易消化和可测量的块的项目经理，而不是革命性价值的重大变化（这不一定是错误的；分而治之是一件好事，但愿景需要在那里查看大图）。

抱歉，在本文上花了这么长时间，但最后，我认为您的问题，即如何让管理层关注技术债务，通常可以通过找到合适的领导者而不是更换现有的领导者来更好地解决。正如瑞尼斯（Renesis）所说，向标准思想家解释技术债务意味着将重点转移到金钱和成本上，我认为这在翻译中会损失很多。即使您成功做到了，也只有公司的最高领导人购买了它才有意义。说服您的中层经理做正确的事可能只会让他被解雇。

首先要做的是更改措辞。称其为“技术债务”使管理层有了一个想法，即允许它是某种投资，而实际上它更像是一种病毒。（我就像技术债务的戴夫·拉姆齐。）

使其无偿付款会带来巨大的成本，无法看到或难以量化。

列出诸如以下问题以供管理：

• 新功能估计远高于其所需的数量。或者，完全不可能。
• 错误代码会产生更多错误代码
• 即使开发人员一直在修正错误列表，错误列表也会增加
• 团队成员要离开（这本身可以表明存在问题，如出色的回答中所述）

我的管理层实际上已经开始认真地解决技术债务问题，这是我喜欢在那里工作的原因之一，但这是一项长期的工作，并且毫不费力地提醒他们为什么这样做值得。

我不断施加压力的一种方法是，每当要求我进行估算时，如果我不必处理特定的技术债务问题，则可以节省时间，我将其包括在估算中。例如，“ 该错误将需要我2-3天来进行跟踪，但是如果我们已经解决了这两个永远都在队列中的其他“低优先级”错误，则可能只需不到一个。 ”通常，响应将是继续并在其他情况下修复其他问题。

我也同意其他一些答案，即只考虑工作中的改进部分，如果不太破坏性，则可以随时进行改进。我当前的任务是添加一些设计不佳的代码。我没有花时间编写新的代码来匹配它们，而是加了点麻烦，而不是通过编写新的代码来使事情变得一团糟，因此发送数据包成为单行功能调用，而不是不断重复重复15行经过稍微修改的“复制和粘贴样板。

我知道一个事实，它将在将来进一步节省一些维护人员的理智。我知道，因为我是今天的维护者。但是，我也相信它将加快我自己当前的任务，以立即获取并调试此功能。

我过去使用过的另一种技术，应该再做一次，就是在您编译，等待长时间的测试或只需要改变速度的时候，在单独的工作树中保留一个重构的DVCS分支，以减少停机时间。当您精疲力尽于错误时，有点。只要您偶尔从上游合并，以免差异太大，您就可以花很少的时间就可以重构变更。随着时间的流逝，每天在这里和那里花费15分钟确实可以加起来。

您可以尝试使用信用卡进行类比。问他们“您是否愿意长时间不支付信用卡账单？”

经理了解成本和收益，但（通常）不了解我们开发人员使用的技术术语。已经发明了“技术债务”一词来帮助克服这种沟通障碍，但是您可能需要更清楚地表达它。大多数经理都非常了解（通常是根据自己的经验），逾期信用卡付款的利率会非常高，因此让他们无偿还很痛苦。这可以帮助他们弄清有关软件熵的问题的严重性。

但是，如果这不能使他们信服，请尝试收集事实证据并进行一些计算。例如，要更换离职员工，公司需要付出多少现金（包括现金和浪费的时间）？

没有人会为用其他（也有运气）也可行的东西代替可行的东西而付出金钱。

您所能做的就是建议用功能更强大的产品替代它，即将技术债务的服务捆绑到升级中，从而带来即刻而切实的业务收益。

当然，您应该对此保持开放态度，我们这里并不是在谈论“将其潜入”一个新项目。

我发现另一方面，开发人员更难处理。基本上可以归结为这一点：对于某些开发人员而言，确保您的代码是您能想到的最好的代码是专业上的骄傲。对于其他人，这只是另一项工作，目的是快速完成工作并回家。

令人信服的情况不会改变这种情况，如果您引入强制性代码质量标准，则您的9到5个开发人员将找到一种工作系统的方法，而您的敬业开发人员将不可避免地对整个过程感到恼火（并不是针对他们的，但是您不能说开发者X必须遵守规则，而Y可以做任何他想做的事情。

可行的方法，但仍然很令人沮丧的是，让您更敬业和知识渊博的开发人员来监督代码库，这可能是在继续进行工作并整理那里的传统之间的一个很好的折衷方案。

事实是，在许多公司中，特别是考虑到当前的经济形势，必须每小时向某人收费。

否则他们很快就倒下。

除非现有客户愿意为重构支付费用，否则除非具有显着升级的性能或功能，否则这几乎是不可能的。这样就不会在较旧的代码库上发生。如果客户有很多钱，您也许可以将其潜入新项目的预算中，但是除非您不需要在重构中更改API，否则它将对较旧的项目毫无用处，并且可能会引入公司正在支持两个代码库的情况，这会导致进一步的麻烦和成本。

作为工程师，我希望能够重构旧的代码，而每当某些东西变得过时或过时，旧的代码就不再真正适用。但是正如我曾经工作过的所有公司的总经理向我说：“谁来付款？”

我一直在尝试清理。在代码干净之前，我还没有完成。技术债务的问题在于大多数人不了解它。解决它的最好方法是不积累任何东西。如果您的经理信任您的开发人员来决定如何解决问题，则可以使代码卫生成为每个编程任务的一部分。如果您从不签入错误代码，则不会累积债务。如果您还遵循《童子军规则》（始终保持代码比发现的要干净），则现有债务将慢慢消失。

我认为重构与实现功能无关。它是其中不可或缺的一部分。

如果您与非技术经理打交道，则可以将讨论内容转化为他们理解的术语，这将对您有所帮助。如果您可以为在偿还技术债务上花费的工作建立一个现实的投资回报率的现实案例，那么您可能会有所建树。该练习将取决于您的情况，但是一个示例可能是这样的：

分析开发人员被迫花费多少时间帮助生产支持部门解决生产问题，然后得出结论：修正繁琐的旧代码将使A.减少支持问题的数量； B。使支持部门更容易地解决问题而不升级到开发部门；以及C.减少开发在出现问题时花费在生产上的时间。用不用让开发人员捆绑进行支持工作而节省的资金来表示。还要指出，开发人员花在支持上的每一小时都是“双重打击”，因为您不仅要向开发人员付费以提供支持，而且还要消耗开发人员可能做的机会成本（添加新功能等）。 ）

是的，其中一些数字将是伏都教/烟雾和镜子……没关系，管理层的肮脏秘诀是，他们知道，他们随身携带的大多数数字都是总学士学位，只要您给他们一些东西即可看起来很具体，可以与他们合作，让他们有机会战斗。

在解释了技术债务之后，应该说服您的管理层还清债务：

想象一下，您有一个非常肮脏的厨房，里面满是垃圾。在准备餐点之前，您必须先花费一个小时的清洁时间。就像每次您想吃的东西一样。另外，在准备餐点时，您必须格外小心，以确保餐点不会掉落。

厨房是您的准则，进餐是您的产品，进餐是您的产品。

如果他们能够忍受更长的等待时间来实施更改，而又没有单元测试的安全网，那么您的公司就有问题了。

就原始产品和业务案例而言，这必须是一个非常令人信服的论据，即我现在无法用这笔钱做对我来说更重要的事情。不管您是否喜欢，您的管理层或您的客户都为此付出了代价，您需要能够出售以说服他们。

让我们重新表述一下，以将自己定位为客户。好老角色扮演。

假设您正在购买冰箱。您可以从Acme Corp.以1000美元的价格购买可以正常工作的冰箱，或者从Acme Deluxe Fridges以2000美元的价格购买冰箱，该冰箱在外观上相同且具有相同的技术规格，但由于内部结构更清洁而降低了维护成本。

作为客户，您自己会买哪个？

Acme Deluxe的工程师认为更好的答案是什么？

向管理人员提出“ 技术债务 ”可能是一个棘手的问题，因为他们可能没有必要。问题可以这样形容为：公司中是否有拥护者说：“看，我们在这方面花了X％的时间来处理技术债务。请给我们3个月的时间来证明您的工作效果很好”或类似的内容类似。那里声称拥有自治权，但也有时间表，因为否则管理层可能会想知道他们要等多久才能看到一些相当危险的结果。

但是，第一点是他们是否认为这是一个问题。如果视力不好的人对眼镜一无所知，他们不知道可以提供什么种类的眼镜，那么他们如何理解为什么进行眼科检查很有价值？这里的主题是技术性的，不幸的是不容易量化。

您应该停止抱怨它。

原因如下：

1. 他们从未打算使用软件超过一年
2. 如果他们的计划是事后丢弃它，那只是浪费时间进行调整
3. 有一些实际问题需要立即解决
4. 程序员只需要学习处理维护问题，即使这并不总是很有趣
5. 抱怨您更了解需要做什么是自大的-别人做出了决定，您应该对此感到高兴
6. 他们仍然相信您会编写出色的代码

因此，最好的前进方式是：

1. 当他们给您新任务时，请尝试在给定的时间内尽可能地实施
2. 第一次完美书写。如果您需要在事后进行更改，那么您是第一次犯错，而任何更改都总是朝着错误的方向发展-当程序员犯错时，这是程序员的学习机会。
3. 不要要求额外的时间，您不会得到它，因为您知道有最后期限。

我认为您从未参与过重写/替换甚至升级现有系统的项目。

这些是一些最难成功完成的项目。您将遇到的一些问题是：

1. 业务规则会及时丢失。
2. 文档和实施完全不同步。
3. 您将错误视为用户将功能视为错误。
4. 相反，许多“特征”将被用户视为缺陷。
5. 您不会获得用户的支持-他们会将您的“事实调查结果”视为“书呆子询问愚蠢的问题”，他们会将测试工作视为浪费时间，他们将坚持添加新功能，从而延长了项目的时间已经落后于时间表。
6. 可能是源代码与正在运行的可执行文件不匹配100％。
7. 当您的部门忙于重构开发时，业务真正想要的工作还没有完成。
8. 您的重构可能会涉及“更清洁的界面改进”，从而将其他项目拖入延迟交付和失败测试的泥潭。
9. 项目结束后（超过50％的努力完全失败了），您将失去所有的信誉-您将需要搬到另一座镇的另一家公司来寻找也愿意倾听您的人。
10. 如果项目“成功”，那么每个人都会记得那是一场噩梦，您将.......

我敦促您避免诸如瘟疫之类的任何重写/重构项目，它们可能是任何职业生涯中最令人沮丧的经历。

“如果还没有破裂，那就不要修复”这句话有很多道理。

在我的一生中，我无法理解为什么有些人如此盲目地害怕改变-有点对自己的能力缺乏信心。

昨晚我在优胜美地国家公园观看了一场表演，并指出从1940年到1990年代末，没有一棵新的红杉树发芽。人们发现，其原因是有严格的政策禁止森林大火燃烧，而红杉松果需要燃烧产生的热量来打开和释放种子。

你看，每十年左右生火是健康的。它清除了所有累积的枯木和荆棘，以使现有树木（过程）保持健康，并为新树木（功能）腾出空间。

我现在在一个有明显重建案例的项目中：旧版软件完全使用.NET Webforms编写。随着业务的增长，几乎所有业务逻辑都与HTML /服务器标签视图逻辑混合在一起，并且不能扩展到其他应用程序中。

管理是任务的背后，因为他们对开发人员有适当的信任，我知道这是一种难得的奢侈。

是的，问问自己是否确实需要重建。尽最大努力重用现有代码，并在可行的地方使用。如有必要，将该代码集成到重建中。只是不要让任何人说服您，害怕进行大胆的更改是作为软件开发人员存在的唯一途径。

祝好运！

您需要给您的管理层一个财务上的理由来处理技术债务，以及一个管理框架来减少技术债务。

维护技术路线图就是这样一种框架。从路线图开始可以帮助您避免积聚技术债务，还可以帮助您减少现有债务。

许多成功的长期项目都有相关的指导委员会和指导发展的路线图。当涉及多个开发团队和涉众时，这些功能特别有用。

我的建议是与您的经理（如果可能的话，决定花钱的人）讨论这个策略。

创建和管理路线图的一般方法很简单，但是确实需要管理团队的支持。首先，定义一个目标。定义技术债务的要素，并开发目标系统架构以减少技术债务的要素。请记住，它不一定是完美的，只是可行且比您目前的状态更好。考虑软件，开发工具，硬件平台，可能添加到系统中的主要新功能。进行成本分析。如果您具有所需的体系结构，那么执行重构的实际好处是什么？（好处包括减少测试时间，更可靠的软件产品，更可预测的开发周期等。）如果您可以显示出执行重构所需的足够好处，则可以获得管理支持。

获得路线图和管理支持后，请制定一系列步骤（也称为计划），以达到所需的状态。最好成立一个指导委员会来维护路线图，对路线图上的开发团队进行培训和教育，并定期审查体系结构完整性的更改，这可能是一个好主意。

路线图确实有用，也许在Joel测试中的第13个问题应该是“您有路线图吗？”

这是最近的Red Hat Linux路线图会议的第一个小时的视频。

我已经参与了重大的重写（而不只是重构），所以我可以同意，让财务人员同意该项目是主要的障碍之一。克服这一障碍需要我撰写，介绍和捍卫一份报告，该报告指出了许多问题，这些问题意味着公司业务在中短期内将陷入困境。

达成协议的关键因素：

• 现有代码位于一个不再受支持的工具链（MicroPower Pascal）中，该工具链仅在几乎不受支持的开发平台（PDP11-23）上运行。
• 寻找可以从事工具和目标工作的开发人员几乎变得不可能。
• 如果需要备件，目标硬件将不再可用，并且制造商越来越不愿提供维修服务。
• 规范中的问题导致易于识别的客户不满和直接服务成本。
• 由于目标硬件的限制，添加新功能甚至修复错误几乎变得不可能了，这导致需要重构其他区域，以便在解决问题时提供空间。
• 由于需要8个小时的构建时间，因此开发和测试任何更改的成本很高。

该报告详细介绍了这些问题，并估算了持续成本，并提供了3种选择：

1. 在不久的将来冻结甚至可能没有错误修复的位置。
2. 仅针对空间优化代码，而不考虑可维护性，并指出，任何尝试维护优化代码的人都必须比进行优化的人更聪明。
3. 在新的，低成本的COTS硬件（PC-104）上以业界标准，广泛教授的语言（ANSI C），以可测试性和可维护性为重的因素进行重新实现，内部有多个供应商设计的接口卡，使其可以与其余现有硬件一起使用。作为开发的一部分，添加了一组有限的新功能，例如非易失性存储，看门狗计时器，以在故障情况下提供自动重启，某些设备每天崩溃多次，并需要40英镑的服务电话进行重置，在此过程中进行更好的诊断。

获得第三个选择权后，我3个月的合同变成了3年的艰苦工作，既开发新的软件和硬件，又取得了很好的成果。

对于极端技术债务较少的情况，我倾向于采用所谓的游击队重构：

特定模块有问题时：

1. 编写一组测试，以证明该问题也可能在不重构的情况下失败
2. 重构作为开发的一部分，指出测试仍然失败。