技术领导力实战笔记_35_第28讲_|_业务高速增长期的团队管理：“知轻重、重绸缪、调缓急”
作为企业的技术管理者，如技术总监、技术副总裁或者CTO,必定会期望企业业务快速发展。
这样技术团队对业务的价值才能最大程度得到体现。
但业务的爆炸式增长将不可避免的带来组织结构的变化和管理上的挑战。
那么，作为技术管理者，你是否做好了迎接这些挑战的准备呢？本文将结合我过往在创业公司以及大公司新业务扩张时期的经历，来讲述如何在企业快速成长时做好技术团队管理。
我将先讲一下我对技术管理的理解，再来聊聊企业快速成长时技术团队管理面临的挑战，并给出一些管理团队的建议。
技术管理者大多都是从技术专业人才转变，成为管理者的极少情况下，存在着没有技术背景的。
技术管理者一般都是在企业发展过程中，需要在专业能力或业务贡献上已经被证明过的技术专业人才来成为技术管理者。
希望他们能将自身的业务能力进行复制带给整个团队，以让企业的技术团队正向发展，晋升为技术管理者。
这是一个令人振奋的新角色，但同时也需要不少新的技能和能力来面对这个职位带来的挑战。
我们先来看技术专家与管理者在日常工作输出上的区别。
技术专家的主要工作有与产品QA团队日常思分析业务需求，并制定技术方案。
编写代码，实现功能需求以及修复bug,解决线上故障或触发问题。
经验、知识沉淀及技术学习管理者的主要工作有，设立团队目标，制定工作流程、协调必要资源来支持团队，并与其他团队保持良好沟通，观察团队工作进展向上输出业务进度报告、招募并培训技术人才评定团队成员业绩。
从上面的对比不难发现，这两个角色实际是从不同角度来看相同的业务挑战。
因此，日常需要完成的工作内容是完全不一样的。
简而言之，技术人才或技术专家是面向任务来工作，而管理者或经理的角色是面向人来工作，他是要驱动激励团队来完成业务需要，并根据公司远景来提前布局在业务高速发展的公司，例如创业公司b轮融资后开始冲业绩，又或是被媒体报道后的激增，一般业务量会有几倍，甚至于几十上百倍的增长，这取决于公司的业务模式。
这时企业的技术团队将面临巨大的挑战。
这时，业务系统能否扛住高并发，业务系统的响应速度，以及业务代码是否存在影响严重bug等。
这里我们要聊的是在这种情况下的技术团队管理该如何做。
所以我们不过多关注具体的细节问题，而要以管理者的角度来更加全局性的来审视。
这样情况下面临的核心冲突或是矛盾是什么。
大家经常会听到的一个比喻是边开飞机边换引擎。
这个比喻呢十分形象的将这种困境描述了出来。
我们简化来看这个困境，实际面临的是两个问题，一个是时间，我们需要驾驶这架飞机在最短的时间内安全到达目的地。
另一个便是资源。
我们拥有的飞机就只有这一架，并没有其他备用飞机提供给我们来进行替换使用。
因此我们只能在这架飞机上进行修修补补，继续飞。
不难看出，我们在企业高速成长时，技术团队管理面临的两个核心矛盾或问题，就是时间和资源。
实践上的矛盾在于业务系统开发和完善以及技术储备等，都需要时间来进行开发、维护以及沉淀。
但业务增长的速度和时间窗口并不会给技术团队以太多喘息机会。
那么在这个时间矛盾下，怎么做好技术团队管理呢？精简来说就是知轻重。
众筹谋调款集如何理解呢？这种情况下，时间对于企业团队和个人来说都很紧张。
因此，技术管理者如何分配时间便很关键。
如何分配时间和资源，也将决定了技术团队的发展趋势和业绩输出。
所以，做到知轻重众筹谋调款急是很关键的。
管理者需要从公司业务未来发展趋势上做规划，进而来看自己所负责事情的轻重缓急。
例如，招募并培训技术人才，扣de review,设立团队目标，制定工作流程。
这样的事情对于企业和团队来说是至关重要的，但是并不会马上有明显产出。
但需要持续坚持做是利于长期的事情。
那么，我们到底该怎么从众多的事物中来做区分呢？下面我们先看一张to do轻重缓急象限图。
从上面象限图来看，作为技术管理者，我们应该怎么分配时间和资源呢？以下是我简单的总结，一是重要紧急。
这类事物得做，但要避免做。
例如线上故障解决这种问题，重要又紧急，可能目前只能你来处理，但是应该是有各种故障后备用方案，让团队成员去实施，先保障业务，然后团队再进行问题定位。
二是重要不紧急。
这类事物要坚持做，例如人员招募、培养、组织架构调整、code review以及技术踩坑分享等。
这些事物做了不会马上产生收益，坚持做的话，日后收益会很大。
三是不重要，但紧急这类事物，让团队成员做将锻炼机会，留给团队成员自己做好支持工作。
四是不重要，不紧急。
这类事物不要做，在时间和资源有些许喘息机会时，可以安排成本低的方式来处理。
因此呢技术管理者应该未雨绸缪的将未来发展所需事物列举出来。
也就是说要有技术管理者的远见，然后将目前要处理的事物列举出来，放置在上面的象限。
图中你需要关注的一个象限是重要不紧急。
另外，需要培养团队成员来处理的两个象限事务是重要紧急和不重要。
紧急相机里的事物呢并非是固定的，会产生事物移动的情况。
有些移动是需要技术管理者自己总结和主动发起的。
最后跟大家分享两个小案例，希望对大家有些启发。
案例一，运营活动支撑重要紧急，变为重要不紧急。
之前公司有做过一款社交app运营同学定期会进行运营活动策划，例如情人节、春节、七夕等活动类型比较多，且比较频繁，涉及到活动广告位、活动着陆页、活动参与页、活动结算以及app内状态标识等诸多app内相关的修改、变更。
对于社交app来说，运营活动能够提升客户活跃以及营收，属于是重要紧急的事情。
一般来说呢都是分配一到两位开发人员进行运营活动的开发工作。
开发人员一般不太愿意接这样的活，因为技术挑战不大，且重复性工作较多。
面对这样的矛盾局面，我们是怎么处理的呢？很明显，这样的运营活动一定会持续办下去，那么将重要紧急变为重要不紧急就尤为重要了。
然后呢，我们在研发团队内部立了个小项目，运营团队定制系统，对于过往经常使用的运营活动策划手法进行了总结整理，可以将app内广告位、着陆页、活动参与页以及状态标识修改等诸多内容，可以通过该系统进行定制。
通过运营ISO android前端服务端同学的一起参与，将该项目开发完成运营，仅通过后台便可以完成常规活动的定制审核以及发布案例。
二、提前部署组织架构调整，典型的重要不紧急。
企业业务初期时业务线比较少，一般研发团队、组织架构按照岗位职责来划分，例如前端团队、服务端团队、运维团队以及客户端团队等。
但随着业务不断的发展，会出来很多的子系统和产品，例如产品a产品、b内部运营系统以及数据可视化系统等。
这时，按照职能划分，团队方式的弊端就很明显，研发团队成员需要身兼多项工作任务，如何在各项工作任务之间弄清楚优先级会出来很多扯皮的现象，并且团队越大，团队负责人专门的管理成本会升高。
面对上述问题，通过提前部署好组织架构调整，可以进行化解。
我们先将运维数据服务端团队划分部分人员到基础服务团队，将前端服务端客户端团队按照项目组来进行划分，项目组里加上运营产品团队成员来形成小团队，降低内部沟通成本，提升组织运作效率。
同时研发团队绩效考核上会加上项目组业务的权重评分，这样保证项目组目标一致，高效运作。
以上呢就是我的一些看法，欢迎大家留言，共同探讨。
作者简介，刘俊强，腾讯云，资深架构师TGO鲲鹏会深圳分会会员公众号程序员精进作者加入腾讯云之前，曾在迅雷担任技术总监。