我应该如何管理具有不同技能水平的团队?


16

我将与我的一些朋友一起进行软件项目,并且被任命为技术主管。这些家伙根本都不是一个糟糕的程序员,但我确实比他们有更多的经验。我需要能够在团队中的每个人之间分配工作,同时还要确保我们不会互相踩脚。他们满足了使该项目成功所需的相对较高的质量和可伸缩性标准,而无需我审查他们所做的一切。

如何避免微管理的同时保持标准?是否足以制作一些图表,安排一些代码审阅并相信我将能够修复可能会破坏的所有内容,还是应该走TDD路线并编写明确的测试以使团队满意?


11
是否有一支具有相同技能水平的团队?
P.Brian.Mackey 2011年

@ P.Brian.Mackey:我的意思完全不同。
乔恩·普迪

@乔恩:我真的希望你知道自己正在做些什么。确保他们从一开始就拥有一些“猪肉”(!)。我隐约感觉到您需要在那里有很多经验的人,如果看起来他们甚至不能编写单元测试并且(!)还没有发现如何自己做的话:这会导致我想也许您是在夸大他们的技能。不用说,假设胜任的能力不是一种好的项目管理技术。
亨里克

@Henrik:我知道自己正在做些什么,我只是没有太多管理其他开发人员的经验,并且想就如何确保事情顺利进行获得一些建议。我对他们的能力充满信心,而且我认为人们对我的问题的否定性比我实际提出的要大得多。我刚刚从事编程已经超过了我一生的一半,所以我已经犯了很多错误,这些有2-3年经验的人还没有遇到过。
乔恩·普迪

是用于公司还是副项目?
Marcie

Answers:


10

您应该检查他们的一些代码,然后让他们互相检查。不是您想成为“签到警察”,而是想要尽可能频繁地提供反馈。成为审稿人可以加强他们的理解。让他们也查看您的代码。成为榜样。

旁注:年度审核期间不应有任何意外。


2
为“成为模特” +1。这是我在代码审查中看到的最大好处:从其他人的技巧中学习。那,并抓住偶尔的缺陷。
彼得·K。


9

最重要的是:以尽可能多的不同方式传达您的期望和设计。图对某些人有好处;定义的接口为他人工作;配对编程也可以;正式的代码审查也可以帮助某些人。

一世 建议尽可能使用自动化:

  • 让团队使用像NDepend这样的工具如果您位于.Net领域,或Resharper之。如果您不喜欢标准规则,请对其进行调整。
  • 尽可能实际地自动化测试。

如果测试用例或自动检查工具设置正确,则很难与它们争论。


3
不好的程序员可能会设置不好的测试用例?
JeffO

1
像Resharper这样的工具都是def。整洁,但肯定不是免费的。自动化测试需要编写可测试的代码,如果他们的技能水平无法与标准相提并论,那么这可能是不切实际的要求。
P.Brian.Mackey 2011年

@Jeff:他们不是不好的程序员,我们只是有不同的背景,而我有多年的经验。如果有的话,我和最有经验的人可能正在编写测试。
乔恩·珀迪

@Jeff O:然后让他们离开团队。
彼得·K。

@ P.Brian.Mackey:问题中没有免费工具的规范。如果代码不可测试,请让他们脱离团队。尝试向他们展示如何编写可测试的代码,如果他们没有任何改善,请让他们离开团队。
彼得·K。

5

如果您确实在同一项目中使用多种技能,那么将会遇到一些问题。问题是您什么时候处理它们?他们会写这么糟糕的代码,如果没有他们的帮助,您可能会更好吗?这会造成个人紧张吗?你要结束友谊吗?这些问题只有您一个人无法回答。

假设每个人都留在团队中,我建议将任务分成小块(更大的部分分配给技术娴熟的家伙),并让最熟练的开发人员在完成任务后进行重构。确保定期进行质量检查。无论如何,这与现实情况非常接近。


3

尽可能远离杂草。在任何团队中,如果您是领导者,则需要为危机和大局节省一部分带宽。图表是好的,编码标准始终是明智的,但是建立人们检查彼此工作的过程甚至更好(交叉测试,同行评审,结对编程)。并非团队中的每个人都需要成为明星-团队在一起通常可以克服个人的任何弱点。

我建议您尽量抵制告诉别人您在编码中看到哪些错误的冲动-而是让他们自己看一下。保留对开发工作进行协作审查的一部分,但要确保您所做的贡献不比其他成员多。相反,要付出更多的努力来鼓励人们看到您所看到的内容,并对您所看到的内容为何重要的原因进行大量解释。

不必过多担心重叠-除了明智的工作分解之外,您可以要求团队成员进行相互检查,然后验证是否发生了沟通。团队将很快开始互相寻求意见,以达成共识,这使您的工作轻松了大约20倍-然后,您要做的就是在主要领域意见分歧时成为决胜局。

