如何组建开发团队


22

我是一个由11位软件开发人员组成的团队的经理,他们负责管理我公司的网站/ Web应用程序,并随时运行多达4个并发项目以及日常支持。在11位开发人员中,技术技能,职称和经验混合在一起,尽管团队结构是平坦的,所有11位开发人员都直接向我报告。

整个团队只有一名经理,现在开始证明扩展性不是很好。我的传播范围太窄了,因此想减少直接报告的数量。我认为实现此目标的所有方式都有很大的缺点:

  • 让初级开发人员向高级开发人员报告。这样可以减少最佳技术人员在开发上花费的时间。
  • 按软件产品划分团队,例如,开发人员1-6在Intranet上工作,而7-11在外部站点上工作,每个部分都有新的团队负责人(可能是新职位描述,与当前的高级开发人员相比,具有更多的管理/指导/指导职责) )。这增加了人为的孤岛,并且如果我希望他们这样做的话,可能会很难使“内部网开发人员”在外部网站上工作。
  • 保持结构平坦,以项目经理/团队管理员的身份添加管理支持,以减轻压力。这不能解决问题,因为团队无法永远这样成长。

有没有解决我所缺少的这个问题的标准方法?

如果没有,你们中的其他人如何解决了这个问题?


2
您现在如何与报告互动?是技术,行政还是混合?如果混合使用,那么每种时间花费的时间百分比是多少?
Telastyn 2012年

50/50的行政和技术组合。
尼克

这是特定于编程的吗?我想知道这个问题是否可以在Workplace.se上得到更好的答案
Daenyth 2012年

Answers:


16

一些简单的想法:

  • 子团队是一个好主意:11个没有任何结构的直接报告对于一个可行的团队来说太大了(您将没有足够的时间进行直接指导,与许多人进行的团队会议往往会徒劳无功)。
  • 考虑将运营与开发分开-这是一个稍有不同的技能,整日被运营问题打断会严重损害项目的开发生产力。
  • 由于前两点,我认为您应该有3个子团队-Intranet,外部站点和运营。运营人员将处理所有日常问题/维护修复等,而两个开发团队则专注于为业务交付新项目/价值。
  • 定期在团队之间循环人员。对于项目而言,这可能是偶然的(例如,让人们去审核另一个小组的代码),也可能是永久的。但是请确保理解,只要有业务需要,团队角色就会发生变化-没有人永远“拥有”特定的角色。
  • 不要添加更多的经理/管理员-这是确保降低团队整体效率/生产力的可靠方法。让每个小组中最有经验的人扮演团队负责人/教练的角色。确保他们在这里扮演的角色是指导和使整个团队成功,并确保他们具备以这种方式行事的能力,而不是充当“任务管理器”的角色。
  • 您的角色应侧重于外部利益相关者管理,优先考虑小组内的资源/任务,并担任“总教练”。您需要处理子团队偶尔出现的问题,但总的来说,您应该鼓励他们自己解决问题,而无需您亲自来解决。
  • 如果您自己是高技术的,您还可以选择扮演建筑师/设计保证的角色。如果没有,请在团队内部或其他地方找到可以的人。

此外,值得一读并重新阅读《敏捷宣言》,尤其是十二项原则


7
每次我在某个地方工作时,他们都会将生产支持与发展分开,这是一个巨大的灾难。如果人们不支持自己开发的东西,他们将永远不会学到哪里出了问题,再加上开发人员的支持,他们最终陷入了无法逃脱的贫民窟。
HLGEM 2012年

3
@HLGEM-绝对是,所以这就是为什么需要人才到处循环。...让人们以各种方式为他们自己的产品提供实时支持,但不能同时开发3.0版本。另外,您可能有一个或两个不是开发人员且要执行不同任务的运维人员,因此为运维使用不同的团队结构/工作模型可能很有意义。YMMV当然。
mikera

9
以我的经验,他们总是承诺会带人到处走动,但他们不会,YMMV。部分原因是原本分配给开发人员的人员不希望获得支持。
HLGEM 2012年

4

该结构将主要 depend on project specifications

理想情况下,团队中每个高级开发人员应有3个初级人员。因此,每位指导老师有2-3位高级开发人员。

因此,只有技术负责人才能向PM报告项目的进度状态。所描述的结构仍然假设,对于非技术性问题(休假,休息,冲突等),每个人都可以访问PM。

我参与的相对成功的软件开发团队之一是按项目进行如下工作的:

其他人直接向其报告的软件开发经理/高级开发人员/指导者。

  • 一个项目经理,他保持进度表,促进需求和验收谈判,并进行沟通。每个人的虚线也向此人报告。文档人员(偶尔也是PM,但仅在允许专业知识的情况下)。
  • 1-3个开发人员或高级开发人员的组合,具体取决于项目的需求。
  • 初级开发人员(如果有)。
  • 从质量检查人员池中分配的人。
  • 基础结构人员(该角色通常由经理执行,因为他也具有扎实的SA能力)。

它运行得很好,我喜欢那个组织。另一方面,我是软件开发经理,团队的组织结构也在不断发展。


2

考虑遵循职能人员组织模式。这将表明您选择按软件产品划分团队的第二种选择。

在您的上下文中引用该文章:

职能组织的最大优势在于它将社会结构与商业价值的交付联系在一起。在我看来,软件项目的成功与提高支持的活动的有效性一样,产生了商业价值。通过以相同的方式组织团队,您将拥有一个使他们的业务用户满意的团队。

除此之外,实际的管理/人力资源结构无关紧要。


0

有没有解决我所缺少的这个问题的标准方法?

并不是的。这将取决于您的团队,您,需要完成的工作以及公司为您提供的资源。

就个人而言,最好的转换是将技术管理与行政管理分开。很少有人会同时擅长于两者,而且他们很少会互动。

一个人处理技术问题。需要做什么,谁去做,如何排列。另一个负责管理方面。审查,预算会议,产品计划等。然后,他们一起工作,从一侧传达见解,并提供统一的战线。

如何将其分解可以采取几种不同的方式。最常见的是让工程经理担任行政方面,而一名工程师则担任技术方面。他们是同行,并向董事/副总裁报告。

我看到的另一项工作是让工程经理担任行政人员,然后由团队负责人担任技术人员。这比较棘手,即使报告是分层的,也要求合适的人(大多数)充当同行。

对于您的特定情况,我建议您拥有2-3个小组,并由技术负责人来负责技术方面的工作,并且您应集中精力进行管理。是的,这可以节省实际编写代码的时间,但是(如果他们做得很好)他们应该(通过提高工作效率)提高初级开发人员的工作效率。它也为他们提供了更大的动力和实际晋升的成就感。在最实际的情况下,向管理层出售股份比开新职位要容易得多。

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.