……这如何影响个人或职业成长呢？我不想为那种坚持让我在公司里永远只做最初几个项目的人工作……要认真对待这一点，内部人员流动（即使只是有人被提升到管理岗位，或者在原项目的小部分领域专精，或者当他们感到无聊时换项目）几乎和外部流动一样 costly。五年、十年后，他们的领域知识对现在每天在代码上工作的人员还有多少相关性呢？如果他们已经脱离了团队，提出过时的建议，这可能会造成伤害！假设并期望你的员工会一直待在同样的职位上，这似乎是导致人员流动的一个巨大原因。
源讨论构建理论以及为什么员工流动对软件公司是致命的原帖 420 条评论 · 导入时统计把你的经验，加入这段讨论。
我并不完全同意文中观点，但它确实提到了与参与该项目的人合作，并可以分享其中的理论。在这种情况下，会雇佣一名新开发人员，然后将系统的全部知识传授给新员工。当你培训他们足够之后，你就可以离开。新开发人员会适应并创造新的理论和解决方案。重复这个过程。
完整原文> 这对个人或职业成长有什么影响？我不想为一个经理工作，他坚持让我永远留在公司里最初参与的几个项目上... 通过记录你的工作和/或指导一名初级员工来传递你的经验知识。
完整原文雇主也不应该希望你这样。我认为最终这成为了一个支持良好文档和入职培训的论点，这样你就可以将“理论”传递给其他人。 如果能够很好地将新人融入团队，那么合理的人员流动是可以管理的。这实际上是我对转向远程办公的一个担忧。我知道很多文化上的适应以前是通过潜移默化和人们在一起工作完成的。我认为当我们都单独工作时，我们团队在保持这种适应性方面做得不够好。我们现在效率更高，但我认为我们还没有找到像以前那样分享和传递背景信息的好方法，我担心如果公司遇到一段动荡时期会发生什么。我担心我们的团队文化现在有点脆弱。
完整原文> 这和个人或职业成长如何相互作用呢？我不想为一个坚持让我永远留在公司最初几个项目上的经理工作... 对我来说，这是建立强大团队的巨大动力。任何人都不应该变得不可或缺；这对公司和个人都是不公平的。结对编程、集体代码所有权、有意识的交叉培训、良好的自动化测试、持续部署和良好的自动化监控对我来说在这一点上都非常有帮助。还有假期！每个人都应该休假很长时间，与外界断开联系。如果有必要，可以通过管理手段强制执行。
完整原文领导转去做了其他事情，每个人晋升一个职位，再招一个初级员工。根据需要重复这个过程。 或者：当人们随着发展而晋升时，即使他们在“同一职位”上，也要给他们加薪。
完整原文我曾参与一个项目，这个项目在赚钱，而另一个团队则有机会参与新的酷项目。 从这个项目中我学到的是，变得不可或缺真的很糟糕。这个教训在我的职业生涯中反复出现，无论是对我自己，还是当我变得更有智慧时，对其他人也是如此。 仅仅写出合理的、能工作的代码或对其进行文档记录是不够的，围绕维护可读的编辑历史的方面是无法衡量的，因此也没有得到足够的鼓励。我经常试图进入错误作者的思维，以了解他们为什么认为这是功能，以便在修复错误时保持功能。他们并不总是在场，而且他们并不总是容易沟通。如果你有历史记录，这个人就可以去从事其他事情。把它们赠予他们指导的人，或者以其他方式重新安置他们。如果你没有这些，如果所有内容都在他们的脑海中，他们就必须离开以摆脱这些。…
完整原文> 这和个体或职业成长如何相互作用呢？我不想为一个经理工作，他坚持让我永远留在公司里最初参与的几个项目上... 种一片花园，而不是一棵树。让我们区分“项目”和“系统”这两个词（不是“产品”——那是销售部门的术语）。我们把项目定义为一个在特定时间和范围内，用来创建或修改你负责的系统（你的花园）的努力。我认为把这两个概念混为一谈是一个常见的错误。如果项目无休止地拖延下去，那么员工确实会感到被困住。按照这个定义，我当然不希望永远只做一个项目。 那如果永远只做一个系统呢？问题在于，为了保持忙碌，你不得不把注意力强加在一个可能不需要关注的系统上。项目结束时，系统应该已经实现了它的目标，并且应该能 indefinitely（无限期）地持续下去。这个目标可能会...…
完整原文> 这和个体或职业成长如何相互作用呢？我不想为一个坚持让我在公司里永远只做最初几个项目而工作的经理工作... 第一个项目可能是个不好的例子，但如果换成“第n个项目”呢： - 不总是更换成员并不意味着从不更换，公司应该只是不希望你频繁地在项目之间跳来跳去（也许作为初级程序员除外），你也不应该希望这样，因为这样很难建立真正的深度专业知识（而是很多浅显的知识） - 如果你还在同一家公司，并且公司状况良好，那么在你换到其他项目后，有人问你之前项目的相关问题应该是可以接受的（只是作为“紧急情况”下的正常情况，而不是随意的） 问题在于软件行业中的职业发展和资历概念严重混乱…
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。