轮换开发人员是一个好主意还是坏主意？

我正在一个小型团队中工作，该团队将开始与另一个小型团队一起进行一个新的大型项目。另一个团队目前正在研究他们已经使用了多年的遗留系统。

经理已决定，我们团队中的开发人员将每隔几个月轮换一次，以替换在旧系统上工作的开发人员。这样，其他团队将有机会从事新项目并更好地理解新系统。

我想知道每2-3个月从项目中轮换开发人员的利弊（如果有）。

我知道这与“轮换首席开发人员是个好主意还是坏主意？”类似的问题。，但是这个问题集中在主要开发人员上。这个问题是关于整个团队轮流上线和下线的（新项目的技术负责人可能会也可能不会轮换-我还不知道）。

我很惊讶每个人都认为这是一件好事。Peopleware的作者（IMO，仍然是少数几本真正值得一读的软件项目管理书籍之一）非常不同意。本书几乎整个第四部分都专门针对此问题。

软件团队是一个非常重要的功能部门。团队需要果冻才能真正发挥作用。团队成员需要时间（很多时间）来赢得彼此的尊重，学习彼此的习惯，怪癖以及优缺点。

当然，从个人经验来看，我可以说，与某些人一起工作了一年之后，我学会了嘲笑某些使我烦恼的事情，我对团队领导的估计要好得多，并且要完成该任务并不难分发工作，使每个人都开心。一开始不是那样的。

现在您可能会说：“哦，但是我们并没有分散整个团队，只是移动了几个人。” 但是，请考虑（a）他们的替换将在一开始就盲目地徒劳无功，以及（b）您会发现自己或其他团队多少次甚至没有想过“我真的很喜欢X”或“ Y仍然在身边变得更加容易”，潜移默化地冒犯了新成员，并在现有团队中造成分裂，甚至在“老”成员中引起了不满。

人们当然不是故意这样做的，但是它几乎每次都会发生。人们没有思考就这样做。如果他们强迫自己不这样做，他们最终会更加专注于这个问题，并且对强迫的沉默感到沮丧。团队甚至子团队将产生协同作用，而当您拧紧结构时，协同作用就会丢失。该人件作者称它为“teamicide”的形式。

话虽如此，即使轮换团队成员是一种可怕的做法，轮换团队本身也很好。尽管运作良好的软件公司应该具有某种产品所有权的概念，但只要团队实际上能够完成旧项目或至少将其投入到项目中，将整个团队移至另一个项目对团队的破坏就不会那么大。他们满意的水平。

通过拥有团队职位而不是开发人员职位，您将获得与轮换开发人员所期望的所有相同收益（文档编制，“异花授粉”等），而每个团队作为一个整体都不会产生任何讨厌的副作用。对于那些不太了解管理的人来说，这似乎效率较低，但请放心，通过拆分团队而损失的生产力完全使将团队转移到其他项目而损失的生产力相形见war。

PS在你的注脚你提到的技术领导可能是唯一的人不被旋转。这几乎可以保证将两个团队搞混。技术负责人是领导者，而不是经理，他（她）必须赢得团队的尊重，而不仅仅是高层管理人员的授权。将整个团队置于一个从未与他们合作过的新领导的领导之下，这些新领导很可能对架构，可用性，代码组织，估计等事物有不同的想法……好吧，这真是令人头疼对于试图建立公信力的领导者而言，这对于缺乏旧领导者而开始失去凝聚力的团队成员而言。有时公司有要做到这一点，即如果领导者辞职或晋升，但凭选择去做听起来很疯狂。

我本人在这方面没有看到太多缺点。轮换让您：

• 机构知识的交叉授粉-至少在理论上，每个人都将了解旧项目和新项目。
• 交叉培训-不同的项目经常需要不同的东西。作为从事丑陋，遗留项目的开发人员，您的成长要比在干净整洁的未开发项目中增长得多。
• 从根本上来说更好的项目-就像有一个新团队来让您完成文档并清理您愿意忍受但不公开承认的丑陋流程一样。
• 更好的代码-在大多数情况下，更多的头脑更好。
• 可能提高士气-多样性是生活的乐趣。谁希望永久地停留在旧项目错误修复/风道录音模式下。另外请记住，您的“新”项目将在某个时候成为遗产，您是否想永远留在那儿？

唯一的缺点可能是您因换岗而导致的生产率下降，但这只会在第一次尝试时带来不利影响。之后，双方将在两个地方都有一定的坐席时间，交接中的丑陋部分可能会更好地理解和解决。

有趣的是，根据我的经验，我们经常出于这个目的开始我们的项目。一直以来，由于对新项目的限制以及交叉培训的成本过高，我们经常无法按照此意图采取行动。

我一直希望我们能对它进行管理，因为从长期来看，我认为它对所有人，团队，公司，客户和软件都有利。2/3个月的时间听起来足够长，任何严重负面影响的风险都很小，对于所涉及的开发人员而言，没有上下文切换，只是在转换点，他们可以专注于替代项目。

未提及的一些可能的好处：

