首页 > 生活杂感 > 关于带团队的一些感悟

关于带团队的一些感悟

2018年8月7日 发表评论 阅读评论 600次阅读    

最近几年慢慢挪一些精力到团队上面,其实这方面觉得摸着石头过河,然后自己呛了一口水,也很多事情没做好,挺对不住兄弟们的。

其实非常不想提‘管理’这两个字,因为我理解谈不上谁管谁,而是大家一起努力,一起干,只是工作分工不同,有些人不得不抽时间去做一些support工作,有些人喜欢专门投入精力到coding, profiling中去而已。所以百度技术人才有T序列,和M序列的拆分。

这里写的东西大都是在平时总结或者说想到的,不要对号入座,基本上大都跟work无关,只是记录一点上下班路上的思考而已。要对就对我^.^,我就是那个反例,想到和做得到是不一样的。

当个好服务员/兄弟,而不是领导

什么意思呢?平时多想想大家的困难点在哪,主动提供帮助,至少平时别一副严肃的样子,多关心下大家,组织个TB,提醒个事情什么的,该表扬表扬,该批评适当合理的注意场合批评(这点我做的很差~)。多给大家提供帮助,做个好服务员,姿态很重要。

不要高高在上,遇到同学找你说事情的时候一定要好好听,耐心讲,千万不要先预设立场,一开始就是一副自己是正确的,我得给他指点问题才行的姿态。

平时多跟大家一起吃饭一起玩,不要做个很难接近的人,最可怕的是大家找你的时候得准备一下,得小心翼翼的来找你,那一定是你的问题了。

太过追求技术完美

有些时候技术人喜欢挑细节,会钻到某个小点上追求完美,做到极致,不这样不行。这样对技术人员可能还好,但是一旦到团队管理上,太过于追求完美反而不好,举几个例子就清楚了:

  1. 产品这么设计有漏洞,如果XXX怎么办?什么?用的少,用的少就能这样了吗? --- 有利有弊,别在不应该的地方钻牛角尖。
  2. 你这功能被黑产利用了怎么办?被刷了怎么办?不行,这方案不行。 --- 黑产变成第一挡箭牌了,好搭档。
  3. 这东西我知道他怎么做的,但这很low,还不如自己重写一个呢? --- 全世界就你牛逼?老板给你发工资让你带团队造轮子呢?
  4. 我们先找出根源问题吧,出问题先忍着,产品来了也没招,我在找原因呢。 --- 你就不能先保证用户体验别继续挂?

不要凡事亲力亲为,冲在最前面

很多技术出身的人都有一个特点,就是看到bug就冲动,看到好玩的技术点就跃跃欲试。而这个时候负责人往往经验丰富,做起来很快,也拥有着分配工作的权利, 所以经常奋不顾身就冲到前面去了。

最典型的就是,每次线上出问题了,第一个跑出来解决问题的往往都是你,团队的其他人还没反应过来呢,你就发了个fix diff, 完了还在群里一顿骂,骂这个怎么设计的,骂那个为什么不review,数据库怎么能这么用。 这个时候上帝可能会说,你早干嘛去了?

时刻记住一定要给大家解决问题,成长的机会,可以适当引导,找不到问题的时候提醒一下,提供必要的帮助,但千万不要什么事都帮大家干了,然后自己爽爽的,一副救世主的姿态,外加溜达一圈,这其实挺不适合大家成长的。

一定要记住,TL不是兵,你的优越感从来都不应该是自己解决了什么问题,而是团队一起解决了什么问题,大家有什么成长。
一个人的牛逼不是牛逼,团队壮大了才是你的优越感。找好定位啊。

手不要伸太长

