高效管理之团队梯度建设

2019年01月14日 18:37 阅读 370 企业管理 IT管理

    经常听人讲,我们要建设高效的团队,如何提高团队的执行效率等等,空谈效率没有意义,这篇文章结合作者自身的经历,谈谈梯度团队是什么样子的,为什么一个有梯度的团队是高效的,以及在管理中如何建设这样的团队。

梯度团队介绍

    下图是我经历的一家中型互联网公司的技术团队组织架构图,展现了在我离开这家公司之前的一个组织状态,首先介绍一下这个图的含义。

 这个图分成两大块,事业部和基础研发部。事业部就指的一个相对独立的业务线,不同的业务线之间有较大的差异,在业务上没有关联和延续。而基础研发部,是指的技术架构的基础设施,比如rpc框架、邮件与短信平台、消息中间件、异常监控等等,这些基础设施与业务之间通常没有太大的关系,更关注性能而剥离业务特点。

    接下来说事业部,一个事业部可以理解为一个大的业务线,例如天猫是一个业务线,支付宝是另一个业务线,菜鸟网络又是另外的业务线等等。这些业务线本身是由不同行业或领域的人组成的,切分成不同的事业部可以很好的理解。

    事业部之下,又可以分成多个小组,比如C端组、B端组等等,每个组选取一个小组长为总负责人,一般的title是技术经理或技术主管。这些小组之间不像业务部那样非常独立,小组之间虽然有很多不同,但也有一定的关联,例如C端的人员列表,可能会展示在B端的后台里,B端的企业列表也可以提供给C端的人员浏览,B端与C端可以建设一个渠道进行沟通,一些标签或分类同时适用于B端和C端两个方向的用户等等。

    小组之下就是人员分工了,我离开公司时已经基本完成了业务线的划分改造,将前端(FE),测试(QA)以及技术都交给技术经理管理,技术经理通常会管理2-8个人的开发,开发中有资深、高级、中级、初级人员。如果开发人员相对较少,可以由小组长直接管理,如果多于5个,一般就会选取一个“副手”,我们称之为memtor,让他分担一部分项目管理工作。

    UI池在这里单独成立一个组,没有被分担到事业部中去,主要是因为这时不仅业务端需要ui设计,有些市场部、公关宣传部、公众号等都需要UI,但需求并非那么紧凑,不像每个项目都需要测试、前端、后端这样,因此还是一个池子,哪里有需要,就向UI池提出需求。

    现在来说基础研发部。基础研发部由1+n组成,1是架构组,n是基础平台。他们都向技术总监汇报。架构组负责公司的核心架构,如rpc框架,消息中心,监控系统,工具包封装等,由一个首席架构师+几位高级中级架构师组成。架构师在这里管理成分不高,主要是还是技术开发,基本上没有业务。图中的研1组长,研n组长是指的多个基础平台小组,例如邮件与短信平台、搜索小组、爬虫小组、开放平台、用户平台、订单系统等,每个小组由2-3个人组成。基础平台可能会涉及到一定的业务,但也是相对独立或可复用的。

    最后说运维部。运维部在我离开时已经统一由基础研发部管理了。运维一般也是有一个总监,但几个运维工程师,运维工程师中又可分为运维、dba、运维开发等职位。

梯度管理的起因

    梯度管理的内因,我理解的是人的精力的局限性。上面的图有些复杂,放到一个几个人的小团队里可以更好的理解。

    如果给你一个人,你手把手指导没有问题,你们俩可以同时工作,你做比较重要的地方,他做相对简单的地方,你们配合默契,一起完成工作,这时管理没太大意义,因为你知道他做所的所有事情,基本上不需要汇报,一起往下走就是了。

    如果给你两个人,当然事情也会多一点,这时你是还有精力去照顾团队成员的,你依然清楚他们所做的每件事,而你自己会从做事到做把控,做设计这样过度过来。之后给你三个人,四个人,你发现由你无法在不询问的情况下知道每个细节,此时你可能需要每天早来上班前招集大家做一个晨会,在晨会上汇报项目进展。

    之后团队人员继续变多,业务也会飞快的发展,你会发现同时有多个项目运行,而随着项目的演进,业务变得越来越复杂,你发现你没有精力像之前那样对每个细节都那么熟悉了,而随着细节了解的越来越少,你把控的粒度也会变得越来越粗。而在这个过程中,有些团队成员逐渐成为团队中的骨干,他们技术过硬,业务娴熟,有时比你还更了解设计的细节,并且对你的一些细节指导产生反感,认为这个时候你再来搀和就是对他们的不信任。

    这个时候,你的梯度团队就需要提上日程了。你需要选拔一个合适的人,这个人可以独立带领项目,进行项目设计,帮助其他同事解决项目问题,因为这样的放权,这位同事会变得更为积极,相对的,你也不会过于疲惫。

    总结说来,梯度的产生,是因为管理者精力的局限性+适度放权的必要性的综合结果。你不能一直关注细节,精力不允许,别人也会受限制。记得三国后期有句话描述诸葛亮:事无巨细咸决于亮。诸葛亮这种管理方式直接会造成青年才俊得不到学习锻炼的机会,自己也会疲劳成疾。诸葛一死,蜀汉政权迅速凋零。

