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