如何降低维护成本

Question

有五分之四的开发人员全职处理维护或支持问题。

这主要是由于在开发过程中完全缺乏问责制（阅读：评论等），并且在各地都有数十个小型内部遗留应用程序，每个人都害怕被替换。

管理层正在努力争取很少的进展，项目落后，所以“评论”和“测试”之类的东西被视为浪费时间。

您如何开始减少这笔巨额开销？

Answer 1

您刚刚描述了大多数IT商店常见的情况！

众议院有经理吗？

这里已经有了一些很好的建议。我同意那些说这是管理问题的人。您可以尝试所有您想要的，但管理层需要了解有能力为公司设定方向的情况和管理。管理层必须决定是否会冻结开发，或者解决过去的问题比当前的项目更优先，或者需要重写，或者更好的方法是合理的，或者可能是某些人们需要将他们的键盘拿走。

现在，当然需要更好的编码，但沟通是最需要的技能。如果管理层开始感受到过去错误带来的痛苦，也许它已经准备好倾听，但是再一次，管理者可能是那些让你陷入困境的人通过犯下假设软件开发很容易的常见错误< / em>的。所以你的工作已经完成了。

我们是自己的

如果管理层没有改变，那么尝试一下IT-land中的许多人必须做的事情：

• 当未授权重新编写代码的项目时，采取渐进的步骤并逐步隐藏重构。
• 利用一些专业化的好处。您似乎有几个开发人员可供您使用？他们不会喜欢它，但为了获得一定的效率，其中一些将被分配为支持端的主要资源，特别是如果您处于管理层不会改变并期望您的位置同时做支持和项目。支持工作将干扰项目和项目将干扰支持;不同之处在于可以管理项目，而支持是不可预测的。您必须隔离它们以减少频繁上下文切换导致的生产力损失。如果你真的希望尽可能公平地对待你的开发者，那么让人们在适当的时候在支持和项目之间轮换。好好看看你的团队的技能;每个人都会说他们想要绿地项目，但肯定有些人会更好，其他人可能会更好地使用现有代码。
• 从错误中学习。您的商店似乎授权了许多自定义应用程序，但在业务分析和测试方面做得不好，导致您现在拥有的支持负载。如果你不能完全纠正现有的代码库，至少你可以尝试更好地完成需求和测试（和开发），以限制新东西带来的支持增加。
• 吸引用户参与。如果您的商店无法访问正式的业务分析和测试资源，那么用户将非常有价值。他们还可以协助与管理层沟通，希望事情变得更好。
• 无偿加班。我知道，只是阅读那句话很糟糕。根据您的描述，我必须假设您已经非常熟悉这个概念。但是，如果你对自己工作的地方感到满意并希望留下来，你可能不得不做出所希望的临时牺牲。示例：在我的商店中，我们曾经通过IDE手动进行构建。但是我花了一些时间来研究我们的开发工具附带的构建脚本语言，虽然我们仍然没有与自动化测试的持续集成，但制作和迁移构建的过程却相关性较小;一只猴子可以做到。它可以节省时间并使任务可以轻松转移到任何团队成员，无论他们的技能水平如何（如Totophil所说：自动化）。这些是你可以做的事情，以帮助团队节省时间。创建团队维基或更好的用户文档是减少支持或减少操作所涉及的麻烦的其他示例（尽管管理层不理解这些事情，并且可能不喜欢使用正常的工作时间）。问问自己：你想坚持的公司是谁？你喜欢你的团队和用户吗？如果是这样，一些牺牲可能是值得的。如果没有，那就开始寻找。

其他一些建议很棒，而且Totophil的帖子很棒，但听起来你已经陷入了深洞，并为可疑的管理工作;要做所有最佳实践建议都很困难。

Answer 2

如果管理层不了解什么是“反馈循环”（即评论，测试），那么可能会切换工作？

从经验来看，公司的文化是一件难以改变/需要时间的事情：如果你发现自己处于你所描述的情境中，那就自救吧。

Answer 3

不要试图立刻吃掉整只大象！

确定特定的应用程序或其部分，这些应用程序或其部分往往会导致大部分维护费用并且似乎相对容易改进...是的，我知道找到这样的目标并不容易，但暂时关注更多的努力在这些“轻松胜利”中，你将完成两件事：

• 提高管理层和其他利益相关者的可信度
• 减少，如果只是逐步减少维护所花费的时间。

因此，随着时间的推移，有更多的时间来清理代码的其他部分以及给予更多时间来正确地做事（例如，通过评论和单元测试）。

