project-management - 如何降低维护成本

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改善这个问题吗？更新问题，以便可以通过 editing this post 用事实和引文回答问题.

2年前关闭。




Improve this question




已经到了五分之四的开发人员全职处理维护或支持问题的地步。

这主要是由于在开发过程中完全缺乏问责制(阅读:评论等)，并且到处都有数十个小型内部遗留应用程序，每个人都害怕替换它们。

管理层因进展缓慢而严厉打击部门，项目落后太多，因此诸如“审查”和“测试”之类的事情被视为浪费时间。

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

Answer 1

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

家里有经理吗？

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

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

我们靠自己

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

当重新编写代码的项目未经授权时，采取渐进的步骤并逐渐进行重构。

利用某些特化的好处。您似乎有几个开发人员可供您使用？他们不会喜欢它，但为了获得一些效率，他们中的一些人将不得不被分配为支持端的主要资源，特别是如果你处于管理层不会改变并期望你的位置同时做支持和项目。支持工作会干扰项目，项目会干扰支持；不同之处在于项目可以管理，而支持是不可预测的。您必须隔离它们以减少频繁上下文切换导致的生产力流失。如果你真的想对你的开发人员尽可能公平，那么在适当的时候让人们在支持和项目之间轮换。好好看看你的团队的技能；每个人都会说他们想要绿地项目，但当然有些人更擅长，而另一些人可能更擅长使用现有代码。

从你的错误中学习。看起来您的商店授权了许多自定义应用程序，但在业务分析和测试方面做得并不好，导致您现在拥有的支持负载。如果你不能完全纠正现有的代码库，至少你可以尝试把需求和测试(和开发)做得更好，以限制新东西带来的支持增加。

让用户参与进来。如果您的商店无法访问正式的业务分析和测试资源，那么用户将很有值(value)。他们还可以协助与管理层沟通希望事情变得更好。

无偿加类。我知道，光读这句话就很糟糕。根据您的描述，我必须假设您已经非常熟悉这个概念。但是，如果您对工作的地方感到满意并想留下来，您可能不得不做出所希望的暂时牺牲。示例:在我的商店中，我们过去常常通过 IDE 手动构建。但是我花时间研究了我们的开发工具附带的构建脚本语言，尽管我们仍然没有与自动化测试的持续集成，但构建和迁移构建的过程却少得多；一只猴子可以做到。它可以节省时间并使任务轻松转移到任何团队成员，无论他们的技能水平如何(正如 Totophil 所说:自动化)。这些是您可以做的事情来帮助团队节省时间。创建团队 wiki 或更好的用户文档是减少支持或减少麻烦的其他示例(尽管管理层不喜欢这些事情并且可能不喜欢使用正常的工作时间)。问问自己:是您想坚持的公司吗？你喜欢你的团队和你的用户吗？如果是这样，一些牺牲可能是值得的。如果没有，那就开始寻找。

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