与僵化的程序员打交道

有时，长时间在项目上工作的程序员会变得僵硬，因此很难与他们进行推理。即使我们设法说服他们，他们也不太可能执行我们的建议。

例如，我最近加入了一个项目，该项目的构建和发布过程过于复杂并且有不必要的障碍。

我建议我们仅通过集成缺陷管理和版本控制工具（这都是IBM-Rational工具，从而可以很容易地一次性完成）来摆脱一些开发开销（例如填充一些电子表格）。另外，如果我们使用Maven和Ant之类的工具（该项目涉及Java和某些COTS产品），则可以简化构建和发布，从而减少人工错误和干预。

我设法说服了其他人，并准备投入精力来开发概念证明。但是“高级”开发人员并不愿意，可能是因为当前的流程使他变得更有价值。

我们如何在不增加团队摩擦的情况下应对这种情况？

您是新的团队成员，并且想要更改团队工作方式的一些基本方面。祝您好运，我感觉到您未来的团队会很幸福。

好的，一些实用建议：

向团队证明自己。 您需要从技术和可靠性的角度进行此操作。如果您想让人们关注您，则需要给他们理由。

了解方法论的历史。 为什么存在？当时正在解决什么问题？确保您的解决方案确实为团队带来了好处。也许您的更改会更好，但实际上可能无法解决团队遇到的问题。

了解您的障碍。 找出他们抵制的原因，并在这些项目上开展工作。

如果您想成为变革的推动者，请学习如何成为成功的变革推动者。数十本书籍和其他资源可为您提供的信息远远超出这里的范围。

而且，是的，我祝你好运。但是，为了您的幸福和团队的幸福，请多加注意。您想要进行流程更改而又不花费精力来构建正确路径的愿望，弊大于利。

我一直在你提到的位置。我以Java开发人员的身份工作了数年，最终从事他们都使用Smalltalk的工作。我的第一个反应是“ OMG，他们正在使用这种过时的技术”，我开始尝试使用Java解决方案解决Smalltalk特定的问题。我只能想象我对其他开发人员一定感到头疼，他们对Java充满热情。

直到几个月后，当我得到一个中等规模的项目进行工作时，我受到两名高级开发人员的指导，我才开始了解Smalltalk语言并学会了喜欢它。自从离开Job并重新进行Java开发以来，我感到更加灵活，因为我可以采用一个项目并以公司使用的任何语言来实现它。使这些人理解的核心是语言不过是中介。我也花了一些时间自学Lisp和Erlang，但这可能并不适合所有人。

作为团队建设的策略，我会向遇到困难的人推荐“ 七周之七种语言”。

我想这还取决于这些人愿意花多少时间来变得更加灵活。大多数大学（至少是我所见过的大学）的麻烦在于，他们偏向于一种特定的语言，正如您所提到的，它的学生变得“制度化”。我认为您策略的一部分应该是培养团队的灵活性。这可以通过域驱动开发来补充。

（1）为一个领域建模（一个简单的领域）（2）使用两种不同的语言（即Java和Lisp）实现它

同样，这是基于他们有动力进行上述工作并愿意花费自己的时间来实现这一目标的假设。

希望这可以帮助

我在这里可能走错了路，但是在我看来，同样的问题在更广泛的范围内很常见，并且与人类保守主义有关。人们经常拒绝更改众所周知的行为模式，原因不胜枚举。

作为一名俄罗斯开发人员（因此很少看到理性的西方实用主义），我认为实用的推理要比尝试穿上别人的鞋子更具说服力。

换句话说，您提到高级程序员重视他自己与当前工作方案相关的职位。也许您应该说服他，新的做事方式将使他的职位更加有价值，并且有很多方法可以做到。例如，您可以让他实际发表您的想法并获得赞誉，或者您可以在此过程中找到他可以独占控制的特定位置等。

我相信，在您的想法的明显优势之外保持灵活性可能是您的魔术。

我设法说服了其他人，并准备投入精力来开发概念证明。但是“高级”开发人员并不愿意，可能是因为当前的流程使他变得更有价值。

与其对高级开发人员的性格（糟糕的举动）撒些小气，也许您应该尝试了解他为何不热情：

• 也许他认为您是那些推销他们想法的人之一。也许他怀疑您能否兑现它们。

• 也许他认为您正在夸大问题。（他们不能那么糟糕...）

• 也许他认为您没有完全掌握技术风险。

• 也许他认为（知道）现在还有更多重要的事情要做。

• 也许您只是用错误的方式摩擦了他。

我的建议是向他证明自己。就像通过交付实际得到的项目一样。当他更加信任您的能力和判断力时，请重新考虑此问题。

如果您确实想立即采用“流程改进”方针，那么我的建议是分步骤缓慢进行。

请记住，毫无疑问，您提议的更改会极大地影响小组的生产力，甚至影响他们维护现有软件的能力。如果发生这种情况，负责人可能会从高级管理人员那里得到最多的帮助。

制度化特别是什么？技术，模式，实践？

如果他们已经在组织/项目中工作了很长时间，那么他们很可能是高级开发人员，并且有责任/经验来打这些电话，并且在项目中有经验，而不仅仅是像5只猴子的实验那样受到限制。

说服他们的解决方案将取决于主题是什么，因为如果已经选择了一种模式/技术，那将是一个很好的理由，并且必须有一个更好的理由来进行改变以证明抛弃工作和重新改造等等。如果是这样的话，那么解决方案就是为建筑师/高级开发人员组织一次会议，以民主方式确定最佳解决方案。

如果团队确实有不必要的障碍，那么他们可能会很乐意让您帮助他们解决问题。但是请注意，可能有很好的理由让他们在那里，如果您在长时间向所有人推销之后不得不说“哦，好吧，我的奇妙主意不起作用”，您就会显得很愚蠢。

先调查一下，然后再提出。另请注意，能够展示您如何建议改进的方式比手动操作要好得多。

我倾向于说你是“不灵活的程序员”。您是该项目的新手，但是您坚持认为自己的想法是最好的，而领导该项目的那个人已经很久了，并且知道系统的内在和外在都在摇摇欲坠。

我经验丰富，受人尊敬，作为老虎团队成员，我经常被分配去解决困难的项目。即便如此，我仍然还是花时间学习团队的方式，原因，动态，项目及其实践，而不是一头雾水地告诉他们这是怎么回事。实际上，我从来没有说过他们在做什么是错误的，因为那并没有得到我想要的回应，通常他们在做什么是没有错的，只需要进行一些调整即可。

每个项目都是唯一的。每个团队都是独一无二的。您的解决方案可能对您和开发人员都更好，但对潜在客户，客户，业务或项目可能不一定更好，但是由于您没有与项目相关的经验来更好地了解，因此您不会知道答案。

让人们去做自己想做的最好的方法就是让他们认为一切都是他们的想法。因此，提出建议而不是直接提出建议。如果您的想法明显胜过其他选择，请给高级开发人员一个机会，将它们选出来并自己制作。不用担心获得信誉。重要的人会知道发生了什么事。