如何降低维护成本[关闭]答案

【问题标题】：How to reduce maintenance costs [closed]如何降低维护成本[关闭]
【发布时间】：2009-12-02 03:17:02
【问题描述】：

现在每 5 名开发人员中就有 4 名全职处理维护或支持问题。

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

由于进展甚微，项目进度落后，管理层对部门进行了严厉打击，因此诸如“审查”和“测试”之类的事情被视为浪费时间。

您将如何开始减少这种巨大的开销？

【问题讨论】：

你应该创建这个社区维基
我投票结束这个问题，因为它与编程无关。

标签： project-management project-planning maintenance

【解决方案1】：

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

房子里有经理吗？

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

现在，当然需要更好的编码，但沟通是最需要的技能。如果管理层开始感受到过去错误的痛苦，也许它已经准备好倾听，但话又说回来，经理们可能就是那些让你陷入困境的人，他们犯了假设软件开发很容易的常见错误。所以你有你的工作为你完成。

我们靠自己

如果管理层没有改变，那么请尝试我们在 IT 领域的许多人必须做的一些事情：

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

其他一些建议很棒，Totophil 的帖子也很棒，但听起来你已经深陷困境并为有问题的管理层工作；很难做到所有的最佳实践建议。

【讨论】：

【解决方案2】：

如果管理层不了解什么是“反馈循环”（即审查、测试），那么是否可以换工作？

根据经验，公司文化很难改变/需要时间：如果您发现自己处于您所描述的情况，那就自救吧。

【讨论】：

【解决方案3】：

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

一旦管理层了解为什么事情无法正常运行，您就可以共同制定计划来控制事情。您可以保证技术需求，并确保并对业务需求保持敏感。尝试制定一个计划，假设 50% 的时间用于修复应用程序，另外 50% 用于解决业务问题。这些百分比是可以协商的，所以看看你能得到什么！

祝你好运……

【讨论】：

【解决方案4】：

不要试图一次吃掉整只大象！

确定特定的应用程序或其部分，它们往往会导致大部分维护开销，并且似乎相对容易改进......是的，我知道找到这样的目标并不容易，但通过暂时集中更多的精力在这些“轻松获胜”上，您将完成两件事：

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

因此，随着时间的推移，有更多时间清理代码的其他部分，并有更多时间正确地做事（例如，审查和单元测试）。

【讨论】：

【解决方案5】：

选项有：

自动化
委托
修复根本原因
吸引更多人
组织
跳过并冒险
或以上的组合。

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

按root cause、来源、频率和所需努力对当前和历史问题进行分类。
当使用Pareto Charts 可视化需要最大努力或来自单一来源的区域时。关注这些区域将带来最大的好处，并使人们有时间处理其他维护问题。

解决根本原因

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

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

尝试看看是否有任何其他“隐藏的诱因”来维持增长。

委托

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

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

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

自动化

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

组织

将类似的问题归为一组，然后一次性完成。解决时间可能会增加，但在同一系统中一次重置 5 个密码所需的工作更少。

为用户提供一种报告和跟踪问题的方式，使您能够以更有条理的方式处理维护，也就是说，而不是让某人在电话中等待问题得到解决立即拥有具有优先级的问题跟踪系统，因此可以以更有序的方式处理事情，并为您提供更多操作空间，以了解如何以及何时处理特定类别的问题。

跳过维护并承担风险

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

【讨论】：

【解决方案6】：

那时那个项目很可能注定要失败。如果管理层不支持代码审查和测试等最佳实践，则无能为力。

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

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

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

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

【讨论】：

【解决方案7】：

如果您需要一些东西来开始。使用“freeze”方法可以克服开销。这是一个很好的管理术语，在这种情况下很好理解。

【讨论】：

【解决方案8】：

我从事过这样的项目，这是一场死亡之旅。我们发现解决办法是“还清房贷”。找出花费你最多时间的事情并努力纠正这些事情。完成后，您将腾出时间来处理其他较小的问题。一个好主意是将 TDD 引入您的流程，如果您可以进行足够的测试，那么您就可以开始进行更改，而不必担心会破坏更多的东西。

【讨论】：