技术团队化腐朽为神奇路线图

对于一个主题的表达方式有几种:一篇文章,一次演讲,一个workshop,甚至一本书。关于这个主题,4月14日在AHA会议上会有一个演讲,在演讲之前,写一篇文章是个不错的主意,帮助自己准备和理清思路,也是一种比较好的准备方法。

为什么想讲这个主题?原因还是跟自己这一年的工作有关,从思想到行动基本都是在这个事情上,把一个技术团队以及他们的产出物变得更好。只是我现在的角色与以前有几个变化:1)以前是自己直接管理团队,现在则是在旁边看着提建议,好处是抽离来看问题看得更加清楚,坏处当让是改变起来很难。2)以前的团队是从零开始的,而现在的团队都是有历史的。如同企业有初创和转型,转型比初创要难十倍,就是因为他有历史,有那些丢不掉的包袱。团队建设也是一样,有历史的团队扭转起来更难。3)最后一个不同就是以前我的经验基本上都是在一个公司的,现在HiCTO服务接近二十个公司,见得团队多了,试的方法多了,也就能抽取共性。经验这个事情,有的时候只在一个环境中有用,换了个地方就不行了。

关于团队的问题,我想首先来谈谈看偏见,我觉得最形象的比方就是我们是在治疗感冒还是癌症。看看这两种病的不同,首先是时间上的不同,一种是突发性的疾病,另外一种已经日积月累,一种急性,一种慢性。所以,指望一个大力丸下去全部搞定的事情,对于急性病可以,对于慢性病不可以。第二,付出的代价也是不同的,感冒咳嗽药的价格不高,甚至不看自己也会好。而癌症要治疗下来,那整个的成本至少是在几十万,美国是两百万,而且还不一定能够治好。第三,最最根本的问题,癌症是基因复制出了问题,如果不能从基因这个角度入手的话,就算实施了大手术,还会旧病复发。治疗感冒对症下药就好,治疗癌症还要看哪里的基因除了问题,需要寻找对应的靶向药。

好吧,说得好吓人是不是,我觉得我只是说出了一个事实,那就是大家对于团队的理解和认知远远低于事实情况,就像我们对于自己的身体一样无知。好了,下面我们假设进入了一家我们所谓的腐朽的团队,那么我们应该怎么办?我这里列出我所理解的九条规则,这里面是有顺序的,但是偶尔一两条不做或者顺序调整下,我想问题也应该不会太大。

外科手术篇

1. 一战成名

我们为什么需要一战成名?原因有两个,那就是一方面要在团队中建立威信,毕竟是技术团队,最有效的还是专家管理,就是我的技术能力比你强,你就自然没话好说。我个人持有一种偏见,那就是纯管理的经理,其职业发展道路是有限的,技术的底子有多厚,决定了管理上能走多高多远。团队中的人信不信你,服不服你是你的想法能否落地的关键。第二的原因是需要让你的老大,产品和运营能够建立对你的信心,如果你的老大不挺你,产品和运营的同学不支持你,你的外部压力就会很大,导致没有施展的空间。

有一种架构师叫做新来的架构师,他也知道信任和信心的重要性,只是他选择的是一条非常难的道路,就是要引入一个新的架构,而这件事情劳命伤财,周期太长,风险巨大,不能快速看到效果。最好的方式是选择一个业务上影响很大好久都没有解决的问题,因为这样产品业务都能有所感知;第二就是快速起效的,能够很快看到效果的。我们不是要证明自己强,而是要证明自己对于业务的价值。

2. 管理预期

有些团队的负责人一上来就开始闷头做事,带着团队开始往业务目标冲刺。我建议先不要这样做,首先的一件事情是和你的上司谈,和你的对口的产品业务谈,谈什么?谈他们的预期,他们最希望解决的问题是什么,以及时间点。还有就是什么是可以缓做的,或者不做的。原因在哪里?首先一个原因是一个技术团队的产出品的好坏,CEO,产品经理,业务的人最有发言权,不管团队自己说的多好,他们不满意都是白搭。产出是检验一个技术团队好坏的唯一标准,而这个标准是捏在外部的这些人手上的,不是在内部的。其次,团队内部的反馈帮助不大,内部的声音往往会有两种,一种是受害者心态,就是抱怨受到不公正待遇;另外一种是觉得自己什么问题都没有。如果团队意识到问题的话,问题早就被解决了,往往是意识不到问题,或者不是真正认为他是个问题,或者他自己本身有问题,才无法让问题得到解决。

