如何向管理层推销“好代码”的好处?

“技术债”(或“工程债”)的概念对商人来说是有意义的。解释一下,当你做一些快速而肮脏的事情时,你会招致“债务”,因此每次你以后做出改变时,你都会支付“利息”。这就是为什么,例如,在一个债台高筑的代码库中,向表单添加一个小字段可能需要四周时间。

然后解释你可以通过重构(或者任何你想用来清理的术语)来偿还债务,然后持续的利息支付将会减少。

显然,就像任何隐喻或类比一样,它可能会变得紧张,但通过使用商业/金融术语,它可能比程序化更有效地刺激他们的大脑。

我发现只有三种方法可以向管理层出售维护:

• 无需询问就可以完成,但要将其转化为功能开发
• 问一下,但是说有必要考虑到一个特定的特性或一类特性
• 让他们相信,他们将通过以后更快的特性开发来赢得花在维护上的时间。

简而言之:管理层谈论的是特性,而不是代码。

使用他们最喜欢的“范例”:大局

这是他们大多数人都理解的一个术语,因为他们都把自己看成是“大局”型的人。 让步 做错事的意义 可以 在某些情况下,短期内可以赚更多的钱,但从长远来看(或“大局”),维护、销售和重新部署坏代码的成本更高,这样做的间接人工时间也值得。 正确的 .

例如:“你需要看一下‘大局’,看看我们做错事会赔钱的。”

多年来,每当我试图告诉经理和团队领导我们正在研究的代码 烂透了 我受到了很大的反弹。(我没用过这工作。)不用说,你的公司是在赚钱,在他们看来,如果没有破产,就别修了。而且,你可以让事情变得更糟。

然而,我确实设法重写了一些东西,等待机会出现。需要添加一些新的特性,代码被忽略了几年,甚至几乎没有编译。我把它卖给了我的团队领导和经理,因为它将是一个更好的投资回报率,在未来增加更多的东西。也就是说,对我来说,重写它并添加它们的新特性要比弄清楚旧特性是如何工作的并在其中插入解决方案快得多。

你通常不能通过简单的讨论说服他们。几乎唯一有效的方法就是通过编写干净的文档化代码(可能是在修复错误时重构小块代码)来“展示”它们,并跟踪开发人员在“干净”与“杂乱”代码中修复新错误所需的时间。

这需要一个好的bug跟踪系统,包括工作时间条目等,然后您才能实际制作一个减少“bug修复”时间和/或减少已清理代码模块中“新bug”的图表。

这是一条很长的路要锄头。-)

你能证明支持成本在上升吗?无论是支持事件的数量,还是开发人员花费在支持上的时间百分比。

尝试识别可管理的重构,以改进事情,然后展示最近的错误是如何避免的。

在保持新的销售流动所需做的工作与长期改善软件“基础设施”所需做的工作之间,总是存在着一种困难的紧张关系。证明“基础设施”工作的回报在短期内发生,是让管理层注意到这一点的最简单方法。

有时使用类比可以帮助非技术人员理解。

对于我发现的代码重构、维护等为什么很重要,最好的类比就是这个。它是从一个 post 在 Slashdot :

每个人都举行了一个盛大的宴会 然后把盘子放了几下 天。更糟的是,有个室友 是谁干的。结果证明这很糟糕,因为 如果你只是想让自己成为 吃点早餐,那就更难了 厨师。你必须刮掉一个平底锅 切掉一个盘子就可以开始了。 烹饪是工作的两倍 因为你必须改变混乱的局面 在柜台附近转悠,然后 然后再换一次 炉子。

当你做完后,你肯定不会 洗干净;水槽 已经盛满了盘子。所以你 把盘子扔在 那堆,说你会找到的 “后来”。当然,这是不断增长的 一堆堆模糊的盘子是 半代码的真实类比 我见过的基地。巨人 不可避免的改写是 就像拆掉你的厨房 建造一个新的因为那是 最便宜的摆脱困境的方法。

相反,好厨师干干净净。他们 随时随地打扫。总是。不是因为 他们是紧张的怪胎,但是如果 他们没有,混乱会减慢他们的速度 最终让他们变得更糟 导致一个巨大的混乱,和 他们所有的同事都对他们大喊大叫。