• 更好的项目管理。如果两个项目的项目经理都参与其中，那么努力工作是他们的最大利益，这样过渡期对每个项目都不会造成痛苦。轮到您了（取决于您的设置），可以在PM和开发团队之间加强协作。
• 更好的（主动）文档。如果您知道自己要进入和退出某个项目，这不仅符合项目的最佳利益，也符合公司的最佳利益，总体上是最佳实践，而且现在每个开发人员都拥有最大的利益，可以在弹跳时轻松自如周围。
• 士气大不如前，如果您的开发人员没有足够留在旧项目中，那么他们可能就不是您想要的开发人员了！如果有的话，切换他们的位置并让其他开发人员进行工作会使他们感到对您公司的热爱-他们可能会整理一些他们认为没人能看到的代码。旧版系统通常被视为二等项目，这通常会对他们造成损害，也许您可​​以通过这种方式来帮助改变这种看法。

轮换对公司来说是一件好事，对开发人员也可能是一件好事。

有很多充分的理由，怀亚特（Wyatt）在回答中提到了许多理由。

话虽如此，在您遇到的情况下，您可能会发现，在将新项目移至旧项目时，开发人员可能会感到不满意，因此需要非常明确的沟通，说明为什么会发生这种情况以及持续多长时间是针对的，并且该计划仍在继续。

考虑不要交换团队开始工作，而要轮换1或2个开发人员，这也许是个好主意，尽管这看起来像是挑出人来降级（有些人可能会看到）。

同意Aaronaught的观点是很奇怪的，因为看到有多少人没有看到不利之处。.很少有人认为，您可以非常快速地指出-代码没有所有者，而当每个人都对所有事情负责时，质量就没有那么好。开发人员不是资源（即使经理经常这样称呼他们），他们是人，对于团队来说，彼此了解非常重要，轮换在这里会造成一些混乱。如果您在某个项目中工作更长的时间，您将成为专家（不仅是领域专家，而且是该项目专家），您将知道大多数麻烦来自何处，谁将为您提供最佳答案，或者也许是一些更具体的领域知识等等。如果您是新手，则需要学习所有这些想法，这样会减慢进度。当然，了解您组织中的其他做法也很不错，其他团队如何建立和组织。如果您的项目以某种方式相关，则特别好，例如，一个项目被输入到另一个项目中（不需要直接输入），这样可以更好地理解全局。当然，传播专业知识是好的（如果您有时间获得这些知识的话）。

我同意Aaronaught的最高答案，我还有一些补充。

• 人们不喜欢被推挤。
• 在分层业务环境中，可以为人员分配职责，这些职责随后又被带走。这可能只是工作的一部分。但是，这种情况发生的次数越多，这些人对分配给他们的任何东西承担责任的可能性就越小。
• 前一点也适用于人们自己没有创造的东西的维护工作。清理他人的混乱局面（或更简单地说是未完成的工作）对大多数创造个人而言并不是特别的动机。
• “程序员是程序员，是程序员，他们是根据需要插入项目中的匿名插件”的理念不会使任何程序员感到赞赏或更关心分配给他的任务。

重新分配任何人的最佳时机是当他们开始对自己的工作感到无聊时。没有什么可以收获的，一切都在控制之下，工作已经完成。在这些情况下，他们通常会挺身而出并要求其他机会。

当然，现实是固执的，通常没有选择，由于任何原因，可能需要在其他地方找人。这并不一定是坏事，它还可以使一个人感到重要，如果这个人要解决某个大问题，对他来说将是值得的。

只是在周围的人们之间改组以传播知识可能会增加营业额。这样，知识将被传播，但是将被传播到公司外部，这可能不是目的。

TL; DR 使其成为一个团队，然后由一个团队支持2个项目。

要回应@Aaronaught，我认为混合团队可能会遇到问题，因为适应新的实践，流程等可能会花费一些时间。如果您轮岗的人过多，团队很快就会失去其身份。这导致更多的问题，困惑和花费时间来弥补这一身份。

另一方面，如果大家齐心协力将2个团队合并为一个团队，并有1个团队支持2个项目，那么我认为，只要团队规模不太大，效果很好。我参与了许多支持多个项目的团队。两个项目的技术越接近，过渡就越容易。以我的经验，跨语言，客户端/服务器（尤其是GUI），行业（医疗，网络，游戏）或其他类似的项目，从一个项目过渡到另一个项目会产生更高的成本。诀窍是让不同的人经常在项目上工作以获得足够的收益，但又不要经常使过渡成本超过收益。

这样一来，吸引更多人参与一个项目所带来的好处以及成本都是众所周知的。

从公司和开发人员的角度来看，轮换程序员都是一件好事。

从公司的角度

1. 管理人员将了解特定开发人员的强项和弱项，他们是否可以处理多任务并适应变化。
2. 如果某个开发人员出于某种原因离开公司，则公司已经为将来准备了备份。
3. 随着许多人的参与，它将提高项目的性能，并且越来越多的开发人员对它进行测试。（最小化测试资源浪费）
4. 所有团队成员都在团队中工作，这将提高项目的绩效，并且在将来的管理中将了解，在实施困难的模块或任务时需要组成什么样的团队。

从开发人员的角度

1. 随着开发人员的信心增强，它将使开发人员更加积极。
2. 开发人员从其他队友代码中获得越来越多的创意，他们可以在未来的开发中使用这些技术。
3. 通过来自其他团队成员的更好的想法和建议，开发人员的生产率得以提高。

只有一件事，需要牢记，

程序员的轮换不应该经常发生。在完成60％-70％的开发后，只有转移才是有益的。