如何打造高绩效的研发团队

作者介绍:王建志,汉诺云创教育科技有限公司CEO。近20年IT企业工作经验,曾在华为、支付宝、链家、好大夫在线,Sybase等多家企业担任架构师、CTO、CEO等职位。熟悉汽车新零售、在线医疗、房产、旅游和支付等多个业务领域产品的建设和开发。

小编寄语:老王有多年的跨行业的架构、研发管理经验,供各位读者参考。技术管理有意思在于它是一门实践的学问,不同背景不同经历不同视野,看到的东西会不一样。尽管如此,乐于分享的“技术琐话” 带给大家的,也期望可以看到些普遍性的知识点,欢迎大家在文后留言讨论。

如何打造高绩效的研发团队

本文尝试回答几个常见的研发团队管理问题:

1,研发团队在企业不同阶段的重点工作是什么,怎样做到高绩效?

2,初创期团队怎样快速进行业务支撑,怎样从0到1建设研发团队?

3,扩张期团队怎样保证系统稳定,怎样完成高管的空降着陆?

4,稳定期团队怎样建设专业体系,怎样利用技术反向推动业务的发展?

基于自己的实践,本文试着用链家丁丁优房、好大夫在线和支付宝在所处特定阶段的一些实践和思考,回答一下上述几个问题。

互联网公司研发团队的工作职责是什么?

在回答上述几个问题之前,我们需要搞清楚在一家互联网公司研发团队的工作职责是什么,总结为一句话:通过技术管理手段完成产品研发工作,配合实现公司整体业务目标。

下图用来说明这个观点:

对上述的几个概念这里做一下澄清。

研发计划管理:进行技术规划(技术、人员、系统)。

研发项目管理:制定研发项目管理流程,持续提升技术开发能力。

研发质量管理:保证系统高可用,进行技术攻关,快速解决问题。

研发人员管理:进行技术团队梯队建设及日常管理,提升工作效率。

技术前瞻:对新技术、行业动态保持敏锐的感知度,对公司未来技术发展走向提出指导决策。

互联网公司都有哪些不同的发展阶段?

这里简单的划分了一下:

在不同的阶段研发团队面临的问题各不相同,采用的管理方式也不一样。

案例一:链家-丁丁优房

这个项目处于初创期。

项目背景是:

1, 链家和爱屋吉屋竞争,推出互联网移动租房产品丁丁优房;爱屋吉屋是一群互联网人做的房产项目,完全是互联网的做法,从上海开始,做租房,只叫500元佣金;然后来到北京开始租房和卖房一起做,卖房只收1%佣金。这种低价策略很受客户欢迎,也融到了很多钱。但是这个事情动了链家的蛋糕,所以链家要进行反击;

2,采用互联网的做法,线上获客,低佣金。

公司要求是:

1,从论证到产品上线一共2.5个月,先打广告后上线;

2,产品计划/营销计划/组建团队同步进行。当时是15年12月27日接到的工作,准备了几天开始进场,16年元旦休息了一天,春节休息了三天。3月1日会在北京200块地铁站台上正式投放丁丁优房的广告,钱已经花出去了。另外销售团队是链家5000名租房销售,人都已经切换到丁丁这边来了,就等着线上产品了。

业务要求是:

1,业务流程全线上,包括:签约/支付订金/支付租金/开发票;

2,上线时间倒推;

3,销售团队已经ready,就等着线上产品开始工作;

4,主流程无问题,可以带着小问题上线,业务需求主线就是一个完整的交易流程。这是个纯移动端产品,包括:客端APP、销售APP、运营后台系统,主要是销售等着客端线索呢。

常见问题是:

1,研发人员少,需求多,上线周期长,以月为单位;

2,线上产品问题多,出现问题处理不了,客户体验差;

3,研发过程混乱,各个团队之间冲突不断;

4,研发团队长时间加班,团队人员抱怨多、氛围差;

5,从0到1怎样快速组建团队。从0到1的过程总体上用了50多人,70多人次,中间换人很多。上线后问题不多,但是出了问题不好解决,因为开发测试都不充分,都是隐蔽的问题。

开发过程中基本都是人盯人,没有流程保障,人治。研发基本上10/12/6,有一个人中间有事儿项目都会出现风险,春节后有个别核心员工不能按时回来。

从0-1建设团队因为当时是自如的技术负责人,所以到了丁丁这边做CTO,是从自如带了几个核心技术过去的,产品是从链家本部带了一个总监进来的,元旦后市面上流动的不是太差的人我们都招进来了,所以有点死马当活马医的感觉,哪有什么自行车啊。但是这时还是需要淘汰,淘汰那些不合群的,干活不是太差的就留下了。

预期表现是:

