记录思考

团队梯度建设和核心人员的培养选拔的一些思考

技术团队的建设其实是技术团队 leader 的事情,但是我最近也在思考这个问题,现在把我最近的思考写下来。

作为一个技术人员,技术的晋升肯定是一个永远的话题。当一个人的技术能力在提升的时候,慢慢的开始需要考虑技术团队的事情了。就是常见的 T 序列和 M 序列的问题了。对于技术确实有爱好的我并不喜欢走 M 路线,还是比较偏向于 T 路线的。但是 T 路线就真的不用带队了吗?我最近在思考这个问题,以及在我的团队中,我该做些什么,怎么去做。

当我们的 Android 开发的规模在四五十人的时候,我有机会带架构组这样的小团队,这个小团队包括我总共才三个人。当团队缩减成十来个人的时候,架构组这样的团队就不需要了,但是这个十来个人的团队还是保留了一个架构师的名额,于是,这个 title 也就挂在我头上了。这样的配比其实还是比较合理的,架构师占 10% 左右的比例。

说是架构师,其实是一个稍微比较高级点的工程师而已。架构师的 title 太多,我有点招架不住。但是既然挂了这样的 title ,那么团队的技术项目,技术选型的活就全都落我头上了。虽然不是说我一个人全包了,但是我还是需要为我们团队的技术项目负责的,这个 title 不能白挂啊。

在技术方面的压力,从原来的了解变成了事实落地。举个例子,Android 的插件化,之前我只要在网上看看例子,看看几篇文章,大概了解一下,有兴趣的话,还可以写写 demo 试一试,玩一玩。只要我在面试的时候能喷就行,能唬住面试官就没问题。但是现在是不一样的,我需要对各个插件化方案有把握,我需要真的了解他们的优缺点,怎么集成到我们的项目中,成本是多少,风险是什么,怎么规避风险。最后需要决策做不做,以及怎么做,需要安排出具体的计划,让这个项目可以推进。所有的这些远比了解一下插件化要难很多。

在这最近一年多的日子里,我一直顶着这样的压力,推进着一个又一个的技术项目,这些项目对我真实的技术能力是一个很大的考验,这过程中,也经常会感觉有些吃力。

在和朋友聊天的过程中,也发现了一些问题。对于个人的技术能力问题,还是需要靠自己去锻炼。除了个人技术能力外,还需要能够带领别人一起完成任务。说白了,我是不能一个人单干的,需要把团队里的力量挖掘出来,这样有利于他们的成长,有利于我的成长。

团队的技术能力梯度建设问题,如果是一个新成立的小组的话,那还比较简单点,安装规划筹备人员就行,难点就是能不能招到的问题了。而大部分情况下,你是中途接手,或者加入的团队。如果有权力调整团队梯队的话,那还好说,如果没有的话,那么了解团队的梯队就很重要了。不管是 leader 还是这个架构师,需要对团队里每一个人的真实技术能力有一个比较全面的了解的,在这方面上,我还是需要加强的。这样才能够把手头上的事情安排下去,推进也可以更快一些,不至于我一个人苦苦支持。

从感情角度来说,我还是希望团队里的每个人都可以进步到一个很高的高度,这样对他们是最好的。但是实际上并不可能那么理想。每个人都有自己的长短板,不同的时期有不同的天花板,瓶颈。与其花那么多时间去自己完成某个工作,不如花时间培养某些人来完成这项工作。在这方面,之前做的好像确实不够。虽然位置是架构师不是团队的 leader,但是这些事情还是需要去思考,了解的。当然需要在不越权的情况下进行了。

- EOF -

本文链接 https://spacepage.top/articles/2018.07.13-team-build.html,欢迎转载,转载请注明出处。