前几天在脉脉职言看到这样一个提问:带团队的人,你们是怎么了解业务细节的?如果不了解,怎么懂的比实际干活的多的?
从技术管理的角度来看,这个问题可以很典型地反映出研发岗与技术管理岗的差异。今天我们就来聊一聊这个事情。
技术管理的思维
从提问者的文字描述来看,我们大致可以推断出他的想法:Leader 肯定要比员工懂得更多的技术细节,不然怎么做 Leader 呢!站在技术 Leader 的角度,这句话其实对错分半。对的地方在于技术 Leader 确实懂的比员工多,但不是细节,而是全局。错的地方在于技术 Leader 并不需要懂所有细节。
当你从一个员工变成了 Leader 的时候,你的职责不再是做完这个需求就完事,而是对这个团队的产出负责。这个时候你个人是否实际去做事,是否了解具体的细节,其实变得不再重要了。你关注的重点应该是整个团队,你应该去做哪些对整个团队有益的事情。
之前你能很好地完成一个需求,并且能非常出色地完成。但即使你再怎么努力,你最多也就影响这一个需求而已。但如果你是一个团队的 Leader,那么你做的事情就可以影响整个团队,此时你的产出就是这件事乘以所有人。从这个角度来说,你此时考虑的应该是整个团队,而不是具体某个需求。
关注团队的整体产出,而不是自己具体做了多少需求,是成为技术管理者的思维转变第一步。
现实情况不允许
为什么说技术 Leader 不需要懂所有业务细节?
这是因为现实情况不允许!因为这是一个不可能完成的任务!
当团队只有两三个人的时候,技术 Leader 确实是可以亲力亲为,什么事情都自己干,任何一个业务细节都摸透了,遇到线上问题自己冲在前面。但是当你的团队变成 8 个人了呢?当你的团队变成 20 个人了呢?你的团队变成了 100 个人了呢?你还能了解所有细节,你还能所有问题都自己解决吗?
想必对于这个问题的答案,大家都清楚,答案肯定是不可能!那么既然不可能,那么我们有什么办法去解决「大团队」的工作协作问题呢?此时这个问题就不再是技术问题,而是一个具体的学科问题,我想这或许是组织管理、领导力的概念了。这块我也不是很懂,所以这里就不展开了。下面我结合我的实际经验,聊聊十几个人的团队怎么做组织管理和分工协作。
团队达到十几个人,我们需要有授权的概念。授权的意思是我把一部分权利分给员工,员工可以在权利范围内自行决定,不需要经过 Leader 的同意。通过这种方式,来提高事情的处理效率。但授权同时也伴随着责任,这就像法律的义务与权利一样。
授权讲得直白点就是:这块业务给你搞了,这块业务上发生的任何事情,你都需要关注,包括线上问题、系统优化等等。你可以自行决定需求的技术方案以及优化改进措施(权利)。你是这块业务的直接负责人,业务有什么问题你就是第一责任人(责任)。
经过授权之后,一般十几个人的团队会拆分成 3-5 个人一组的小组,单独负责 1-3 个系统。这时候这几个小组是一个独立的单元,可以高效地自行运转,不需要你做太多的干预。这时候很多业务细节,其实并不需要你去干预。你只需要在关键时刻给予支持和辅导就可以了。
那么是不是 Leader 就完全不需要懂这块业务的内容了?那肯定不是,技术 Leader 只需要了解个大概,知道这个东西大致是什么,业务细节可以等到具体需要的时候再了解。
如何总览全局?
那对于技术 Leader 来说,怎么样快速了解一个系统?又怎样在需要的时候可以快速上手了解业务细节呢?对于我来说,了解一个系统最重要的其实就是两个东西:数据库 ER 图、系统架构图。
数据库 ER 图,其实就是业务模型。 所有的系统到最后其实就是数据,如果你弄懂了数据库 ER 图,明白了实体与实体之间的关系,那其实你就弄懂了这个业务。在你遇到问题的时候,你就知道怎么去找关联关系,怎么去排查问题。所以弄懂数据库 ER 图是很重要的。
系统架构图,其实就是系统的具体实现结构。 如果说 ER 让你弄懂了业务模型,那系统架构图就是让你明白系统是如何运作的!你弄懂了业务模型,但你不懂系统运作的原理,那你还是无法入手去排查问题、去写代码。但如果你弄懂了系统架构图,那你就知道系统数据流是如何走的,问题可能出现在哪里,我这个需求需要改动到哪些地方。
ER 图和系统架构图,基本上是我了解一个系统的关键。在实际工作中,我也是只了解这两个东西,再加上一些需求的大方向。而具体的细节,恕我直言,真的太多了,无法一一了解。如果真的到了那种需要技术 Leader 自己动手排查问题、自己动手写需求代码,那这个团队真的离崩塌不远了,所以这个问题其实可以忽略。
或许下次可以写一个:为什么技术 Leader 自己写代码、排查问题,这个团队就离崩塌不远了?
他山之石
上面就是我对这个问题的一些只言片语,说得有点乱,没啥太多的逻辑,但思想是对的。这个问题下也有不少热心的网友写了很不错的回答。这里也摘录一些。
诸葛瑾推荐了三本管理相关的书:
拉姆查兰《领导梯队》,管理领域的经典力作,详细阐述了从基层 leader 到 CEO 各个层级的能力要求和工作方法。2. 陈春花《管理的常识》,顾名思义这本书是讲管理的基础概念,越是基础越需要理解,每次读都有不一样的收获。3. 前美军特种作战司令斯坦利麦克里斯特尔《赋能》,阐述的是如何像园丁一样通过给团队赋能,最大限度发挥团队成员的主观能动性,打造应对不确定性嗯敏捷团队,这本书对于如何对自己不擅长的专业领域进行有效管理非常有启发(这也是高层级管理者需要具备的可迁移的通用能力)
诸葛瑾聊了聊他的一些想法:
带团队重要的是如何带领团队形成合力创造更大的价值,并走向一个更好的未来。如果还一直在关注当下很多细节,说明团队没有成长起来,下面的人还不能独挡一面,或者内部外部的协同有问题。大概可以从以下几个方面思考:1. 定目标,短期与长期,个人与团队;2. 划边界,团队內与外;3. 追过程,关键节点;4. 拿结果,保质保量拿到目标结果;5. 建团队,选用育留开人;每个方面要做好都要花很多心思。一个优秀的管理者应该是这个团队有他没他都能运转的很好,这样才能更好地往下一个层级发展。
华山弟子举了一个很形象的例子:
如果你管理的团队,还要靠你来主力输出的时候,就需要考虑自己的问题在哪里了。这就好比京东物流,每天东哥送货量占比 50% 以上,这是什么画面。
腾讯员工聊了聊他的想法:
肯定不了解业务细节啊… 带领着一帮人做成一些事,才是 team leader 的职责,至于这些事需不需要他自己来做,根本无所谓,要的是结果。最基本的,一个项目扔给你们团队,能否保质保量按时交付。重要的是交付,而不是 leader 和大家一起写代码。更进一步,团队是否有战斗力,比如能否交付有难度的项目。这取决于团队成员的技术能力和协作能力,技术大佬可以是但没必要是组长。组长最重要的还是协调组织能力。如果自己不在一线,那就要想办法给一线兄弟们带去更多利益,不然谁跟着你干?楼主:也许我的思维还没转变,总想让别人知道自己干了多少事。回复楼主:干了多少事很简单啊,哪些活是你接过来的?这些活的意义你有没有了解清楚,价值是什么?怎么拆解给兄弟们的,怎么管理研发进度的?作为一个 tl 对整体项目负责,你做了哪些去负责?比如服务挂了你是不是不知道?为了监控到可能的问题,有没有做详细的监控方案,有没有兜底方案?这些事情你想到了,可以交给组员来实施,什么进度了你有没有跟进?为了提高迭代速度,你做了哪些研发流程的管控,从而提高组员的工作效率和需求响应时间?最终通过你的组织协调甚至直接参与架构和代码设计,团队做出了哪些成绩。
名草求主的回答也有不少人赞同:
不要想着带人的了解系列比底下人多,否则你就是不合格的主管,了解个大概,知道对方在做什么,给方向争取资源利益才是你该做的,否则就是不懂瞎指挥,做主管的自以为比别人懂导致实质意义的瞎指挥的真不少。
小结
回归到这个问题:技术 Leader 是怎么了解业务细节的?
我的答案是:不需要了解太多的业务细节!作为技术 Leader 只需要大致了解业务模型、系统架构就可以,细节问题交给手下的弟兄们。作为技术 Leader 的你还有更多、更重要的事情去做!
大家是否有类似的经历?是否也曾吐槽过自己的 Leader 啥都不懂瞎指挥?是否不理解为啥啥都不懂还能做 Leader?是否也曾陷入到业务细节的坑里面,无法自拔?
本文转载自微信公众号「陈树义」,可以通过以下二维码关注。转载本文请联系陈树义公众号。