1,研发团队能快速地交付产品,配合业务试错;

2,系统问题少,有了问题解决速度快,客户体验好;

3,研发团队项目流程顺畅,各司其职;

4,研发团队工作目标清晰,人员主动性好,氛围融洽。这个产品的主要困难是销售团队不知道他们的工具应该是什么样的,需求变了几次,所以试错主要在销售端上了,改来改去。

考核指标是:

1,这个阶段通常不需要设置研发团队KPI;

2,主要工作目标是快速交付。当时的KPI就是按时上线。

高绩效标准是:

1,研发团队有工作计划,有推进的关键节点;

2,研发项目交付速度快,业务可以迅速试错;

3,系统质量保持可用,出现问题能解决。做这种项目,前期主要还是要想清楚,关键流程,关键设计,主要风险。项目交付不及时大部分情况是技术过于乐观,理想化了。这个时候质量也不是最重要的,保持可用即可。

怎样达成高绩效:

1,理解业务制定研发计划,关键节点要实时开会同步给全员;

2,0-1的项目研发团队采取封闭/半封闭方式开发,突击实施;

3,1-N的项目采用小步快跑的方式迭代,以周为单位发布;

4,项目管理只执行必要环节,流程尽可能短;

5,底层技术不单独投入时间,使用已有成熟技术;

6,可以不建设测试团队或建设测试小团队,负责主干用例测试,其他测试由产品经理/开发参与完成;

7,有了故障,各部门负责人进行技术支持。从0到1的项目主要采用封闭开发,50个人在欢乐谷自如寓住了2个半月,分了三个屋子工作,当时个别人在春节期间把家属也带来了。这个情况下要高绩效,就是几个关键负责人要靠谱,自己能做关键代码,别人出问题时自己还要能顶上,现在这几个负责人都在大公司做总监了。

面临挑战: 

1,研发人员短缺,研发职能缺失;

2,研发人员以新人为主,管理流程、项目流程缺失;

3,研发团队对风险抵抗力低,人员变动会影响整体进度;

4,前期需求泛滥,需求调整频繁。挑战中新人这个是最大的坑,主要是对业务不熟悉,毕竟链家积累了这么多年,还是有一套标准的线下作业流程,这个是逃不开的。所以这个地方就是靠大量的沟通,和天天耳根子边上叮嘱风险、监督结果。

思考逻辑:

1,团队目标必须一致,过程中要实时同步信息;

2,项目落地越快越好,项目周期越短越好(一、两周为佳);

3,项目流程尽量简单,实用就好,设计、计划环节不可少;

4,项目质量尽力而为,不求完美,故障响应要及时;

5,人员选择适合就好,不要太过严格,早期人员风气要正。在这个项目1.0结束后,把项目发布周期调成了两周发布,后续调成了一周发布,最后是一周Android两发、iOS一发。项目流程采用的瀑布+看板,周报跟进进度。

初创期小结:

初创期研发计划,项目管理要做好。这时质量不是最重要的,人员管理和技术前瞻都不需要花时间,靠的是人员的自觉性。

丁丁优房这个项目最终失败了,原因很多,最主要的原因是没有按照精益的方式,以客户为中心来进行项目的落地,想当然了。

案例二:好大夫在线

项目背景是:好大夫在线B轮后,业务全面商业化。好大夫是2006年创办的公司,天使是雷军投的,公司三位创始人都是360的。在B轮之前一直做免费的业务,没有任何收益,从B轮之后开始进行商业化探索。

公司要求是:

1,业务项目尽可能快;

2,商业化产品必须要有极致的用户体验;

3,底层技术资源投入只给10%的资源。当时公司有700多人,近200人研发人员。之后研发团队快速增加到近280人,公司总人数900人。公司分了5条业务线,产品团队有80人。

业务需求是: 

1,APP每日不能有重大的问题;

2,系统高可用性99.5%;

3,项目周期不能大于1个月。尤其是医生APP,每天不能超过3个BUG,或者一个问题不能有不同的医生同时报。项目周期之前是2-3个月一次发布。

常见问题是:

1,系统故障多,客户体验差;

2,出现故障无法解决或者解决时间较长,客户投诉多;

3,研发人员消极怠工,抗拒工作或是裁剪需求,达不到业务预期;

4,高管空降难落地。 

因为所有产品都在医生APP和患者APP上,出现故障时没有流程,没人牵头解决,一片混乱。通常需要半天的时间恢复,主要是重启服务。

说到高管空降的问题,这个里面最主要的是个人心态,你来的时候需求是什么,你的个人底线在哪里?如果你的个人需求公司能满足,那就看什么时候突破你个人底线了。

