当他们的团队多年来缺乏产品创新，不使用项目mgmt方法并保持不良的软件开发实践时，如何做为开发人员？[关闭]

我有兴趣知道如何处理当前的软件开发流程，该流程多年未变，最终会导致产品和团队失败。是的，解决这个问题的更简单方法可能是换工作，但是有了这种经济，说起来容易做起来难。但是，如果您有特定的示例，并且在相同的情况下曾经或多次出现，并且认为解决这些问题的最佳解决方案是离开公司，那么请支持您的回答。关键是，这个问题确实有答案，特别是如果该主题的多个专家最终指出最好的路线是：路线A。

我知道成千上万的开发人员曾经或正在经历类似的情况。这是公司从在市场上排名第一变为最后甚至退出市场的主要原因之一。希望本文中的答案能够帮助其他面临类似障碍的开发人员。在小型或大型开发团队中，通常会发生以下情况：

• 一些开发人员似乎并不在乎并决定顺其自然，而宁愿让代码充满很多代码味道，保持开发流程不变，
• 其他人厌倦了不变，辞职并搬到另一家公司，
• 其他人似乎害怕说话，宁愿保持沉默，
• 有时，很少有开发人员或只有一个开发人员试图说出要改进产品的情况，并告诉团队遵循最佳编码实践的重要性和对客户，用户和团队的益处。这些类型的开发人员通常由于诸如公司提供的收益，软件公司提供的收益很少，产品具有很大的潜力等原因而决定留在团队中。

我们团队中的产品仅是公司从中获得收入的一小部分，因为它拥有大量产品（该公司不是软件/硬件公司；因此，至少在目前，没有持续的专利诉讼可创造工作机会）不稳定）。这些年来，我从其他开发人员的经验中学到的东西是，要真正认识一个开发团队，需要花费时间，而不是几天或几周，而是几个月。在面试过程中，团队是否要雇用您或需要您；它们使一切听起来很棒，并且它们可能会告诉您您想听的内容。但是，当您开始在该团队中工作并开始深入研究代码并迈向完整的SDLC流程时，现实就不同了。这是作为开发人员时，您开始看到自己从事的工作的现实。这种现实使得很难从一家公司转移到另一家公司，因为很难知道您所迁移的公司是好是坏。是的，您可以阅读Glassdoor的评论等。但是，这些在线评论中有多少是真实的，而不是来自HR？

考虑到经理从一开始就一直拒绝更改，而以前的开发人员已经这样做了多年，那么解决以下概述的问题的最佳方法是什么？

• 多年来缺乏产品创新：产品具有巨大的潜力，并为公司带来了可观的收入，但产品看起来像20年前制造的。一些用户抱怨该产品不友好，不直观，而另一些用户则提到该产品已用于Gmail等应用程序，并且由于不具有类似功能而在使用该产品时感到沮丧。这里的主要问题是，当您作为开发人员尝试对产品进行更改并开始将产品的主要元素移开几个像素（以使其更加用户友好或直观）时，经理会慌张并告诉您把它放回原处。如果您尝试添加对用户有利的功能，经理会要求您删除它，因为“用户习惯于按原样进行处理等。” 我认为您理解了变革，改进和创新的阻力（即使您作为开发人员提供了强有力的利益主张，经理也不愿意改变）。公司在该领域有一些竞争对手（其中的几个产品更具竞争力），但是公司以某种方式保持了现有客户多年。

• 缺乏项目管理协调：因此，一些项目交付较晚，存在错误，有些客户抱怨（客户也报告错误），或者在交付项目之前预算太快等。我已经提供了它们一些项目协调技巧，并且现在定期使用这些想法来跟踪项目和要完成的任务的进度。

• 不良的软件开发实践：在大多数（如果不是全部）文件上看到代码异味，没有文档，代码冗余，在同一文件上混合了前端层和后端，过时的开发工具，没有真实的测试环境或测试工具（只需复制和粘贴）文件从开发环境到生产环境，然后手动进行测试，看情况是否良好并发布）。我用于开发和测试的大多数开发工具都是团队不知道的，因为团队仅使用2个IDE进行代码开发，而源代码控制仅适用于开发环境。其他开发人员试图使用最新的框架来改善当前问题，但是经理不喜欢它，因为“如果离开，那么谁来维护该代码？让我们保持现状”，其中一些开发人员已经离开并搬到另一家公司。

