经常听人讲，我们要建设高效的团队，如何提高团队的执行效率等等，空谈效率没有意义，这篇文章结合作者自身的经历，谈谈梯度团队是什么样子的，为什么一个有梯度的团队是高效的，以及在管理中如何建设这样的团队。
下图是我经历的一家中型互联网公司的技术团队组织架构图，展现了在我离开这家公司之前的一个组织状态，首先介绍一下这个图的含义。
这个图分成两大块，事业部和基础研发部。事业部就指的一个相对独立的业务线，不同的业务线之间有较大的差异，在业务上没有关联和延续。而基础研发部，是指的技术架构的基础设施，比如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，要仔细倾听各小组反馈的问题，其中主要的一点是效率低下的原因，而这种原因往往是跨团队、或者重复劳动造成的。对于跨团队的工作，如果业务是相同的可以合并，如果是重复劳动，要把一些业务下沉并成立一个团队统一负责。
对于独立业务的负责人或新提拔培养的员工，要认识到，虽然给予机会是也是一种激励，但这种激励伴随着高负荷劳动和更多责任的压力，在工作有一定成果的情况下，要实时的给予认可甚至奖励，让能者多劳多得，否则这种不持续的激励，有可能会造成翅膀硬了脱离团队的风险。
