已经到了这样的地步，即五分之四的开发人员全职处理维护或支持问题。
这主要是由于在开发过程中完全缺乏问责制（阅读：评论等），并且到处都有数十个小型内部遗留应用程序，每个人都害怕更换。
管理部门因进展甚微而受到严厉打击，项目落后，因此诸如“审查”和“测试”之类的事情被视为浪费时间。
你甚至会如何开始减少这个巨大的开销？
问问题
754 次
8 回答
4
您刚刚描述了大多数 IT 商店中常见的情况！
房子里有经理吗？
这里已经有一些很好的建议。我同意那些说这是一个管理问题的人的观点。你可以尝试任何你想要的东西，但需要了解情况的管理层和有权为公司设定方向的管理层。管理层必须决定将冻结开发，或者解决过去的罪过比当前的项目更重要，或者需要重写，或者有更好的方法是合理的，或者也许一些人们需要拿走他们的键盘。
现在，当然需要更好的编码，但沟通是最需要的技能。如果管理层开始感受到过去错误的痛苦，也许它已经准备好倾听，但话又说回来，管理者可能就是那些让你陷入困境的人，他们犯了假设软件开发很容易的常见错误。所以你有你的工作为你完成。
我们靠自己
如果管理层没有改变，那么请尝试我们在 IT 领域的许多人必须做的一些事情：
- 当重做代码的项目未经授权时，采取渐进的步骤并逐渐潜入重构。
- 利用一些专业化的好处。您似乎有几个开发人员可供您使用？他们不会喜欢它，但为了提高效率，他们中的一些人将不得不被分配为支持端的主要资源，特别是如果你处于管理层不会改变并期望你的位置同时做支持和项目。支持工作将干扰项目和项目将干扰支持；不同之处在于项目可以管理，而支持是不可预测的。您必须隔离它们以减少频繁的上下文切换导致的生产力消耗。如果您真的想尽可能公平地对待您的开发人员，那么让人们在适当的时候在支持和项目之间轮换。好好看看你的团队的技能；每个人都会说他们想要新建项目，但肯定有些人更擅长，而其他人可能更擅长使用现有代码。
- 从你的错误中学习。您的商店似乎授权了许多自定义应用程序，但在业务分析和测试方面做得不好，导致您现在的支持负载。如果你不能完全纠正现有的代码库，至少你可以尝试在需求和测试（和开发）方面做得更好，以限制新东西带来的支持增加。
- 让用户参与进来。如果您的商店无法访问正式的业务分析和测试资源，那么用户将是有价值的。他们还可以协助与管理层沟通希望事情变得更好。
- 无偿加班。我知道，光是读那句话就糟透了。根据您的描述，我不得不假设您已经非常熟悉这个概念。但是，如果您对自己工作的地方感到满意并想留下来，您可能不得不做出暂时的牺牲。示例：在我的商店中，我们过去常常通过 IDE 手动构建。但是我花时间研究了我们的开发工具附带的构建脚本语言，虽然我们仍然没有与自动化测试进行持续集成，但制作和迁移构建的过程要少得多；一只猴子可以做到。它节省了时间，并使任务可以轻松地转移给任何团队成员，无论他们的技能水平如何（正如 Totophil 所说：自动化）。这些是你可以做的事情来帮助团队节省时间。创建团队 wiki 或更好的用户文档是减少支持或参与其中的麻烦的其他示例（尽管管理层不喜欢这些事情，并且可能不喜欢使用正常的工作时间）。问问自己：这家公司是你想坚持的吗？你喜欢你的团队和用户吗？如果是这样，一些牺牲可能是值得的。如果没有，然后开始寻找。
Several of the other suggestions are great and Totophil's post is awesome, but it sounds like you're already in a deep hole and working for questionable management; it would be difficult to do all the best practice recommendations.
于 2009-12-02T17:11:44.940 回答
1
如果管理层不理解什么是“反馈循环”（即审查、测试），那么可能换工作吗？
根据经验，公司文化是一件很难改变/需要时间的事情：如果您发现自己处于您所描述的情况，那么请自救。
于 2009-12-02T03:19:58.807 回答
1
不要试图一次吃掉整只大象！
确定特定的应用程序或其部分，这些应用程序往往会导致大部分维护开销，并且似乎相对容易改进......是的，我知道找到这样的目标并不容易，但暂时将更多的精力集中在这些“轻松获胜”，您将完成两件事：
- 提高管理层和其他利益相关者的可信度
- 减少，如果只是逐步减少花费在维护上的时间。
因此，随着时间的推移，有更多的时间来清理代码的其他部分，并有更多的时间来正确地做事（例如，通过审查和单元测试）。
于 2009-12-02T03:23:00.390 回答
1
通常，与管理层交谈并向他们解释问题所在会有所帮助。基本上与您在问题中提到的相同。让他们知道您没有取得进展，因为团队花费大量时间进行应用程序支持。还要让他们知道应用程序有严重的位腐烂，需要修复。向他们解释解决这些问题需要时间和投资。
一旦管理层了解了为什么事情不能正常工作，您就可以共同制定一个计划来控制事情。您可以保证技术需求，并确保并对业务需求保持敏感。尝试制定一个计划，假设 50% 的时间用于修复应用程序，另外 50% 用于解决业务问题。这些百分比是可以协商的，所以看看你能得到什么！
祝你好运...
于 2009-12-02T03:32:14.887 回答
1
选项包括：
- 自动化
- 代表
- 修复根本原因
- 让更多人
- 组织
- 跳过并承担风险
- 或以上的组合。
但第一步是收集一些数据，然后进行快速分析：
修复根本原因
始终致力于解决问题的根本原因。解决方案不必很昂贵，“工程的艺术就是用一美元做任何该死的傻瓜都可以用两美元做的事情”。使用诸如五个为什么之类的分析技术来找出问题的根源。
阅读问题的根本原因之一似乎与当前的软件开发过程以及向现有系统快速添加功能所施加的压力有关，这导致通过一系列项目交付的低质量代码增加了维护负担。这通常是由于不正确的项目计划和预算造成的，因为项目预算不包括任何维护成本，并且一旦将更改交付给用户，计划就会突然结束。正确的方法是在可交付成果的生命周期内包括和跟踪维护成本，然后将其添加到组织预算中。该数字将首先提供更多动力来交付强大的代码，并有助于在各种项目选项之间做出更好的选择。
试着看看是否有任何其他“隐藏的激励”来维持增长。
代表
IT 部门或项目团队通常可以被视为组织内的免费资源，用于培训用户、运行数据转换、报告、执行日常系统配置、数据更正和其他真正可以由其他部门完成的任务。
这些任来自公司外部的托管应用程序）。
要么简化任务，要么教育用户执行更复杂的任务。组织和支持用户社区，这样他们就可以解决最常见的问题，而不必依赖您的时间。
自动化
自动化可以自动化的事情，包括日常监控。有些事情不能完全自动化，至少部分自动化，提供一种维护脚本库来完成部分流程的方法。帮助团队成员学习脚本工具和语言。
组织
将类似的问题归为一组，然后一次性完成。解决时间可能会增加，但在同一系统中一次重置 5 个密码所需的工作更少，每个密码都单独执行。
为用户提供一种报告和跟踪问题的方法，使您能够以更有条理的方式处理维护，也就是说，而不是让某人在电话上等待问题立即得到解决具有优先级的问题跟踪系统，因此可以以更有序的方式处理事情，并为您在如何以及何时处理特定类别的问题方面提供更多的回旋余地。
跳过维护并承担风险
评估不进行某些维护的风险和影响。如果足够低，那么让每个人都意识到工作将无法完成并继续前进。
于 2009-12-02T11:04:56.957 回答
0
那个项目很可能在那时注定要失败。如果管理层不支持代码审查和测试等最佳实践，则几乎无能为力。
我会尝试让管理层相信，从长远来看，实施测试套件和进行代码审查会节省时间。
如果没有适当的流程，错误修复将只是半途而废的补丁，很可能会引入新的错误，这将需要更多的时间来修复，这将导致更多的错误，这将花费过多的时间和金钱。
现在花一两个月的时间来解决问题并开始一个适当的流程实际上会比继续当前流程花费更少的时间和金钱。
如果事情没有改变，我会强烈考虑在其他地方找工作，你比这更好，你的问题证明了这一点。
于 2009-12-02T03:23:21.497 回答
0
如果你需要一些东西来开始。使用“冻结”方法可以击败开销。这是一个很好的管理术语，在这种情况下很好理解。
于 2009-12-02T03:24:15.147 回答
0
我从事过这样的项目，这是一次死亡之旅。我们发现解决办法是“还清房贷”。找出最耗费您时间的事情并努力纠正这些事情。完成后，您将腾出时间来处理其他较小的问题。一个好主意是将 TDD 引入您的流程，如果您可以进行足够的测试，那么您就可以开始进行更改，而不必担心会破坏更多的东西。
于 2009-12-02T03:31:05.857 回答