综上所述，我确定其他公司的许多开发人员也会遇到类似的情况，但是由于情况不同，开发人员可能更愿意留在团队中而不是去其他公司，原因是（工作便利，工作灵活性，公司收益或只是因为还没有一个更好的机会）。我没有一家完美的公司，但是作为开发人员，您将如何处理和解决所有这些问题，以保持积极的态度，并最终促进变革，以改进产品并改善软件开发流程（无论您是否有很多）多年的开发经验还是仅几个）？我知道这是一篇很长的文章，但是我希望提供更多细节，以增加获得更多有用反馈的机会。

非常感谢您的反馈和时间

马丁·福勒（Martin Fowler）的话是相关的：“您可以更改组织或更改组织。” 鉴于您显然已决定更改组织（使其更好）而不是更改组织（为其他组织工作），这里有一些建议。

首先，您的许多行动都取决于有关权力结构和工作中的政治细节。有一个软件开发经理，还是几个？如果是几个，那么有没有不厌其烦的人呢？有多少软件开发人员？开发人员有兴趣改变吗？如果是这样，即使没有管理层的批准，您也应该可以进行一些更改。（正如Fowler在Refactoring中建议的那样，您甚至不必告诉管理人员。您可能被雇用来尽最大努力开发软件，因此，如果有更好的方法来做，那就去做吧。）

其次，请记住，管理层可能会对自己的工作有充分的理由。您是软件开发人员；您的工作是开发优秀的软件并了解这样做的优秀技术。管理层的工作是了解更大范围的问题和可能超出您权限范围的业务注意事项。即使您是对的并且他们对业务考虑的内容是错误的（您对缺乏创新，延迟交付，客户投诉等的担忧），了解管理的来源也将有助于您以其术语进行交流，缓解他们的担忧，等等。

第三（及相关），确保您会说商务语言。企业（正确地）不直接与良好的软件开发实践相关；企业关心的是服务客户的需求并获利。（而且，许多企业显然会竭尽所能，以最低限度的服务来获取利润。）如果您能够解释不良的软件开发实践和缺乏创新会如何损害公司的利润或长期发展，那么您将更有效地促进变革。健康。

第四，从普通工人的职位改变公司文化非常困难。詹姆斯·肖尔（詹姆斯·肖尔）（敏捷顾问兼作家）写了《变革日记》，描述了他自己为此所做的努力。我强烈建议您阅读整个内容。相关几点：

• 不要试图立即更改所有内容。找到最大的痛点，然后从那里开始。通过帮助所有人了解您的更改如何解决这些痛点，使所有人参与其中。
• 了解他人的观点。Shore从软件开发的角度讨论了他正在推动的更改如何受到项目经理的抵制，因为他（Shore）未能考虑更改将如何影响项目经理。
• 最终，你会需要一些从上更高的支持，即使你促使大多数的改变自己。肖尔谈到了他的冠军（“与我一起工作的人，比我更有影响力，并以与我大致相同的思路思考”）。

显而易见的简短答案是离开公司。其他人已经离开了，您的经理是前进的积极障碍。如果您停留在该位置，您将逐渐衰落（士气和技能）。寻找新工作并不总是那么容易，但在这种情况下，这是必要的。

以防万一您选择不离开公司（问题的第一行就这样说了）：

你的经理有老板吗？如果是这样，那位老板如何看待产品？您能（甚至敢说吗？）越过您的经理的头并接近他的老板？不要对技术细节na之以鼻，只是表达对公司发展的兴趣和热情。提出切实可行的改进想法，这些想法会显着影响利润。您可能会从障碍中升职。

不过请注意-一些吱吱作响的车轮被涂上油脂，而另一些则被更换。您将导致您的经理强烈不喜欢您。他将听到有关此事的消息，并会向老板说关于您的不友好的话。小心行走，但要记住-没有风险，没有回报。

可能发生的最坏情况是您将寻找一份新工作，无论如何您都应该这样做。

听起来像是时候该去了解摇钱树了。去这里和这里。看看增长份额矩阵。GSM提供了一些其他信息，说明为什么摇钱树是一个好状态。

在这种情况下，Investopedia（第二个链接）可能具有最佳报价。

1. 摇钱树需要很少的投资资金，并且常年提供正现金流量，可以分配给公司内的其他部门。这些现金产生者也可能会用他们的钱回购市场上的股票或向股东支付股息。

正如您所指出的，现金摇牛项目有一些好处。

• 很稳定
• 保证适度的新发展
• 解决问题总是存在错误修复工作。

正如您还指出的那样，这些项目有一些缺点。

• 它很稳定并且代码库没有太多变化
• 新技术通常被忽略（太昂贵而无法依靠）
• 事情变得……陈旧。