Answer 4

通常有助于与管理层交谈并向他们解释问题所在。基本上你在问题中提到的相同的事情。让他们知道您没有取得进展，因为团队花了很多时间来做应用程序支持。还让他们知道应用程序有严重的位腐烂，需要修复。向他们解释解决这些问题需要时间和投资。

一旦管理层明白为什么事情不能正常运作，您就可以一起制定计划以控制事情。您可以保证满足技术需求，并确保对业务需求敏感。尝试并提出一个计划，其中50％的时间用于修复应用程序，另外50％用于解决业务问题。这些百分比是可以协商的，所以看看你能得到什么！

祝你好运......

Answer 5

选项包括：

• 自动化
• 代表
• 修复根本原因
• 吸引更多人
• 整理
• 跳过并承担风险
• 或以上的组合。

但第一步是收集一些数据，然后进行快速分析：

1. 按root cause分类现有和历史问题，所需的来源，频率和工作量。

2. 使用Pareto Charts可视化需要付出最多努力的区域或来自单一来源的区域。关注这些领域将带来最大的好处，并将使人们免于处理其他维护问题。

修复根本原因

始终致力于解决问题的根本原因。解决方案不需要昂贵，“工程艺术是用一美元，任何该死的傻瓜可以做两个”。使用Five Whys等分析技术来解决问题的根源。

阅读问题其中一个根本原因似乎与当前的软件开发过程以及为快速向现有系统添加功能所施加的压力有关，这导致通过一系列项目提供的低质量代码增加了负担维护。这通常是由于项目预算不包括任何维护成本时项目计划和预算不正确而导致的，并且一旦将更改交付给用户，计划就会突然结束。正确的方法是在可交付成果的整个生命周期内包括和跟踪维护成本，然后将其添加到组织预算中。该图将更有动力提供强大的代码，并帮助在各种项目选项之间做出更好的选择。

试着看看维护增长是否还有其他“隐藏的激励”。

<强>代表

IT部门或项目团队通常可以被视为组织内的免费资源，用于培训用户，运行数据转换，报告，执行例行系统配置，数据更正以及其他部门可以真正完成的其他任务。

可以将这些任务委托给其他业务部门（通过为他们提供工作来完成工作）或外包给外部供应商（如果是非业务关键或特定系统，您可以获得更好的服务优质服务或来自公司外部的托管应用程序）。

简化教育用户执行更复杂任务的任务。组织和支持用户社区，以便他们可以解决最常见的问题，而无需依赖您的时间。

<强>自动化

自动化可自动化的事物，包括日常监控。事情不能完全自动化，至少部分地自动化它们，提供一种维护脚本库来完成部分过程的方法。帮助团队成员学习脚本工具和语言。

整理

将类似问题组合在一起并立即执行。解决时间可能会增加，但在同一系统中同时重置5个密码需要的工作量较少。

为用户提供一种报告和跟踪问题的方法，使您能够以更有条理的方式处理维护，也就是说，不要让某人在电话上等待问题得到解决直接有一个问题跟踪系统有优先权，所以事情可以更有序地处理，并给你更多的机动，如何和何时处理特定类别的问题。

略过维护并承担风险

评估不进行某些维护的风险和影响。如果足够低，那么让每个人都意识到工作将无法完成并继续前进。

Answer 6

那个项目很可能注定要失败。如果管理层不支持代码审查和测试等最佳实践，那么就无法提供帮助。

我会试着说服管理层，从长远来看，实施测试套件和进行代码审查会节省时间。

如果没有正确的流程，错误修复将只是半思考的补丁，很可能会引入新的错误，这将需要更多的时间来修复，这将导致更多错误，这将花费过多的时间和钱。

现在花一两个月来解决问题并开始一个正确的过程实际上比继续当前流程花费更少的时间和金钱。

如果事情没有改变，我会强烈考虑在其他地方找工作，你比这更好，你的问题证明了这一点。

Answer 7

如果你需要一些东西才能开始。使用“冻结”方法可以节省开销。这是一个很好的管理术语，在这种情况下很好理解。

Answer 8

我参与过这样的项目，这是一次死亡之旅。我们发现解决方案是“偿还抵押贷款”。找到花费你最多时间的东西，并努力纠正这些。一旦完成，您将腾出时间处理其他较小的问题。一个好主意是将TDD拉入您的流程，如果您可以放置​​足够的测试，那么您可以开始进行更改而不必担心会破坏更多的东西。