但是高管没有好当的,脑力、体力和心力,最考验的是心力,彭蕾说的皮实。高管落地三板斧:一、搞清业务;二、搞清人员;三、一个月左右开始做一件有挑战的事情获取CEO的信任。

在好大夫在线做的第一个项目就是VIP面诊,这个就是以前提过的,CEO要0.5个月上线,CTO说1个月上线,技术总监说2.5个月上线的项目。这个项目要说又是很长的一个故事,但是最关键的地方还是专业性帮了忙,懂专业的技术管理者是会有办法克服难题的。

预期表现是:

1,系统故障少;

2,故障处理时间尽可能短;

3,研发团队专业负责,效率高。故障处理时间要求5分钟响应,10分钟上报总监,15分钟上报CTO,30分钟上报CEO,这玩意会把人害死啊。

考核指标是: 

1,更短的项目交付周期,每周发布两次;

2,系统故障个数有要求,每天<=3个;

3,专业团队加入考核指标,比如运维安全故障每月<=3个。在接手的时候,JIRA上有700多个BUG,沉寂了4、5年,在6个月时间清零了,嗯,这又是一个单独的故事,比较复杂。

高绩效标准: 

1,研发团队有工作计划,有推进的关键节点(夯实);

2,研发项目交付速度快,业务可以迅速试错(夯实);

3,要求系统高可用指标99.95%;

4,出现问题要马上解决;

5,进行专业团队体系化建设。这个时候公司要求做团队氛围建设、体系建设、考核、文化,一些形而上的东西来了。主要是怕技术人员划水,恨不得在工位上装上摄像头。但是自己一直觉得,CEO看CTO或者技术团队靠不靠谱不是看一两个个别问题事件,还是要看总体业务发展瓶颈来自哪里,是技术团队还是别的什么团队,如果不是技术团队就不用这么不信任了。

怎样达成高绩效:

1,提升系统交付能力,缩短上线时间(更高标准);

2,从系统可用到系统高可用,建设专业体系,包括:项目管理体系、业务开发体系。

——技术架构体系,底层技术投入专门资源建设:运维自动化、测试自动化;

——建立技术委员会,打破部门墙。

3,团队管理方面:团队组织架构建设、团队氛围建设,重视核心员工的培养和留用;

4,月度沟通会让信息透明;

5,有了故障,技术支持部门牵头系统Owner进行技术支持。

技术委员会是一个横向组织,便于提升协作效率,但是实践起来还是经历了很多坑。从纯虚拟组织,到庞大的实体组织,到独立的架构师团队,到技术委员会+架构师团队推进工作,经历了几次组织架构的迭代。

阿里的owner制是个非常好的核心人员参与公司发展的好实践。

面临挑战是:

1,多项目管理难度大,风险控制难度加大;

2,团队人员上百人,沟通成本加大;

3,涵盖专业多,能力需要全面提升,需要引进专家型人才;

4,向上管理和平行管理难度加大,需要提升研发团队影响力。团队人数多的时候,管理的最大难度在向上管理和平行管理了,一定要不断地提升研发团队的整体影响力,以客户体验为前提进行工作,CTO以公司利益为先的角度去思考协作问题。

思考逻辑是:

1,在快速交付项目同时要保证系统稳定,需要建设基础设施;

2,夯实团队组织架构,打通内部横向部门协作;

3,需要得到CEO/业务部门/相关部门信任,因为犯错几率增加,需要有一定的容错度;

4,人员选择执行力强,有成功经验者。这时要开始考虑效率提升的问题了。

扩张期小结:

质量是一个必须做好的新工作。质量提升要求流程制度建设和专业体系建设,开始考验真本领了。这时团队的管理、专业能力高度必须进行提升,否则一定会出现不能实现的工作。

当时我们遇到了一个非常头痛的问题就是安全问题,一段时间常常被攻击,一旦出现整体宕机几小时还没有办法,后来想了很多的方法,花了一些早该花的钱把问题解决了。好大夫C轮拿了百度的投资,在商业化这步上走稳了。

案例三:支付宝

项目背景是:2012年,支付宝从单一靠淘宝转型到生活支付全场景,其实那时的支付宝绝大部分交易还是来自淘宝。

公司要求是:全年高可用率从99.95%到99.99%。研发团队有几千人了,服务不可用几分钟就是几百万损失。所以技术团队当时的主要任务就是服务化,去IOE,双11是工作抓手。

业务需求是:

1,底层架构升级满足高可用指标:弹性计算、容量可评估、运维自动化、自动扩容;

2,技术委员会:双11专项工作、底层架构升级;

3,专业体系打磨。这个时候都是在做精细化的工作,往往性能提升1ms,全站几万台机器效率就提升很多。当时技术委员会是鲁肃牵头,也学到了很多。