我曾经从事过一个项目，在这个项目中，我收到了许多与您提出的类似投诉。我清楚地记得当时与老板分享了我对代码库的担忧。他的见解并不是特别有启发性，因此我不会分享。但是我坚持了这个项目，说实话，这是我见过的更好的项目之一。不，它并不浮华。是的，我们错过了最后期限。是的，我从那里rack了几场死亡行军。不，代码技术并不是全部具有创新性，但是我们确实提供了一些令人惊奇的解决方案。

问题是我。我没有足够的视角来理解代码库生存的真正要求。我没有经验去了解创新真正在哪里发生。我不了解决定该现金牛项目的适当资金水平的市场基本面。

我鼓励您将其视为学习的机会，以更好地了解业务的运作方式以及如何提高产品适应业务需求的技能。尽管工作可能并不浮华，但学习潜力却很高，这些技能将在您的职业生涯中为您提供良好的支持。公司级开发的大部分围绕您刚才提到的所有约束而进行。代码很臭；一切都准备妥当，以包含已经逃脱的最后期限；许多开发人员抵制变化。

在某些时候，您仍将继续进行该项目。您可以带走的课程可以成为真正的职业课程。

您的经理可能抵制变革，因为他认为没有（业务）价值在改变实践。该业务没有真正的问题，因为开发团队的任何要求最终都能解决，客户的抱怨也不会传递给关心和/或可以做些事情以确保取得更好结果的人员。要么，要么企业已经开始不可避免地接受当前的事务状态。

如果要更改开发实践，则需要向他们证明当前的状况并非不可避免。而且，您将要听到的唯一方法是建立一个业务案例，以显示当前事务状态如何增加产品成本并在给定另一种事务状态的情况下保留潜在的收入。

要构建该业务案例，您需要与该软件的产品经理联系。产品经理是根据项目所代表的业务价值决定要开发项目的优先级的人。产品经理应该（应该）看到能够更快地构建更好的软件的好处和商业价值。（我希望这与负责开发团队的人不同。）

业务案例需要解决以下方面对业务收入的影响：

• 尚未（尚未实施）的功能将在实施时产生更多的客户或保留更多的客户。
• 实施不充分的功能会引起客户不满并导致客户流失。

该业务案例还需要说明当前的开发实践如何影响开发急需功能的速度和成本：

• 进行最简单的更改需要多长时间。
• 由于开发新功能而引入的错误有多少，包括新功能以及其他功能的附带损害。
• 修复这些不能花费在实现新功能上的错误需要花费多少时间。
• 由于这些错误，产生了多少个支持电话，以及员工需要在这些电话上花费多少支持。

当然，需要表明采用更好的开发实践将如何影响这些数字。

您可能正面临对软件（主要）部分的（主要）重写的需求。即使您不这样做，如何进行这类项目也必须阅读如何在不失去理智的情况下进行彻底的重写。

最后说明：如果产品经理对这一切都不感兴趣，那您就迷路了：跳船。

我认为这是一个非常棘手的问题，没有直接解决方案。以下是您可以尝试做的一些想法：

对变革的恐惧 关于使事情变得更好的话题，我明白了为什么管理层担心会改变。人们习惯于某种方式的事情，如果您更改它，用户将会反抗（也许）。变革是一件令人恐惧的事情，通常需要大量的思想和研究才能完成。您需要的数据是证明它更好并且用户想要它。说到gmail，您可能会考虑做类似“ Google实验室”的事情，您可以在其中启用/禁用新功能，以便用户可以尝试一下。然后围绕此收集一些数据，以帮助备份您的更改。

改变软件开发流程 再次改变是很难的，人们不仅会改变，因为您说有更好的方法。我认为在这种情况下，我最好的建议是以身作则。以您希望他们完成的方式做事，并向人们展示它有多好。另外，这是关键，您需要找到其他分享您想法的人。如果您可以请一些人加入，对您的事业大有帮助。一旦可以显示出一些结果，就可以与管理层联系以扩大这些更改。我发现自上而下和基层的努力确实有助于做出改变。

在工具方面，公司也担心升级/更改这些工具，因为它们要花钱，而且新工具的结果并非总是可衡量的。我的建议是制作自己的工具。如果您自己创造，将节省时间并做得更好。希望人们的意愿开始引起注意，然后也想使用它们。

改变管理方式 这很困难，除了成为一个能产生成果并获得他们的见解的人外，我不知道该怎么做。一旦您的意见得到重视，人们可能会开始倾听，也可能不会。

最后要记住，改变是困难的，需要时间。挂在那里，从小处做起。