然后,省去集体看团队的精力。每个人都有一些很棒的优点和一些令人着迷的缺点。理想情况下,您将开始向适合自己优势的人员投入工作,同时仍给他们提供机会以不会削弱团队生产力的方式克服自己的劣势。

团队领导力的终极金星使人们意识到自己的弱点,以使其有足够的动力和足够的知识开始修复它们。


2

坐下来,讨论团队中每个人都同意的技术和工具。有些人可能比团队中的其他人更有经验,因此,那些经验丰富的人必须愿意并且愿意与其他人分享经验和知识。

讨论,同意,写下,建模和交流标准(例如命名约定,编码最佳实践和文件夹结构)。

进行连续的定期测试和质量检查。看到不一致之处时,请尽快通知此人。


2

我要说的是“请团队中最有经验的人来组织它”,但这听起来像是您就是那个人。

如果可以,请将项目分成两个级别。应用程序层/驱动程序层是很好的分离。在您的团队中形成两个小组,并在每个小组中让一个人负责该级别。那可以很好地工作。

辞职吧。您将必须审查他们所做的所有事情,尤其是在早期。如果一切进展顺利,您将只盯着代码。审核根本不会花费您太多时间,它会让您充满信心,一切都会好起来的。您更有可能会发现有人错误地使用了信号量,或者正在编写他们自己的版本的库函数或某些类似的疯狂行为。我的经验是,在编写代码时,您必须观察代码,以解决萌芽中的代码问题。


同意代码审查部分。您必须尽早指导他们。

2

贵公司通常期望技术负责人做什么?我是一名经理,已经去过这个地方几次,本周将再次做这件事(雇用新手和其他人加入由20年和4年经验的团队组成的团队)。

我是一名经理,可以担任技术主管(在过去的几年中,我淡化了后者的作用,以增强团队中的领导力。无论如何,有些想法:

  • 评估整个团队的技能和弱点。
  • 制定增长计划-当您的重点是培养最弱的成员时,您实际上应该专注于以个人和团队的方式发展每个人。
  • 传达该计划并设定每个人的期望。
  • 在团队中分配学习和验证。当您作为负责人时,我自己占工作的大部分,而分发工作将帮助您的高级团队成员成为领导者。
  • 创建一个常规的反馈循环。与团队成员会面以评估进度并提供反馈。
  • 根据需要调整计划以确保成功。
  • 如果有人没有锻炼,即使有合理的帮助,也不会准备将他们推出。这很复杂,但是如果您制定了计划,期望并提供了反馈循环,那么您将处在一个更好的位置。
  • 密切注意团队士气。这种情况可以使团队成长或瓦解团队做出巨大贡献。您的领导才能和对团队的投入对确定结果将大有帮助。

1

尝试研究定义“软件体系结构”的内容。创建可单独开发的模块是进行前期设计和分析的主要原因之一。我知道进行这种类型的工作是过时的,但是它在所有情况下都可以工作,而不是新的开发方法支持的某些情况。


1

作为团队中经验最丰富的开发人员,我希望您能给予大量指导

让团队使用看板将工作分配给自己,然后花费整天的时间与他们每个人进行配对编程

当您发现不良习惯或他们应该(所有)要注意的事情时,停止一切并在白板上画画。

几周后,随着团队的整体技能逐渐接近您,您将能够放慢沉重的指导。


1

我很想从您的职位中查看几个不同的清单:

  1. 我对这支球队有多了解。您知道团队中每个人的优点和缺点吗?您知道如何从每个人中获得最大收益吗?您是否知道如何以相对公平的方式将工作分配给所有人?这些问题是要问和要理解的,因为有些人可能会发展一些技能,这些技能可能会改变他们的观看方式,所以这些列表可能会随着时间的推移而发生变化。当您被任命时,您是否期望团队中有人拥有您?最后一个问题可能很难使人们诚实地回答,但是如果可以以有意义的方式公开和讨论该问题而又不会激起冒犯或不满,这将大有帮助,如果所讨论的内容对某些人而言非常个人化,这很容易人。不要试图在小组会议上征求个人意见,

  2. 我对自己有多了解。您正在使用什么背景知识来要求某种技术授权?您带给团队哪些优势和劣势?您是否希望定期进入战es?您是否已经想过向您介绍该团队以帮助指导他们的做法?您是否有从过去的经验中记住的警告信号,这些信号可能对了解团队中正在进行的工作中是否开始出现这些警告信号有用。

在某种程度上,这一切都归结为沟通。祝好运!


0

定期(每周)介绍一些技术主题,并使其围绕小组进行轮换。这样,每个人都会学到一些东西。而且,让年轻的成员也出席会议,没有比通过教导来真正理解某事的更好的方法。您可能需要帮助他们选择主题。

一些指导如何演讲的指导可能是为了每个人。我在大学里有一位教授为我做了这件事,这非常有帮助。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.