常见问题是:

1,一般问题不多,偶尔出现复杂问题,影响客户体验;

2,研发团队规模已经几百上千人,整体协作效率需要提升;

3,需求发展速度快于团队成长的速度;

4,怎样利用技术反向推动业务发展。阿里有一个企业成熟度模型,基础设施/持续优化/知识共享/业务敏捷/业务革新,前面三个做到了业务就会快起来,业务能够快起来就可以对业务产生革新的效果。前面三个工作需要技术不断地进行创新,在这里面做了很多技术上的尝试,比如MYSQL内核优化,SOFA服务框架优化,XXX优化。其实这些优化就是我们常说的在高速行进中换轮子。

预期表现是:

1,对于故障可以提前预判进行演练,避免出现;

2,团队管理更加规范,制度流程打磨的更加实用;

3,技术委员会这样的横向组织要有效提升工作效率;

4,研发人员工作积极,自主性、创造性加强;

5,技术处于行业前列,能够引领新技术的运用。双11之前需要进行容量评估,支付宝当时的容量评估不是在线下模拟环境,然后进行放大计算,而是真实的线上容量测试,这个是需要大量的工作和尝试的。

考核指标是:

1,高可用性是主要考核指标;

2,研发人员的选用育留指标;

3,对技术创新、新技术使用上进行考核。提倡创新文化,让更多的人发声,更看重人员的发展和贡献。当时有很多人刚刚毕业,一年可以升两级,这个现在是不可能了。

高绩效标准是:

1,高可用性继续提升,倒逼专业体系精细化建设;

2,团队管理作为首要任务,制定制度,进行团队氛围建设,加强研发文化建设;3,发挥技术委员会横向打通部门的作用;

4,建立整体技术影响力,在行业里新技术运用上要有创新。高可用性、服务治理、弹性计算、自动扩容、zPass、ZDass,支付宝内部做了很多东西,这种创新环境来自于业务需要,来自于技术主动创造。这种创新的氛围不是闲下来做出来的,是实实在在服务于业务的。

怎样达成高绩效:

1,高可用性成为带动整体研发团队工作的抓手,人人以质量工作为重;

2,技术委员会操作要简单实用,从客户中来到客户中去;

3,鼓励创新性工作,重视研发人员的选用育留,将人员视为第一资产;

4,季度表彰会,建设组织氛围;

5,有了故障,全员7*24小时进行技术支持。支付宝故障响应小组很牛,主要是运维部门牵头,有了问题不管多晚都要马上出来。晚上上线时也很好玩,一起买烧烤。

面临挑战是:

1,人数多,部门多,流程多,怎样能提升效率;

2,管理力度不好拿捏:管理过松,组织涣散;管理过严,人员没有参与感、成就感,人员创新能力下降;

3,研发工作无法度量:人员工作量化、可视化是难题,容易让人产生效率低的错觉;

4,各部门开始闭门造车,重复建设;

5,对新技术要有足够的把控度,然后再尝试运用。大团队管理主要靠流程制度,需要法治社会。另外,团队的文化很重要,在出现冲突的时候文化很好用。

大团队里面有个技术的坑是,很多新人初生牛犊不怕虎,来了什么都敢改,觉得哪哪都是问题,这个是无知者无畏,需要团队新人多注意。

思考逻辑是:

1,考核、管理还是以严厉方式为主,保持高执行力;

2,持续找到团队中的专业和人员短板,不断补短板;

3,做工作实用性为第一要素,一切工作以客户可感知为原则;

4,重视人的作用,鼓励个人创新和主观能动性;

5,人员选择能让公司转型的开拓型人才。实用性是做技术人的第一要素,这和练武术一个道理,花拳绣腿大不了人的。实用性的最高境界是工作结果客户可感知。

稳定期小结:

这时研发人员管理和技术前瞻是新的工作重点。

支付宝虽然没有摆脱淘宝是它第一大交易订单来源这个事情,但是像双十一这样超大规模数据量的技术难关是过了。

总结

总结1: 公司不同阶段研发团队的重点工作变化

总结2: 研发团队工作职责本质是什么

研发团队思考是前提,执行是态度,质量是能力,效率是产出。

总结3: 如何打造高绩效的研发团队

看了这么多工作要做,大家是不是觉得有点头大,对的,如果想让一个团队高产出,还是真得要搞定这里面的全部事情。

参与相关讨论,请在公众号回复关键词:读者群。

参与相关讨论,请在公众号回复关键词:读者群。

 往期推荐:

— END —

技术琐话 

以分布式设计、架构、体系思想为基础,兼论研发相关的点点滴滴,不限于代码、质量体系和研发管理。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值