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

#1 楼

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

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

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

#2 楼

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

对我来说，问题不在于管理者是否需要说服力。更好的人已经意识到，如果不加以控制，债务可以成为杀手。但是，无论他们是否理解，无论他们是好经理还是坏经理，他们都面临着交付的压力，而交付是由老板根据日期来判断的。质量只有在非常糟糕的情况下才重要，在这种情况下，是开发人员的错，或者是在非常好的情况下，才是实现管理的才华。质量只需要“足够好”。而且我认为我们所有人都已经看到公司的发展成为日期驱动型和项目管理型的，而不是以客户和质量为中心。我的意思是说典型的公司，而不是真正勇敢地说“完成后就会完成”的坚定公司（例如Apple Computer或id Software-是的，我知道有时候人们没有自由采用这种方法）。

但这就是问题：采用质量第一方法的公司...您对它们有什么看法？没错，它们是由工程师而不是销售员，营销人员，项目经理或会计师管理的。想想HP，Apple，ID，Google，Microsoft和IBM。所有这些都是由工程师而非推销员开始并取得成功的，尽管推销员当然参与其中，但我敢肯定，许多人会争论将Microsoft与质量相关联:)。其中，那些走下坡路的人摆脱了工程驱动的领导。但是，由于有许多技术公司由于无法适应时代的变化和管理自己的增长而最终失败，因此该声明中存在很多争论。我不认为基于工程的领导能力是导致这些失败的原因，对我而言，这是技能和业务敏锐度的问题，而这些问题与开发人员或会计师无关。但是，我认为一般来说，工程学致力于严格的问责制和纪律性，从而使那些将工程学作为组成部分的公司受益。严重缺乏IT领导能力。只要足够好，重点始终放在成本和时间上，很少关注质量。 IT领导者很少再向CEO汇报工作了，现在一直是CFO。 IT部门一直坚持提供生产支持，越来越多地垂青于那些专注于较小，更易消化和可测量的块的项目经理，而不是革命性价值的重大变化（这不一定是错误的；分而治之是一件好事，但愿景需要在那里查看大图）。

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

#3 楼

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

不予偿还将带来巨大的成本，无法看到或难以量化。

清单诸如以下用于管理的问题：


新功能估计远高于其所需的估计。或者，完全不可能。
错误代码会产生更多错误代码
即使开发人员始终在修复错误列表，错误列表也会增加
团队成员正在离开（这本身可以表明存在问题，如这个极好的答案）

#4 楼

我的管理层实际上已经开始认真地解决技术债务问题，这是我喜欢在那里工作的原因之一，但这是一项长期的工作，并且毫不费力地提醒他们为什么这样做值得。 br />我要施加压力的一种方法是，每当要求我进行估算时，如果我不必处理特定的技术债务问题，则可以节省时间，我可以将其包括在估算中。例如，“此错误将使我花2-3天的时间来查找，但是如果我们已经解决了这两个永远都在队列中的其他“低优先级”错误，则花费的时间可能少于一个。通常，响应将是继续并在您使用时修复其他问题。它不是太破坏性。我当前的任务是添加一些设计不佳的代码。我没有花时间编写新的代码来匹配它们，而是加了点麻烦，而不是通过编写新的代码来使事情变得一团糟，因此发送数据包成为单行函数调用，而不是不断重复重复15行经过稍微修改的“复制和粘贴样板。

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

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

#5 楼

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

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

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

#6 楼

没有人会因为用其他也可以用的东西代替任何有用的东西而赚钱。债务升级带来了立竿见影的业务收益。

当然，您应该对此保持开放态度，我们不是在这里谈论“潜入”新项目。 br />我发现另一方面，开发人员更难处理。基本上可以归结为这一点：对于某些开发人员而言，确保您的代码是您能想到的最好的代码是专业上的骄傲。对于其他人，这只是另一项工作，目标是尽快完成并回家。

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

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

#7 楼

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

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

作为工程师，我想重构不再适合实际用途的旧代码，每当某些东西过时了或已弃用。但是正如我曾经工作过的所有公司的总经理对我说：“谁来付款？”

#8 楼

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

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

#9 楼

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

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

是的，有些数字将是伏都教/烟雾和镜子...没关系，管理的肮脏秘密是，他们知道他们随身携带的大部分数字总学士学位只要您给他们看似切实可行的东西，以便他们能想到，您就有了战斗的机会。

#10 楼

在对技术债务进行了这种解释之后，应该说服您的管理人员偿还债务：


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


厨房是您的习惯，餐是您的产品，吃东西是在推销您的产品。

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

#11 楼

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


假设您要买冰箱。您可以从Acme Corp.购买价格为$ 1000的冰箱，该冰箱可以正常工作；也可以从Acme Corp.购买价格为$ 2000的冰箱，
豪华冰箱的外观与外观相同，
但由于采用了更清洁的内部架构，维护成本却更低。


作为客户，您自己会买哪个？ Deluxe的工程师认为更好的答案吗？

#12 楼