梯度管理的高效性分析

    梯度管理一旦形成,团队运转将会高速运行。

水平沟通的高效性

    从上面的图上可以看到,划分团队时,是按照最小的粒度、业务独立性进行了拆分,假设项目的迭代多数情况下只会涉及到一个业务线,团队内部沟通是非常高效的。这个小团队工位一般都在一起,很多事情不用开会,一抬头就沟通明白了。而如果是跨团队的,要么开会,要么语音会议,沟通成本非常之高。

项目执行的高效性

    项目优先级可以灵活把控,设想一下,如果你的团队需要开发一个项目,前端或测试却进行着别的项目,让别的团队调整优先级是非常困难的,这样势必会造成效率低下,我等你你等我的现象。

充分发挥优秀员工的积极性

    梯度管理就意味着放权,把一些不太重要的事情的决策权逐渐交给下属,让他们有一个锻炼的机会,也减少流程上对他们的束缚。打个比方,如果没有梯度管理,你就需要对所有成员的所有项目直接负责,所有重要的东西都是你做的,所有的大功劳也都是你的,这样团队成员必然会想,既然都是你负责的,我也没啥机会,我也不用考虑那么细了,反正最后有你把关,出了事情还是你担责任,逐渐就会消极起来。有了梯度管理就不一样了,随着权力的下放,团队成员的积极性也会更高,担的责任也会越大,这本身就是个成长的过程。

纵向汇报的高效性

    梯度管理的又一个好处是汇报更快了。还是做一个对比,在一个小团队里,如果要做一个汇报的话,没有梯度,你需要问n个人,有梯度了,你可能只需要让1到2个人帮你总结一下再做个汇总就行了。这是上传。相反的,如果上级有个下达的指令,如新的制度,通过这种汇报机制,也能在最短时间内起到传达效果。

梯度管理与扁平化

    在说的梯度管理时,我们也常常听到某些互联网公司说他们的管理是扁平化的,这两者矛盾吗?我认为并不矛盾。因为梯度管理并没有强制要求不能跨越节点沟通,你依然可以直接给总监、cto、或ceo提你的建议,梯度管理的公司内部,小组长、总监也都没有办公室,和大家都做在一起,如果有特殊意见或建议,依然可以直接倾诉或提出的。梯度管理和扁平化管理是可以完好的融合在一起的。

梯度团队的建设

认真观察,积极培养

    在最基层的小组团队中,小组长除了日常的项目管理与人员分工,还要认真观察每个成员的工作表现,对于那些态度积极性高,项目完成度好,不抱怨,多承担的成员,要给预更多的发展机会,更大的权力,有能者多劳多得,既而让他去承担一部分你的管理职责,形成梯度。

仔细梳理,业务独立与公共部分抽取

    作为总监或cto,要仔细倾听各小组反馈的问题,其中主要的一点是效率低下的原因,而这种原因往往是跨团队、或者重复劳动造成的。对于跨团队的工作,如果业务是相同的可以合并,如果是重复劳动,要把一些业务下沉并成立一个团队统一负责。

给予认可与奖励

    对于独立业务的负责人或新提拔培养的员工,要认识到,虽然给予机会是也是一种激励,但这种激励伴随着高负荷劳动和更多责任的压力,在工作有一定成果的情况下,要实时的给予认可甚至奖励,让能者多劳多得,否则这种不持续的激励,有可能会造成翅膀硬了脱离团队的风险。


个人资料

张无忌

文章:115篇
还没有评论!