管理预期还有一个重要的作用就是要为团队减负,为调整留下空间。传统机械的管理模式是一看团队产出不行就采取高压的方式,结果虽然短期内看到产能提升了,但是质量却大大下降,为以后积累的大量的技术债务,这些债务的集中爆发才引起了团队之后的效能大降。我们在团队效能提升的过程中是需要大量还债,简化系统,需要把负担降下来,所以如果能够把外部压力降下来,就可以让我们进行更大范围内的调整。这就像是面临经济危机的时候,不应该收紧银根,反而应该货币超发,这些都是经济学的基本规律。

3. 让不合适的人离开

经过了前面两项之后,你的肌肉也秀了一把了,老大也开始挺你了,外部的压力也缓解了,下一步就是要好好盘点一下手上的人了。不管今天我们面临的技术问题是长成什么样子,最终你会发现都是人的问题。人是组织的基本单元,人的思维和做事方式决定了组织的基因,要该组织的基因,必须从人开始入手。对于团队中人的评估主要分成几个点:1. 技术能力。好了,又回到了技术上了,技术管理中间很重要一点就是对于每个人的技术能力进行一个合理的评估,这又是一个技术管理者的一项基础能力。2. 能量场。他身上到底是存在正能量还是负能量,凡是有抱怨的,必然是负能量场,需要特别留意。对于这两者评估以后就自然会出现四个象限,1. 技术好正能量,委以重任,加薪升职。2. 正能量技术好,老黄牛类型,降低难度,多布置任务。3. 技术好负能量,适当隔离,给予有难度的技术任务,紧盯考核。4. 技术差负能量,马上离开。

一般来说这个时候肯定会出现一种情况,那就是这个人离开了以后他的事情就没有人做了。这就是为什么我们要和产品业务达成预期的原因,很多工作是不需要做的,如果我们的外部压力不放一些的话,里面无法调整,这就是死锁。而且一个烂人同样占有一个名额,业务团队的期望值是跟着你人数走的,而不是看具体的能力走的。第二,真正重要的事情,就应该给更重要的人去干,不重要的事情就算不做了也没有人关心。第三,如果这个岗位没有其他人的情况,那么可以考虑稍微缓缓再动,但是裁员最好的方式是一步到位。这样对团队的冲击反而最小。

恢复调养篇

4. 丫丫学步

前面三步,就如同外科手术一样,需要干净利落地尽快完成。但是接下来的事情就需要慢慢调整了,一定要不急不躁,一步步地来。不管剩下的人有多么地优秀,不管剩下的人有多么渴望成功,不管业务有多么迫切的任务,我们都要保持淡定和克制,就像是一个全新的团队一样,需要重新建立起自己内部的工作方式,饭要一口一口吃,每一口都细嚼慢咽;路要一步一步走,每一步都扎扎实实。

