我是怎么管理团队的

博主: Simon Lin 创建于: May 2, 2019 更新于: May 2, 2019
分类: management
标签: management tech

我管理团队的小总结

有人问我,作为技术经理或者技术总监,最多管理过多少人?大约40人。那你是怎么管理技术团队的呢?这个……真的不是一句话能说清楚的。

今年37,从事研发工作十多年,技术管理也很多年,多到具体写简历的时候,管理经验多少年,真的算不过来。第二年工作的时候,就开始负责一个小团队。之后又有做项目经理负责管理项目。再然后开始带3-5人的小研发组,也有10个左右的敏捷团队,再扩张一直到40个人左右的研发。这40个人里,有研发,有测试。不在团队里,但需要合作的还有产品,UI,美工,还有业务方等等。

在我的经历里,对于短期的一个项目管理不算是纯粹的技术管理。这里我只想说一个技术团队的管理。这里我按照人数的多少区分不同的管理模式。

小组管理

5个人以下的研发,有时会有1个测试,这样的研发小组。这样的小组的管理职能我称之为小组长。小组长就是涉及到开发任务的所有细节都需要参与,问题都需要亲手解决,然后把简单的,程序化的东西派发给小组的其他初级角色。管理的功能其实不多,需要的只是找几个初级人员打下手,并保证初级人员的任务完成,不出问题,出了问题就要这个小组长来扛。

敏捷团队管理

敏捷团队与小组管理的最大不同在于角色。有需求方,有产品,有测试,有前端,有后端。基本的角色在敏捷小组里都是齐全的,一个敏捷小组可以到10个人左右。这个时候管理的角色称之为Scrum Master。作为这个Master,我的理解更多的是指导整个团队按照合理的流程进行开发,并充分的发挥团队各个成员的自身能动性,提升效率。Scrum Master在做敏捷管理的同时,也可以兼任小组管理里,小组长的角色,但不分配任务,只起辅助,问题跟踪解决,监管的作用。

小部门管理

当人更多的时候,一个小的敏捷团队超过15个人时,其实渐渐的就不敏捷了,因为沟通的路径指数级上升。作为一个技术管理者,这个时候会渐渐开始减少一线编程的工作,转而解决沟通效率的问题。道理很简单,15个人团队,如果10个人编程,每个人效率提升10%,就可以省出一个开发人员来,让这个开发人员专注的提升团队开发效率,而不需要他顶在一线。

这个阶段,我的理解是需要建立更小的更高效的小组。核心问题就是两个:如何分组?如何安排小组的管理者?

例如一个系统,我们划分成业务层和基础层,然后分成2个组。也可以分成前台,后台,分成2个组。分组的合理性,很大程度上决定了之后管理的复杂程度。假设把用户模块放在基础层,然后改一个相关的登录功能,有前端页面上的功能,需要业务层来改,也有数据变动,需要基础层来改。这样一个功能的变动,就涉及了2个开发小组的多组联合开发。如果很多功能都涉及这样的问题,不合理的分组造成多组间的频繁沟通,反而是造成沟通效率低下的重要原因。所以,分组这个事,其实是考验这个部门管理者的能力的很重要的一环。

而如何找到一个小组管理者,也是团队能否稳固的一个关键。一个小部门,至少需要找到2个靠谱的管理者,帮你管理。第一要充分的授权,第二要提供合适的帮助和指导。

大部门管理

团队超过20个人,也就是底下超过3个小组,会进入一个新的阶段,就是极速扩张的阶段。这个时候会碰到一个很经典的问题,人员的流动。如何进人?如何减人?

进人不是简单的找领导要人头,然后叫HR找人这么简单的。关于面试筛选,这里不做多说。作为管理者,更重要的是建立一个体系,让进来的人不容易流失,让进来的人更容易的产生绩效,更容易的融入团队。我称这个时候的管理为开发流程的管理。这些流程的管理,相关的事有,文档体系,代码管理提交的体系,技术选型,以老带新,鼓励分享等等。

文档体系是作为大部门管理者一个核心需要管理的事。产品文档,需求文档,开发文档(接口文档,设计文档,测试报告),配置清单等等,是技术部门除了实实在在的代码以外的最重要资产,一定要好好的管理起来。同时也是对于一个新进来的人最重要的培训资料。

代码管理等相关的技术规范,通过流程保证开发管理的质量,不会受个别人能力等其他因素影响。说一句其他的,管理其实只是管理平均线以下的人,要让他们提高,就是要建立规范,让他们照做。

技术选型,当然这个主要还是架构师的职责,但尽量选择最开源,受众最广,最稳定,而不是最新的技术等原则,是保证可以找到足够候选人,保证新来的人能快速上手,而不需要投入新的很多的学习成本的重要要素。

以老带新,鼓励分享等,建立起相关的技术文化,让进来的人更快的融入,也让技术人有更多成就感,自我实现等。

这里再说说,如何减人?

团队中一定有人表现相对较差,对于团队的发展来说,如果团队产生的绩效远远高于平均,即使最差的那个人,也是可以不裁的。可是如果团队绩效总体下降,或者总体绩效低,换血是有必要的。

关于裁人的经验,我其实也不多。只说几点:

  • 用更客观的绩效评定方式,选出绩效最差的人,尽量少的主观因素
  • 个别沟通,私下沟通,简单直接
  • 同理心,该补偿的补偿,该通融的尽量通融,好聚好散

小结

技术管理其实有许多细分话题可以说,这里只是简单说了一下,我对于一个最小的技术团队,到一个相对大一些技术部门管理的很多点。欢迎与我交流讨论


打赏 支付宝打赏 微信打赏

如果文章对你有帮助,欢迎点击上方按钮打赏作者