基本上:更好的代码=更少的维护。维护更少=开发人员开发新功能的时间更长。新功能=增加收入。

另外:更好的代码=新开发人员的学习曲线更低。

我的经验是,销售“清理代码库”项目总是失败的。我建议您选择以下选项之一:
1。开始为小维护分配时间,以及您估计的所有未来工作。您可以使用这样的论点:只要您向现有模块添加一个特性,您就可以在那个时候改进它,因为您更熟悉这个特性。一定要表达随着时间的推移而改进的好处,并且在更长的时间内它更便宜,而不是“清理代码库”项目。
2。开始为小维护分配时间以及所有未来的工作,但不要告诉任何人。如果有人发现了,只需告诉他们您需要重构有问题的模块,以完成您要添加的功能。

首先,我建议你看看你是否能做到双赢。通过这一点,找出软件不满足公司需求的差距(例如,它是否限制了业务类型,员工是否有大量的复式输入,或者管理层是否缺乏良好的报告),并将系统大修与之结合起来。

成本核算有多种方式:

1)缺乏可操作的数据。如果报告速度慢(到不再有效的程度),或不准确,或不存在,这对管理者来说是最有意义的一个领域。

2)如果发生人工输入或重复输入,并且可以自动输入,则确定受影响的员工数量、频率,并向公司估算其成本。然后你可以把损失计算为(每个人)损失的时间*这个人的成本之和。

3)确定机会成本的领域——例如员工或管理层受到限制的领域。找出客户不满意,并且由于系统缺乏灵活性而没有返回的场景。

我找到了 Technical Debt 隐喻在试图说服非技术人员投入资金以支持代码库的改进时非常有用。其基本思想是,通过让代码的质量受到影响而产生更多的特性,就像是为了利用机会而获得贷款:你可以做到,但是如果你不偿还贷款,你将被利益所压倒。同样,如果你从不解决质量问题,你的进度会越来越慢,直到应用程序被丢弃为止。

您可能希望考虑到您公司的优先级不利于生成星型代码。

如果不是这样,那么就提出具体的建议,并根据具体想法的优点销售您的建议,因为它们反映了组织的目标。

根据它如何帮助实现业务目标来销售它。

不要说“如果我们这样做,这意味着一旦我们发现了一个bug,我们就可以更快地管理它”。 相反,把它放在一个不真正关心技术方面的人会理解和理解的角度。比如说“如果我们这样做,我们就能够增加总收入,同时提供更好的产品”。

如果你能做到这一点,这意味着做出更大决定的人通常会更乐于接受。

开发人员编写代码,而不是管理人员。我敢肯定你的管理层从来没有告诉开发人员去写垃圾代码。我认为您需要说服其他9个开发人员,编写的所有新代码都需要满足更高质量的标准。

我怀疑你是否会得到经理的同意去重写大块的代码,因为你认为质量很差,但是,你应该能够在你的同事开发人员身上花点心思,至少让他们走上正确的道路。

在其他开发人员的支持下,您可能能够说服经理分配空闲时间进行清理。

这取决于你的商店所处的商业模式。如果你正在为一些公司制作下一个大型的视频游戏、下一个大型的IDE或下一个大型的CRM系统,那么清理一些代码库的优点可以用非常不同的方式进行评估。

我只做过服务开发,所以我不能解释在任何其他业务模型下代码清理的合理性,但这里是我的0.02美元用于服务开发:

如果您正在为某个外部公司进行服务开发,则很难推销清理工作。”你是说你给我们写了坏代码?现在你想要更多的钱来清理它?”这是一个没有商店愿意回答的问题。作为开发人员,我们并不总是意识到我们的时间花费了客户多少,他们非常注重将成本与直接业务价值挂钩。

因此,我希望在这个场景中完成代码清理的一种方法是将清理描述为对某个变更单或特性请求进行“必要的修改”。这允许企业将清理成本与一些直接价值(即变更或特性)联系起来,并允许他们使用熟悉的通用成本效益分析。这让你有时间做一些清理,但要注意范围。当你有一周的时间清理的时候打开一罐蠕虫可能是危险的事情。您的建议可能没有说,“我们将重新编写应用程序,然后实现您的功能。”请与您的客户进行一些风险和期望管理,并保持诚实和道德。