怎么样才是一步步走呢?我举几个例子:比如scrum,千万别一下子推广出去,先开每日站立会议,先跑两周。在过程中每日监督,确保每个人对着大家讲,确保每个人写出来的工作内容是可读的,确保会议时间是准时的,不准时的要接受惩罚。再比如代码规范,先达成一个小小的规则,比如 { 到底是跟着后面还是独立一行。又比如,Code Review从一个最新的模块开始,先在几个人中间开一次。以前我们一个很好的经验就是,确保一个规矩有效,比建立一千个无效的规则要好得多的多。一旦这些规则变成潜规则,变成工具,深入到每个人的习惯之中,那么这个团队的战斗力也就是在不断提高。想想看特种部队的训练,无非就是一次次训练最简单的技战术动作,让这些动作变成人的自然反应。

5. 稳住节奏

清理了人员,建立了规矩之后,我们必须再次回到对外,团队管理中对外管理是非常重要的一部分,甚至可以占到管理中30%以上的时间,之前说过技术团队的衡量标准是团队的产出,而这个标准是外部团队定的,不是自己定的。同时还有一条,技术团队的输入也主要来自于外部,需求来自于外部。当然也有很多的需求来自于内部,比如技术重构,性能优化,架构升级,这些工作会占据外部需求开发的时间,可是最终又会让产出结果更好,这些都是需要跟外部去沟通的。基于这几点,我们需要把对外沟通的渠道和方法变成一种有效的开发节奏,这就是我所说的稳住节奏。

首先是明确迭代周期,传统的开发模式是需求固定,人员不固定,开发时间也不固定的状态;而现在scrum模式的方式是人员固定,开发时间固定,而需求不固定。这个怎么来理解,拿远洋运输来比喻可能最好了,传统开发就像是就是要把一批货物从A运到B运完,不管用多少条船来运,运完为止,时间完全取决于船的大小。而迭代模式是从A到B点开了一条航线,就这么些运力,每周一班准时出发,需求要被切碎到一个个集装箱里面装好,这样集中发船,装船卸货的速度都是标准化的,这样效率就会很高,但是同时对于货物的切分和先后就提出了更高的要求。

所以回到技术团队和外部的沟通部分,基于明确的迭代周期,一周,两周或者是三周,一个月,这个根据业务形态来定,然后产品需要维护一个产品需求池,技术需要维护一个技术改进需求池,每次迭代周期需要有明确一次迭代需求的会议,什么放进去,什么不放进去。平时的时候还需要针对需求设计,还有开发过程中的需求改进进行沟通,到迭代结束的时候,还需要产品来进行确认验收,整个过程需要经过长期打磨,变得尽然有序。这又是一个长长的磨合过程,不可一蹴而就。

6. 目标达成是最好的激励

如果你问技术他最有成就感的时候是什么?基本上都是在他的成果被认可的时候。而对技术团队最好的鼓励就是他们的一次次迭代都成功上线,然后得到业务的认可。还是回到第二条和业务之间做好期望值的沟通,以及第五条建立共同的节奏吗?一个士气低下的团队,往往是得不到任何的鼓励和滋养的团队,而这可干枯的小草最需要的就是外部的鼓励,所以,一开始定的目标可以小一点,低一点,相对比较轻松地能够完成,然后再把目标调高一点,继续达成,然后再调高,再完成,这样团队的自信心和战斗力会逐渐提升。团队的战斗力提升不是自然发生的,而是被设计出来的。

关于团队的激励我再谈两点,一种是所谓的严刑峻法或者重赏之下必有勇夫的心理,这两者都不是很好的方式,前者会让人陷入到怕承担责任的坑里面,后者会进入到个人英雄主义,觉得别人拖自己的后退。技术团队最好的方式还是需要把对于个人的激励推迟,不要把短期结果和表现进行强挂钩,采用半年的综合评定的方式。另外一点是随着OKR的知名度越来越高,很多团队就想引入这样的考核方式。这我也不是很推荐,原因是OKR的基础是技术人员已经有了很强的自驱力,这对于团队的要求较高。而我所见的大多数团队,尤其是需要倍改变的团队,往往缺少的正是自驱力,可以在KPI和OKR之前做适当的变种,那就是有些是公司期待的,把一部分目标适当地放给员工去定。

目标达成的意义不仅仅是在于团队信心的增强,凝聚力的增强,而且可以加强互相之间的配合,优化流程。在每次迭代之后必须引入postmortem会议,就是对于协作方式和流程的反思和总结,让大家觉得特别好的工作方式保留下来,同时改掉原先不好的工作方式。这样团队是在不断地进化,即便有时候我们失败了,只要养成了总结的习惯,团队也能比较快地发现原因,避免以后掉进同样的坑里。

发展提高篇

7. 引入新人

第四第五第六步的共同特点就是循序渐进,永不停息地做,分别从内部规则,外部协作,目标提升和总结的角度不断让团队形成自己的战斗力。为什么这个时候才谈引入新人,最重要的原因是虽然新人很重要,但是我们不能完全寄托在新人身上,有的团队有这样的期待,就是牛人来了以后什么问题就解决了。基本上这个事情叫做可遇而不可求,首要任务还是在自己团队里面先折腾起来,把自己能够控制的部分先做到最好。招人是个长期的活,不是一个想招的时候捞一把,不想招聘的时候看也不看,一个技术经理最好每周都有面试,因为好人的窗口期是很短的,所以我们时刻要敞开,另外一方面也是保持时刻对外的一种开放视角,看看不同的人,不同的趋势,招聘是一种很好的学习。

谈招聘新人的时候,我们还是面对一个问题,就是公司是否在招聘问题上领先于竞争对手,在我看来,要把技术招聘给做好,必须有一下几个要素:1)专职的技术招聘的HRBP,不仅仅有技术人员的招聘经验,可以提供建立筛选和候选人,而且能够跟你讨论JD以及人的可能来源,同时在发出offer后进行后续跟踪,同时在试用期能够帮助评估候选人,几乎整个就是半个经理的角色。2. 对于核心员工的股票期权激励体系,现在股权期权已经被广泛接受,如果期权池没有建立或者期权不够吸引人都会无法吸引最优秀的人才。3. 明确面试的标准,对面试官要有培训和梯队,面试流程的规范要点,对于招聘失败的经历需要有总结流程,避免重蹈覆辙。

从第七条开始,是团队的提高篇了。我一直有一个观点,那就是看这个团队是否重视人,就是看这个公司的HR在做什么,如果只是发发工资,开开证明,这个公司必定不重视人才。一个创业团队如果真有远大的理想,期望成为独角兽,他的用人标准起码要跳三级,倒不是说一下子就要有非常高的标准,但是他对于优秀人才的获取能力必须是业界领先的。真正能够改变团队基因的只有人,而能否找到人又是HR的主要工作,这就是为什么Facebook会说招人是公司最重要的事。

