高效管理之团队梯度建设
千次阅读
2020-05-18 20:03:21
经常听人讲，我们要建设高效的团队，如何提高团队的执行效率等等，空谈效率没有意义，这篇文章结合作者自身的经历，谈谈梯度团队是什么样子的，为什么一个有梯度的团队是高效的，以及在管理中如何建设这样的团队。...
经常听人讲，我们要建设高效的团队，如何提高团队的执行效率等等，空谈效率没有意义，这篇文章结合作者自身的经历，谈谈梯度团队是什么样子的，为什么一个有梯度的团队是高效的，以及在管理中如何建设这样的团队。
梯度团队介绍
下图是我经历的一家中型互联网公司的技术团队组织架构图，展现了在我离开这家公司之前的一个组织状态，首先介绍一下这个图的含义。
这个图分成两大块，事业部和基础研发部。事业部就指的一个相对独立的业务线，不同的业务线之间有较大的差异，在业务上没有关联和延续。而基础研发部，是指的技术架构的基础设施，比如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、运维开发等职位。
梯度管理的起因
梯度管理的内因，我理解的是人的精力的局限性。上面的图有些复杂，放到一个几个人的小团队里可以更好的理解。
如果给你一个人，你手把手指导没有问题，你们俩可以同时工作，你做比较重要的地方，他做相对简单的地方，你们配合默契，一起完成工作，这时管理没太大意义，因为你知道他做所的所有事情，基本上不需要汇报，一起往下走就是了。
如果给你两个人，当然事情也会多一点，这时你是还有精力去照顾团队成员的，你依然清楚他们所做的每件事，而你自己会从做事到做把控，做设计这样过度过来。之后给你三个人，四个人，你发现由你无法在不询问的情况下知道每个细节，此时你可能需要每天早来上班前招集大家做一个晨会，在晨会上汇报项目进展。
之后团队人员继续变多，业务也会飞快的发展，你会发现同时有多个项目运行，而随着项目的演进，业务变得越来越复杂，你发现你没有精力像之前那样对每个细节都那么熟悉了，而随着细节了解的越来越少，你把控的粒度也会变得越来越粗。而在这个过程中，有些团队成员逐渐成为团队中的骨干，他们技术过硬，业务娴熟，有时比你还更了解设计的细节，并且对你的一些细节指导产生反感，认为这个时候你再来搀和就是对他们的不信任。
这个时候，你的梯度团队就需要提上日程了。你需要选拔一个合适的人，这个人可以独立带领项目，进行项目设计，帮助其他同事解决项目问题，因为这样的放权，这位同事会变得更为积极，相对的，你也不会过于疲惫。
总结说来，梯度的产生，是因为管理者精力的局限性+适度放权的必要性的综合结果。你不能一直