it-swarm.cn

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

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

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

164
Desolate Planet

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

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

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

194
jmort253

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

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

我认为我很喜欢Renesis在他的回答中所说的,因为它是少数几个理解管理层与工程学思维截然不同的人之一。而且我认为我们所有人都已经看到公司的发展已成为日期驱动和更加项目管理的公司,而不是以客户和质量为中心。我的意思是说典型的公司,而不是那些胆敢说“完成后会完成”的真正坚定的公司(例如Apple计算机或id软件-是的,我了解有时候人们没有采取这种方法的自由)。

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

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

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

48
Bernard Dy

首先要做的是更改措辞。称其为“技术债务”使管理层认为允许它是某种投资-实际上是更像病毒。 (我就像技术债务的 Dave Ramsey 。)

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

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

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

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

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

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

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

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

30
Karl Bielefeldt

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

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

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

20
Péter Török

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

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

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

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

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

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

12
biziclop

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

否则,它们会下降快速

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

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

12
Orbling

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

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

12
EricSchaefer

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

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

是的,其中一些数字将是伏都教/烟与镜子...没关系,管理的肮脏秘诀是他们知道他们随身携带的大多数数字都是B.S.只要您给他们看似可以使用的具体东西,以便他们能想到,您就有了战斗的机会。

7
mindcrime

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

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

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

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

6
BЈовић

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

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

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

作为客户,您自己会买哪个?

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

4
jasonk

技术债务 ”可能很难呈现给管理层,因为他们可能没有必要。问题可以这样形容为:公司中是否有拥护者说:“看,我们在这方面花了X%的时间来处理技术债务。请给我们3个月的时间来证明它运行良好”或其他类似。那里声称拥有自治权,但也有时间限制,否则管理层可能会想知道他们要等多久才能看到一些相当危险的结果。

但是,第一点是他们是否认为这是一个问题。如果视力不好的人对眼镜一无所知,他们不知道可以提供什么样的更换,那么他们如何理解为什么进行眼科检查很有价值?同样的想法在这里是相当技术性的,不幸的是不容易量化。

3
JB King

您应该停止抱怨它。

原因如下:

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

因此,最好的前进方式是:

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

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

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

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

我敦促您避免像瘟疫这样的任何重写/重构项目,它们可能是任何职业生涯中最令人沮丧的经历。

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

2
James Anderson

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

达成协议的关键因素:

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

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

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

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

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

特定模块有问题时:

  1. 编写一组演示该问题的测试如果不重构也可能失败
  2. 重构作为开发的一部分,指出测试仍然失败。
2
Steve Barnes

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

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

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

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

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

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

祝好运!

1
Matt Cashatt

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

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

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

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

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

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

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

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

1
Jay Elston