8. 文化即管理

文化是什么?文化就是一种软性的管理,文化体现在我们奖励什么和惩罚什么之上。第四条谈到丫丫学步,我们的管理规则如果按照那种方式往下走的话,一定会出现大量的规则,直到出现一个拐点,那就是随着管理制度的推出反而效果变差了。之后的很多的管理制度可能是需要减少的,而更多的是通过文化来体现出来的。文化是一种柔性的管理,是把崇尚的价值观用潜移默化的方式来影响每个人。

比如,百姓网以前有个乐高文化,每隔两周会做一次技术上的PK,最终技术上胜出的人会得到一块乐高,我们就会看到很多技术人员都会在自己的桌上放着那块乐高,换位子的时候别的可以落下,这几块乐高肯定不会落下。为什么?这是一种荣誉,具体是怎么PK的,一开始我们的做法是出题,然后分成小组来写,然后对比各自的方案。后来因为时间有限,我们就采取了另外一种方式,就是每个人来展示一下自己最近写的一个新模块,或者小改进,这个模块是可以被别人更有方便高效地使用的,就像乐高一样,简单而有效。然后最后大家投票来决定这个哪个模块是最佳的“乐高”。这种比赛不仅仅是技术能力的一种展示,而且是一种做事习惯的影响,就是要创造简单可以来的乐高出来。

我们有太多的管理是简单而粗暴的,文化的力量就是创造出一种环境的力量,让你在工作的同时享受快乐,而不是被逼迫的感觉。比如说加班文化,我承认被迫的加班是无意义的,那种看着别人都在加班自己不敢走的状态是特别不好的和无意义的。好的文化应该是人自愿地加班,有选择地加班,干完活了就走,可以早早的走,每个人都选择自己最高效的节奏。有人说这个怎么做到?我的建议是这样,一是把学习和交流放到晚上,加班工作和加班学习是两件事情,有学习的机会而不去学习,这对于工程师来说是不可接受的。二是让结果透明,多劳多得,做同样的事情,优秀的人可能只需要4个小时,而烂的人可能12小时还干不完,所以问题不是在于表现加班还是不加班,背后的原因还是在于做的好的人没有理由做得更好,而做得烂的人也没有得到因由的惩罚。让优秀的人更有干劲,更能被认可才是关键。三是适当的时候做一次冲刺,适当的时候让团队承担巨大的压力,只有在压力之中才能激发出团队的战斗力,看看人的表现,但是之后又要适当地放松一下。

9. 真金要用火来炼

大家都知道巴菲特的滚雪球理论吧,找到一条长长的雪道,雪道上潮湿的雪,一旦滚动起来,那就会成为巨大的雪球。这两点在技术团队里面一样适用,长长的雪道就是公司的业务发展的规模体量以及速度,潮湿的雪是团队凝聚的力量,公司的业务发展越快,雪球越大,吸收新的雪的能力也越强,他的滚动速度也越快,一旦滚起来,那就是强者更强的一个过程。

如果你去问一个优秀的技术人员他什么时候的技术提升最快,他一定会跟你绘声绘色地讲一个故事,在哪一年的时候,当时业务的发展速度太快,导致系统的各种顶不住,然后用了各种方法来进行提高,解决了一个问题又解决了一个问题,直到系统变得稳定之后,反而有一种失落感。我们把这种现象叫做跑得连鞋子掉了都没时间穿的情况,这是一种非常好的状态,在这种状态下,团队会跑的很快,而且不需要做过多的管理,自组织,配合就会体现出来,跟不上的同学会自然掉退和被淘汰。由业务快速发展本身产生的驱动力会让团队的成就感和信心大大提升,战友间的感情也会特别深。

只可惜的事情是这种情况可遇不可求,如果一个公司十年上市的话,最多只有两三年时间能够有这样的黄金状态吧。但是这确实是团队锻炼最黄金的时间,让业务的压力来驱动团队跑起来。

0. 做好失败的准备

如同公司转型一样,团队转型面临的风险也是巨大的,因为我们是在和习惯在做斗争,就像开始的时候说的,他不是治疗感冒药到病除,而是治疗癌症,是基因的扭转。首先最大的观念因素来自CEO和技术带头人是否有这样的认知,其次是业务推动方向上能否有效配合和目标清晰,然后是HR的配合能够找到合适的人选,最后还要感谢上天眷顾给予我们时间让业务发展起来且不要被竞争对手灭掉。

如果你有幸成为这个扭转乾坤的人,那么恭喜你,这是人生宝贵的一段修行。

Leave a Reply

Your email address will not be published. Required fields are marked *