如何领导一个由初级开发人员组成的团队？

Question

目前，我领导着一个由4名开发人员组成的团队，他们都是5-6个月前开始他们的职业生涯的。我可以认为自己是幸运的，因为我们已经被分配到一个绿地项目，这完全取决于我们实现业务目标。该公司本身规模很小，他们有很长的历史来维护遗留应用程序，而且它们远远没有跟上时代的步伐。这些情况导致了公司内部的某种程度的孤立。一开始我非常有动力，但几个月后，我开始感到精疲力竭。我的职位相当棘手:因为我们只有5个人，没有专门分配给项目的管理人员或业务团队，所以我主要负责处理这个项目。设计架构(并编写其中的很大一部分)，进行代码评审，组织待办事项，努力推动一切，并向管理层传达我们的进展。正如我提到的，我开始感到精疲力竭，感到沮丧。我真的无法得到任何帮助，甚至无法与别人进行技术讨论，而且我也不能现实地期望初级学生对我的决定提出质疑。

无论如何，我真正的问题是:我该如何处理这一切？我试图保持代码库尽可能干净，同时保持进度，这样项目就不会被关闭，但有时我觉得我接受的解决方案，否则，我不会，为了进步。这些问题听起来可能很愚蠢，但我相信你们中的一些人可能曾经经历过这样的问题:拒绝请求有多少次是可以的？我需要进行多少次培训，或者我的工作中有多少应该是编写文档，这样我就不是一个失败的地方了？我显然不希望任何人具体回答这个问题，相反，我想听听大家的意见。

Answer 1

你所有的问题都是相关的，正如你说的，你的团队还很年轻。如果我们在一起的话，我会问你你做了些什么来弥补他们的知识差距。我看到了几个危险信号：

• 你的发展是孤立的--这意味着公司里没有人被你的所作所为所支配。
• 你正在做大部分的进步，这是令人沮丧的。
• 你真的没有一个层级的人来帮你减轻负担

答案是一个难以下咽的药丸：

您将不得不接受代码中的一些混乱。

你的团队可能和你的项目一样绿色，但你可能处在一个过分强调原始代码的地方。人们无法在无菌环境中学习。他们会太害怕把事情搞砸了。如果你的团队太害怕搞砸了，因为你知道你会跟在他们后面，不管怎么说，这都会降低他们的积极性。

多少次可以拒绝拉请求？

这个轻率的回答是尽可能多次的。但现实生活却不一样。

• 确保您由于架构错误或危险而失败了拉请求。
• 当你请求失败时，让它成为一个训练的时刻。
• 帮助团队成员了解哪些漏洞是什么，或者它如何损害代码。
• 帮助他们从一开始就了解如何避免这个问题
• 让他们做些改变。如果你用勺子喂他们该做什么，他们什么也学不到

我需要进行多少次培训，或者我的工作中有多少应该是编写文档，这样我就不是一个失败的地方了？

这很难回答。我发现，当你训练一个人时，你必须挑选一两件最重要的事情来关注。你必须平衡正反两方面的反馈。如果有人做得对，就告诉他们。它将有助于加强良好的行为。

让您的团队参与设计决策。他们可能不够熟练，无法从一张白纸上设计出这个设计，但他们肯定可以帮助您的团队根据自己的技能进行设计，而不是与他们作对。

把文件保存在为什么脸？！(WTF)时刻。换句话说，当您有一个令人惊讶的需求，或偏离设计标准，记录它。此外，记录概念设计是什么。只够和你的团队沟通。

你越鼓励你的团队掌控他们的工作，他们就越能迎接挑战。如果有人不这样做，那么你可以考虑和管理层谈谈如何改变这个团队成员。

Answer 2

虽然我想给你一个建议，但我相信你没有什么可以做的。如果你向管理层传达了这个问题，而管理层不愿意(或无法)帮助你，那么你成功的机会就很小了。

我相信像这样的问题在团队或技术层面上往往没有解决方案。只有管理层才能真正解决这些问题。可能的办法是增加更多以人为中心的人来帮助指导和指导初中生。也可能是通过减轻价值交付的压力，允许初中生失败，学习并重新做已经做好但效果不佳的工作。

让管理层接受这些条款往往涉及到政治，你显然不愿意、不能或没有动力参与其中。

Answer 3

绿地项目可以是伟大的，但对于一个年轻的开发团队，它可能是挑战和压力。这听起来是个非常困难的情况。

有两个问题是很好的讨论要点：

多少次可以拒绝拉请求？

团队需要拥有并致力于质量过程。试着建立一个关于质量的共识--每个人都看到了拥有高质量的设计和代码的价值吗？如果不是那样的话，坦白地说，你每天都在战斗，把岩石推上山，这不值得。

更好的办法是共同理解(a)为什么质量是重要的，以及(b)期望或要求什么程度的质量。当期望是明确的，人们理解他们的目标，那么你可以更容易地指导朝着这个目标。

期望获得完美的代码是不合理的(就好像有这样的代码一样)，但是有一些标准是完全合理的。与团队会面并就这些标准达成一致。它需要的是团队的标准，而不是你的标准。确保团队的其他成员正在帮助执行这些标准。帮助团队想出一个解决反复出现的公关问题的解决方案，例如：(a)一对用于“重症监护”以解决问题的编程会议，(b)一次群体学习/小组编程会议，或(c)围绕团队质量期望进行的讨论等。

尝试这些东西，并定期“检查和调整”。这将是一个不断发展的过程，随着团队对质量的理解、承诺和经验的提高而发生变化。

我需要进行多少次培训，或者我的工作中有多少应该是编写文档，这样我就不是一个失败的地方了？

你应该100%可以让别人跟上你的步伐。您的首要责任是避免成为单一的失败点(或瓶颈)。

请注意，编写文档可能有帮助，但可能没有帮助。团队需要和想要什么？他们想要集体指导还是一对一的指导？像配对和聚众这样的方法会有帮助吗？

你希望尽可能多地委托他人，让人们犯错，但要尽快提供反馈和课程纠正(即经常的评论)。鼓励人们的机智和学习这些东西的能力是很重要的。