这种情况一般出现在你管的人比较多是时候,比如线上出问题了,老板经常第一个跳出来@ 一线技术,客服群里发出问题后没几分钟,CTO 跑出来开始说“这个问题xxx看一下吧”,或者“这问题XXX 找你的人看一下吧”。 注意跨级沟通是个挺让人有压力的事情,挺郁闷的, 有以下几点:

  1. 官大一级压死人啊,虽然互联网公司扁平,但多少让人有压力;
  2. 不紧急的问题别整天在群里@ 人,你的话很可能大家优先级比较高,频繁打断开发很让人讨厌的;
  3. 给大家个反应时间,你可以整天没事干盯着群里的消息,但是大家不行啊,知道为什么程序员晚上写代码效率最高么?
  4. 你确定你还懂细节业务?确定那是个问题?

这问题归根结底是“在什么位置做什么事情,不要随意跨级沟通,除非你能提供必要的帮助,不要做那个群里的Mr.@ATer”。
送一张图体会一下:

舍不得放权

这点经常也会遇到,因为你很可能是从基础干起的,很多核心功能都是你做的,你最了解最懂这代码。然后由于这功能比较核心,不小心就会出问题,于是紧握着权限不给别人,不放心给大家去运维,去改。

最直接的例子比如: 一个服务里面的核心功能,每次线上有问题或者有bug的时候,就自己冲在前面,不给别人机会去了解,自己吭哧吭哧的在那敲代码,敲完也不发给其他人review,也不讲讲具体原因和解决办法。 最多就是“这问题我解决了,你们看一下反馈,看看监控还有没有问题吧,一个很隐蔽的问题” , 然后就没有了,留下团队的其他人一脸懵逼~

还不用比如线上某个服务不太行了,需要升级或者换一个别的框架或者开源库。这个时候你是自己默默的去找别的框架试呢,还是让其他同学去调研,了解,评测,最后大家一起评审出一个最优的解决方案,然后让他们去搞起?第一种自己很爽,也许你会觉得你自己先选一个部署好,让大家去用更安全。其实你是错的,你完全可以做那个引导着,在评审的时候不断引申出疑问和注意点,带着大家走到正确的路上。

殊途同归,但是过程完全不一样。甚至别人比你做的更好,毕竟术业有专攻,何况大家所能付出的时间是不一样的。

要了解大部分代码,却别替别人写

这个跟放权,不要亲力亲为类似。
你应该去了解大家实现的代码,设计的功能,不然只能瞎指挥。但别把别人的事情干完了。你应该干你该干的事情。
所以扯远一点,这挺重要的,团队负责人整天冲在前面写代码,那怎么服务大家?让大家给你点赞么?其他人怎么成长? 好的TL每天确实忙但是忙着做计划,想着怎么给大家带来帮助。

适当让大家试试新东西、服务

包括两点,别一直安排某个人做某件事情,适当轮岗换换工作,收益很大的哈,不信试试。
另外就是技术人很多都有个特点:特别喜欢尝鲜,想试试某新的开源服务。 条件允许的情况下,确实能带来一些实质的好处,其实可以支持大家适当尝鲜,适当引进新功能。当然要悠着点,别整天造轮子,别整天core了。

充分考虑大家的成长和公司需求

不扯了,我就是个反例吧可能。^.^

最后,怎么看你是不是做好了呢,简单点: 看大家平时能不能跟你打到一块去,看你哪天创业的时候,有没有人愿意跟你干。

Share
分类: 生活杂感 标签:
  1. kulv
    2018年11月11日17:55 | #1

    @三颗豆子
    世界这么小,有机会的

  2. 2018年11月8日00:34 | #2

    你和博哥都是很好的TL,很难再遇到了。

  1. 本文目前尚无任何 trackbacks 和 pingbacks.

注意: 评论者允许使用'@user空格'的方式将自己的评论通知另外评论者。例如, ABC是本文的评论者之一,则使用'@ABC '(不包括单引号)将会自动将您的评论发送给ABC。使用'@all ',将会将评论发送给之前所有其它评论者。请务必注意user必须和评论者名相匹配(大小写一致)。