也许其他人可以在软件开发的不同商业模式下回答这个问题…

他们很可能理解权衡,接受风险。我认为在你进行的过程中重新考虑因素的建议可能是你唯一的希望。

如果他们像你所说的那样是一家小公司,他们会更感兴趣的是留在企业中,而不是拥有好的代码。其他60家开发商可能也没有类似的抱怨(我希望资产负债表/现金流报告/预算/营销预算/销售线索/停车场更好)。每个人都有一个位置来决定真正的人们的工作和生计(包括提问者在内),最终会在今天陷入困境。当你是一个小企业时,这是正确的做法。

如果你真的很幸运的话,你会在董事会会议室找到一个富有同情心的技术专家,这样至少你会有一个理解你的痛苦的人,可能会让你有足够的空间把一些非常糟糕的代码作为一个副项目或者在一个主要的bug发布过程中删掉。那个人可能不需要太多的说服力。

另一个想法…

您可能想做的事情是保持细致的错误统计,按代码组件组织。通过这种方式,您可以证明或反驳代码库中缺乏质量会导致交付的产品中出现更多错误。如果您看到特定组件每月报告的错误数量稳步上升,您可以将其放在图表上,并让它在未来继续上升,向管理层证明,最终,您的团队中有一半将忙于维护该组件。

如果您每周或每月发送一个bug统计报告,这也将帮助您的团队,因为您会感到有必要分析导致bug更改的原因,并采取相应的措施。

我怀疑你的老板是否会理解干净的代码如何为你的公司赚更多的钱的真正本质,除非你为一家中高层管理人员作为程序员在许多不同规模的软件公司积极工作的公司工作。别费心给他们编程器的理由,只是不明白。相反,你必须给他们结果。

我的建议是找到一个足够小而不完全被遗留代码负担的项目,并选择一种您认为有助于清理系统的方法,然后就这么做。跟踪您的更改,记录流程中的差异是如何改进的,然后在系统中跟踪结果。最后,如果您确实对代码行做出了积极的贡献,并且您的贡献经常顺利通过测试,而您的同事却不这么做,那么人们会听您的。

一旦他们看到解决方案的好处,他们就会更加关注问题。

更好的代码更容易维护,但更重要的是,通过 原作者以外的人 .

编码标准允许开发人员更“可互换”——这对开发人员很好,因为很少允许产品上的Hero编码人员从事任何其他工作。

我去过那里——你觉得自己真的很需要,对公司很重要,大约一年了,但很快就会开始想为什么你总是被升职而忽略了,永远也不去做有趣的新工作。

作为一个企业,你需要的是灵活性和安全性——如果你的明星开发者中了彩票,或者最终认为他已经厌倦了在同一件事情上工作五年,你就要继续工作。如果有大好机会,你希望能够迅速扩大规模。

写得好、评论得好、符合标准和经过单元测试的代码编写成本更高,但对业务来说价值更大。

任何企业的经理是否希望将其成功与一个长期存在的开发人员或小型团队挂钩?如果是(他们疯了吗?)然后认为开发人员每2-5年移动一次公司,他们的技能集是100%可转让的。

10年的代码库可能需要几个月的时间,新开发人员才能做出任何贡献。每次你失去一个开发者,实际上你都会失去他们六个月的时间(更不用说招聘)。如果你的团队被严重孤立,你可能会损失更多,因为其他人需要数周时间来解决离开者代码中的小问题,因为他们不知道它是如何工作的。

有很多关于如何构建新项目的研究,这些项目不存在这些问题(我自己使用一个定制的敏捷变体),但是对于改变中间流程的研究却很少。

如果不了解公司的更多情况,我想你是无能为力的。

你说的方式,他们甚至不知道他们有问题,更不用说寻求解决。他们很可能会把你看成是在寻找一个他们认为不存在的问题的人。

十年的“经验”是一个很大的斗争。从他们的角度来看,他们有一个产品,它是工作的,当然有麻烦和持续的维护和客户问题,但没有人能与结果争论?他们能吗?另外,每个人都有这些问题,对吗?

也许你会比我运气好,但他们找的少,我想你永远也不会让他们看到。