向管理层提出“技术债务”可能是一个棘手的问题，因为他们可能没有必要。问题可以这样形容为：公司中是否有拥护者说：“看，我们在这方面花了X％的时间来处理技术债务。请给我们3个月的时间来证明您的工作效果很好”或其他内容类似。那里宣称拥有自治权，但也有时间表，因为否则管理层可能会想知道他们要等多久才能看到某些结果，而这是相当危险的领域。一个问题。如果视力不好的人对眼镜一无所知，可以提供什么样的更换，那么他们又该如何理解为什么进行眼科检查很有价值？同样的想法在这里是相当技术性的，不幸的是不容易量化。

#13 楼

您应该停止抱怨它。

这是为什么：


他们从来没有计划使用软件超过一年的时间
这只是浪费如果他们的计划是在以后将其转储，请进行调整更清楚地知道需要做什么是自大的-别人做出决定，你应该对此感到高兴
他们总会相信你编写好的代码。 br />

当他们给您新任务时，请尝试在给定的时间内尽可能地实现它。
第一次完美地编写它。如果您以后需要更改它，那么您是第一次犯错，而任何更改总是会朝错误的方向发展-这对于程序员犯错是一个学习的机会。你不会明白的，有截止日期。

#14 楼

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

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


业务规则会及时丢失。
文档和实现完全不同步。
您所看到的用户将其视为功能的错误。
相反，许多“功能”将被用户视为缺陷。
您不会获得用户的认可-他们会将您的“事实调查”视为“书呆子问愚蠢的问题”，他们会认为测试工作是浪费时间，他们会坚持添加新功能，因此延长项目的进度已经落后于进度。
可能源代码与100％不匹配使用正在运行的可执行文件。
您的部门正在混乱地进行重构开发时，业务实际上并没有完成。延迟交付和失败的测试的泥潭。
项目完成后（超过50％的努力失败而无法完成） tely），您将失去所有的信誉-您将需要搬到另一座镇的另一家公司来寻找也愿意听您讲话的人。您将.......

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

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

#15 楼

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

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

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

我的建议是与您的经理（如果可能的话，决定花钱的人）讨论这个策略。 />
创建和管理路线图的一般方法很简单，但确实需要管理团队的支持。首先，定义一个目标。定义技术债务的要素，并开发目标系统架构以减少技术债务的要素。请记住，它不一定是完美的，只是可行的并且比您目前的状态更好。考虑软件，开发工具，硬件平台，可能添加到系统中的主要新功能。进行成本分析。如果您具有所需的体系结构，那么执行重构的实际好处是什么？ （好处包括减少测试时间，更可靠的软件产品，更可预测的开发周期等）。如果您可以显示出执行重构所需的足够好处，则可以获得管理支持。
和管理支持，制定一系列步骤（也称为计划），以达到所需的状态。最好成立一个指导委员会，以维护路线图，对路线图上的开发团队进行培训和教育，并定期审查更改以确保体系结构的完整性。

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

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

#16 楼

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


现有代码已不在受支持的工具链（MicroPower Pascal）中，该工具链只能在几乎不受支持的开发平台（PDP11- 23）。
几乎不可能找到能够从事工具和目标工作的开发人员。
如果需要备件，目标硬件将不再可用，并且制造商越来越不愿提供维修服务服务。
代码中的问题导致易于识别的客户不满和直接服务成本。
由于目标硬件的局限性导致需要重构，因此几乎无法添加新功能甚至无法修复错误。其他区域，以便在广告时提供空间修整问题。
构建时间为8小时，开发和测试任何更改的成本都很高。

在不久的将来冻结我们可能无法修复的错误。
仅优化空间代码，而不考虑可维护性，指出有人试图维护优化的代码必须比进行优化的人更聪明。

在新的低成本COTS硬件（PC-104）上以业界标准，广泛教授的语言（ANSI C），以可测试性和可维护性为重的因素进行重新实现，内部有多个供应商设计的接口卡，使其可以与其余现有硬件一起使用。作为开发的一部分，添加了一组有限的新功能，例如非易失性存储，看门狗定时器，以在故障情况下提供自动重启，某些设备每天崩溃多次，并且需要40英镑的服务电话进行重置，

第三个选项取得了进展，我三个月的合同变成了三年的辛苦工作，包括开发新的软件和硬件，但都取得了很好的结果。

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

当特定模块存在问题时：


编写一组测试，以证明在不进行重构的情况下也可能失败的问题

重构是开发的一部分，指出测试仍在失败。

#17 楼

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

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

你看，一场大火每十年左右就很健康。它清除了所有累积的枯木和荆棘，以保持现有树木（过程）的健康，并为新树木（特征）腾出空间。重建：旧版软件完全使用.NET Webforms编写。随着业务的增长，几乎所有的业务逻辑都与HTML /服务器标签视图逻辑混合在一起，并且不能扩展到其他应用程序中。

管理是任务的背后，因为它们具有适当的功能。我意识到，他们对开发人员的信任是不可多得的。

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

祝您好运！