我有多次类似经验,就当是自我总结一下。
第一条、最重要的一条、切记的一条:千万不要新官上任三把火!!!
很多刚提拔上来的小leader,或者刚转到一个团队的leader,急于“快速融入”团队,急于快速树立权威,急于快速证明自己,加上又有了一点权力,会情不自禁的想来个大刀阔斧的改革,参考自己以往成功的经验,这里觉得不爽,那里觉得做得垃圾,碰到一点问题就觉得团队个个都很菜,于是引进这个、改进那个、调整流程、改变规范、树立典型。。。。。。搞得原本稳定的团队鸡飞狗跳,人心惶惶,如果此时业务发展还可以,可能大家忍忍也就过去了;如果正好运气不好碰到业务发展一般,嘿嘿,小心小报告和怨言到处飞,三个月后背锅的就是你!
如何面对这种技术不熟、业务不熟、团队不熟,又不能新官上任三把火的情况呢?我总结为“了解现状、循序渐进、逐步优化、证明自己”几个步骤。
【1 - 了解现状】
新leader的一个典型错误做法就是将老的经验直接搬过来,或者就是按照自己的喜好来管,而不是根据团队和业务的实际情况来管理,这样做轻则被团队认为瞎指挥,重则成为背锅侠。
为了了解业务、技术、团队的现状,第一件事就是“拜码头”,也就是找相关人的人全部聊一遍,包括:你的BOSS、产品经理、项目经理、测试人员、组内所有开发人员、配合的项目组、运营人员。。。。。。等等,主要了解如下信息:
业务的介绍:这个业务规模多大,收入多少,在整个部门的业务中什么地位,老大们怎么看,各个利益干系人怎么评价这个业务,业务现在是停滞还是发展,是问题多多还是表现良好,后面会加大投入吗。。。。。。团队的评价:团队氛围好么? 技术能力如何? 是不是经常出问题?与产品配合如何? 经常和产品吵架么?研发和测试配合怎么样?。。。。。。人物的评价:谁是技术最好的,谁是业务最牛的,谁脾气比较大,谁性格比较好,谁比较拼命,谁表现一般,每个人自己如何评价自己,如何评价团队其它人。。。。。。各方期望:BOSS为什么派你去? 产品经理希望你做什么?项目经理给你的建议?团队成员的诉求?配合方的建议?。。。。。。
拜码头大概需要一周时间甚至两周时间,不要急,跟一个人聊完后,消化一下,别一天跟10个人聊,信息量太大你也吸收不了。
第二件事就是“用产品”,不管什么业务或者系统,你至少要简单的用一下,体会一下。是Web还是App ?用户在什么时候用你的产品 ? 主流程是怎么样的? 全流程跑一遍有多少步骤?系统包含哪些基本功能?当然,用产品的事情并不一定要等拜完所有码头后才做,而是可以穿插进行的,你跟产品A聊了一下,然后体验了一下业务,理解会深一些;你再跟运营B聊一下,再体验一下,理解又会更深一些。
第三件事就是“看文档”,把这个业务和团队积累的文档都大概的扫一遍,了解更多历史和细节信息,能够更好的熟悉业务和熟悉人。比如说有的人写的文档很好,有的人写的文档很一般,有的人一篇文档都没有。
整个了解现状的时间短则一两周,长则一两个月也是可能的,看业务和团队的规模而定。
【2 - 循序渐进】
拜完码头,体验了业务,看完了文档,你以为你就很熟悉团队、业务了? 图样图森破,有事拿衣服,其实还差得远呢!第一阶段你能获取到的信息有30%就不错了,更多的细节信息需要在工作中持续观察和体验。
比如,产品说系统不太稳定,经常出bug,但到底“出bug”是什么意思呢? 页面经常挂掉? 系统经常宕机? 用户投诉很多 ?还是出了bug处理很慢?。。。。。。
比如,项目经理说版本开发效率一般,那什么是“一般”呢? 是bug太多导致测试周期长? 是进度不合理导致总是延迟 ?是突发需求多导致版本经常变更?是产品经常在测试阶段改需求 ?还是测试环境不足导致版本没法测试?。。。。。。
比如,A同学技术很厉害,到底是哪里厉害? 线上问题定位很快?开发语言很熟悉?数据库高手?还是代码bug很少 ?
以上种种细节信息,需要你和团队一起开发、一起处理问题、一起讨论需求、一起和产品撕逼、一起和项目吵架。。。。。。等等各种事件中去体会。
这个周期大约持续1 ~ 2个月。
即使你是技术总监、架构师,这个步骤也是必须的,只是具体做的事情可能有所差异。比如对技术总监来说,就需要了解各个团队用了什么技术,技术牛人都有哪些,整个团队的流程和规范是如何的,执行过程中有什么差别等等。
【3 - 逐步优化】
经过前两个阶段,你对现状已经非常了解,此时团队和业务是否有问题,问题在哪里你都已经比较清楚了,是不是有了想大干一场的冲动?毕竟都憋了几个月了。
别急,对于一个已经运作了2年的团队来说,改革都是让大家改变习惯,总有人会反对和不习惯的,即使你已经熟悉团队和业务,也不要来猛烈的改革,这样会给团队带来较大的震动和不稳定因素的。即使你觉得这是一个烂透了团队,你也不可能把人全部开除然后自己重新组建,因为招人不像开人那么容易,从零开始组织一个10人的团队,靠招聘至少6个月,而且新人技术不熟,业务不熟,那这段时间你的业务完全处于停摆状态,BOSS受不了吧?
但也不能什么都不做,毕竟对于一个新安排的leader,不管是团队还是BOSS,都是有所期待的,期待带来一些正向的改变,啥都不做就是辜负了各方的期望。
所以我推荐逐步优化,技巧就是先挑一些简单的优化推行,让大家看到一些变化但又不会特别抵触,对团队影响也不大,这周优化流程,下周引入一个技术,3个月后架构重构,润物细无声的慢慢就把团队的不好地方改过来了,你也展现了自己的能力,团队成员也欣然接受,业务表现也不错,各方评价更高了,BOSS也开心,这是最好的多赢局面。
那如果团队已经很不错呢?首先恭喜你,因为你不需要做太多的优化;其次提醒你,没有完美的团队,没有完美的业务,没有完美的技术,如果你认为啥都不需要做,首先想想是不是自己水平还不够,看不出问题和找不到提升的空间。
【4 - 证明自己】
经过前面大约半年到一年的时间,业务你也熟悉了,团队也熟悉了,各方都认可你了,此时可以做一些比较大的动作来证明自己了。但我不建议为了证明自己而凭空想出一些大动作,例如业务完全不需要你却要引入docker和大数据这类。关键还是要结合业务、团队、技术,来找一些关键事件。
比如,我接手A项目(后台系统)的时候,做了系统拆分,减少了90%的线上数据问题;
比如,我接手B项目(游戏接入)的时候,做了双中心,解决了机房故障导致业务损失的问题;
比如,我接手C项目(手游交易)的时候,做了架构重构,引入很多组件和拆分系统,降低整站故障的次数和影响。
特别申明:以上内容仅适合于技术leader、技术经理,最多到技术总监,如果阿里的CTO换到滴滴,千万别这么做,当然,具体怎么做我也不知道 :)