【ArchSummit架构师峰会】探讨数据与人工智能相互驱动的关系>>> 了解详情
写点什么

从 1 到 1000,业务拉锯战中如何打造一支千人精英研发团队

  • 2016-09-20
  • 本文字数:4937 字

    阅读完需:约 16 分钟

本文根据张海龙在中国技术开放日苏州站走进同程的演讲内容整理而成。

ArchSummit 北京站即将在 12 月 2 日开幕,更多专题讲师信息请到北京站官网查询。

张海龙,同程旅游联合创始人,现任同程网CTO, EGO 会员,ArchSummit2016 深圳站明星讲师

我心里一直有个梦想,就是希望有一个舞台能让更多的技术人沟通、交流,展示他们自己的一些成果。

同程有一句话:“再苦也不要忘了读书和学习。”这是同程价值观。我觉得技术人一定要坚持一个价值观,否则,你可能会被不断涌现的新思想、新技术所抛弃。虽然很多技术并不是所有公司、所有人都会使用,但是我们需要接触新想法、思路和技术,知道这些技术的应用场景可能对将来会有帮助。同程团队最初只有几个人,从困难、迷茫的阶段,发展到现在这个规模。我希望通过我自身以及同程研发的一些变化,能够给大家一个启发。

关于同程

首先,我分享一下同程的十年演变,包括团队变化,以及我们遇到的一些问题。不论是5 个人的团队,还是50 个人、500 个人团队,我希望同程的演变历程可以让大家得到一些借鉴和共鸣。我带领团队遇到很多挑战,然后看到其他创业团队的变化,譬如腾讯的变化,于是便确定我们的方向是正确的,遇到的挑战也是正常的。

同程研发发展历程

业务初创期

同程于2004 年成立,图中照片是针对第一次招聘开的会,当时人很少,只有5 个人。我相信也有很多团队目前处在这个创业阶段。当时整个研发没有任何体系,人来了就是“干活”,没有激励的制度、方法,员工也很难招,唯一能做的就是自己带头、自己写代码,这个状态一直延续了很长时间。

后来,最根本的线上竞争已经不是流量,我们更多是往线下、往区域去落地,这个时候研发人员也更多了。研发团队成立了一些区县的管理组织,研发能力模型也继续推行。过去研发团队可能都会埋怨:业务牵着研发的鼻子。但是当真正自己掌握主动的时候,我们发现在产品、系统需求上,研发人员的思考还不够。这也是我们接下来要去重点拓展的。

业务探索期

然后是业务探索期。我们当时是做B2B 的平台,做了一个行业软件,人员增加到15 人。当时我们的团队活动就是唱歌、聚餐,人员的流动很大,整个团队的吸引力和凝聚力等方面都比较弱。

业务拓展期

在业务拓展期,我们开始做B2C 的预订。同程分成两个产品,一个是B2B,一个是B2C,规模达到15-100 人。开始有了月度会议的表彰、户外拓展等激励方法。这是跟业务发展紧密相关的。领导团队也有了一些挑战,需要分工。我自己当时就是从开发到DBA,再到服务器,一个人做所有事情,这并不是好现象。

业务转型期

然后到了转型期的时候,同程业务完全聚焦在B2C 上。B2B 的用户量有限,而B2C 是面向全国的用户,其用户量和访问量跟B2B 完全不一样。业务线增加以后,研发人员也增加了,我们设置了研发负责人和政委。同程还向阿里学习,HR 不仅仅是HR 的角色,还做很多关怀同事、关怀团队的事情。大家都知道,B2C 的预约变化非常快,业务需求也非常多。做B2C 的时候,同程业务又变为以流量为主,业务部门都承担业绩指标。

业务扩张期

当研发团队在扩张的时候,很多人也会质疑:这么多研发人员,效率到底怎么样?

研发团队有很多公共职能,比如短信、邮件、电子传真等,这些都是需要公共团队独立去做。这个阶段,也是公司的快速扩张期。业务会埋怨,业绩完不成,是因为系统、想法没有变现。于是,很多压力就会传递给研发,研发就需要扩充更多的人员。但是大家知道,招人或者扩充团队是非常困难的。

研发涅槃期

2014-2015 年是同程研发的涅槃期,这个时期跟过去相比有焕然一新的变化。成立了研发中心,现在的事业部就是当时无线开发部的发展和壮大。两年时间里,技术研发做了非常多的革新,有了自动化部署、运维,高效的前端开发。人员扩充到 800-1400 人,同程研发的能力模型体系建立了。当然,也遇到更多的挑战、部门的矛盾、新旧技术的碰撞。很好的是,我们坚持了对的方向。

后移动时代及区域落地

有过组建研发团队经历的人一定说过这样一句话:公司投入不足。公司要发展研发,但是投入不够,人员不好招,技术好像也不是那么先进、主流。我相信很多人都会碰到这些问题。这里简单探讨一下,人员快速扩张的时候,人员从哪里来?同程是这么做的:一方面通过招聘,更多一方面是培训部专门培训员工,不管人员是刚刚从学校毕业,还是非常喜欢做开发,同程通过培训班制度定期输送研发人员。

研发管理探讨

随着公司业务的规模、团队扩张,如何营造研发团队的学习和技术氛围呢?同程内部有一个挺有意思的现象:研发团队会要求公司提供培训环境,但是当真正有培训的时候,他们又会因为忙而无法参与。这个矛盾如何解决?一方面,我们会提供更多的培训。另一方面,内部经常会做技术的 PK,只有 PK,大家才能发现自己实力水平或者差距。我觉得,差距是最好的动力,学习一定要保持好的心态。

带过团队的人也许都会遇到这种情况:同事突然有一天要求辞职,可能是去创业,可能是回老家买房结婚,各种各样的原因。同程最早期的时候,一个同事说要去创业,我至少挽留了三次,因为那个时候团队人很少,走一个人觉得挺可怕,但是我也不能说创业不好,当时我非常纠结。但是,现在我知道每个人都有自己的发展方向,一定要去体验之后才有认识,如果他不迈出那一步,他不会放弃。

那么,平时我们可以跟同事多沟通,知道他们的困难,及早发现这些问题。另外,多储备一些后备人员,这样应对人员的变化会更有把握。

我们团队有两大类研发,一类是做业务的应用系统,一类是做基础技术。研发人经常会困惑,为什么每天要不停地修改业务、数据库。确实,我也有过这样的困惑。也许修改数据库的技术并不是高精尖的技术,但是这些工作可以让研发人员能够真正懂业务。去年同程对研发做了一些创新,我们发现真正了解业务的研发,能够更好提升业务人员的效率。

那么,研发人的发展路径是什么?是做技术管理者,还是做技术深入挖掘的专家,还是做懂技术的产品经理?我认为这些都是非常好的方向。惟有一点不好,就是你不想学习,“我这样就可以了”,这真的是会影响你的发展。

我们一直很缺乏技术研发和业务研发。但是,目前我们更缺少懂业务、研发出身的产品经理。在接触了很多系统、需求之后,能不能将其变成你自己对于业务和流程的思考和理解,我认为这个其实更有价值。

在技术提升和业务需求之间,怎么平衡技术需求时间?

现在公司不再要求研发“必须在什么时候做完”,而是由研发自己控制。但是前几年更多是业务要求研发必须在哪个时间点做好。我们有一个小方法:排期任务的时候,不会把 100% 同事排进去,排百分之七八十就可以了,要给自己留一点时间。我们公司很多需求都会排到 6 个月之后。

几年前曾有这样的质疑:为什么不能很快变现提出的新业务,是不是研发人员不够?后来,公司对这个问题释然了。第一,业务同事,包括公司老大,发现所有的研发团队、互联网公司都是这样,没有哪个互联网公司敢说能够满足所有需求。我们应该多出去交流,然后把信息传递给同事、公司老大:我有我的计划,但是永远不可能满足所有的需求。

具体问题探讨

前几年,每个团队都喜欢做自己喜欢的事情,后来发现术业有专攻,每个人有每个人的特长。所以我们开始内部 PK,谁能够 PK 胜利,就用谁的东西。最后分出公共研发和技术研发部门,他们做出的产品要对其他研发部门负责。

研发团队的工作成绩和效率如何评估?从研发的角度来看,做到几个任务点,这个研发就是不错的研发。

针对业务需求,我们提出有效需求的完成率。什么是“有效需求”?前几年业务提出的任何需求,研发都会去做,但是可能 30% 都是无效的。我觉得作为研发的负责人,有责任向公司要求:我可以完成,但是必须是有效的需求。业务提需求,研发认真评估会给业务带来什么效果。上线之后,再看看实际效果。如果发现业务提出的 10 个需求有 5 个常常无效,那么完全可以要求公司给研发更多的自主权。

还有价值创造。这么多研发工作,到底为业务部门、为技术提升带来了什么样的变化?价值创造是所有研发同事、研发负责人要去关注的。

最后两点是创新突破和业内水平。基于每个公司的规模和特点,观察同行业里面对标的公司,看看它的研发水平。然后再把这些信息让公司所有人知晓,这样公司老大会更理解研发,可以评判是否有差距、持平,还是超越。

同程研发的体系方法

最后讲一讲同程做研发团建的实践方法。随着团队的扩张,我们需要一些方法来完善招聘、管理、工作等方面。

在招聘方面,我们有培训班制度,培养更多新人,使用内部推荐技术。另外,虽然每个人都非常忙,但我们希望老人带新人,这是非常好的智库。在人员晋升、考核上面,我们会有一些制度,去鼓励、推动大家带领新人。在人员方面,我们也坚持“价值观第一”的原则。每个团队有自己的特色,大家在一起工作,首先第一点要相互认同。

在管理方面,我们会有一些晨会。可能很多人会疑惑,研发开那么多会议干什么?会议时间从 5 分钟到 30 分钟不等,最重要的是,希望通过会议让同事得到什么。还有政委制和竞聘制。如果出现一个岗位需求,并不是指定谁来做,而是大家竞选应聘。我们实施了评审制,虽然累,压力也很大,但是对于整个团队非常有帮助。工作方面有专项制、过堂制、价值、创新、技术日、产品发布会、基础研发。我们希望研发多发出自己的声音,更多地向业务、公司展示自己的成绩。研发相互之间,也应该相互学习、相互借鉴。

我们在招人宣传的时候,也关注这个人对于技术的兴趣和热爱。就像我们内部想要做一件事情,并不是为了某个利益目的,而是出于自发,这一点对于所有的研发团队都是非常重要的。另外,对于所有的研发管理者来说很重要的一点是,在每个人工作压力比较大、工作任务比较重的情况下,应该创造一个简单、相对轻松的工作环境。

Q&A

问:我也是个程序员。很多时候,我们读到一些文档,发现一个新技术,很想学习一下。我们如何在有限的时间里面,全面提升自己这样的能力?

张海龙:以我个人的经历来说,我觉得只有一个办法——花更多的时间。你花时间,但不要什么都学。现在有一个误区:很多语言很流行,也好像是将来的趋势,开发人员都想学。但是在同程,现在还在用 Java。你的工作确实需要哪一门技术,你就学它,只要把一门语言钻研透彻。我不鼓励大家去跟风“听说这个很流行,尽管我不知道应用在什么地方”。

我觉得小团队的好处是,可以让你做所有的事情。大团队的好处就是,你可以很专一地做一件事,可以接触到以前没有机会学习的知识。有人问:“毕业之后,先进大公司还是先进小公司?”我的建议是先进大公司,先要了解技术体系,具备比较全面的知识。工作四五年后,可以去创业。除了技术,还要面对更多的人,会遇到更多问题。

问:怎么样自下而上推动一些事,因为我相信在最底层的人可能会发现一些最常见的问题。这方面,我想听一听您的一些看法和建议。

张海龙:三四年前,同程还是从上往下做事情。经过了 2014-2016 年的涅槃期,现在最上面的人已经不知道底层在干什么。我唯一能做的就是支持,“你去做,只要做的事情是行业里面主流的,只要对业务是有帮助的,只要对同程是有帮助的”。

很多人总是要求培训,但是真正有培训机会的时候他又不参加。我个人觉得这跟团队的“人”是有关系的,核心是人,而不在于“我”。你为什么做技术?你是想有一口饭吃,还是你非常喜欢,哪怕不睡觉也要把问题解决。如果你找到的是前一种人,觉得研发的工资比业务高一点,做研发好像挺牛气,那么一定是 Leader 催促着他完成工作。如果你找到是后一种人,你会经常发现同事的想法太好了,就应该支持他。

现在同程的很多事情,就是下面的同事去推动的。我不会要求业务系统应该做什么提升,我只会说希望这个月能够拿出一个比较好的创新。当很多部门产品进行 PK 的时候,主动学习的氛围就形成了。技术人一定要热爱技术。很多技术能力很强的人,并不是科班出身,只是因为喜欢技术,只要解决一个技术问题,掌握一个技术难点,他就会很满足。

当技术能力强、主动学习的人越来越多,这个团队就会变成自下而上的结构。这个时候你唯一要做的就是给大家机会和空间,让他做喜欢做的事情。


感谢陈兴璐对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ @丁晓昀),微信(微信号: InfoQChina )关注我们。

2016-09-20 17:242119
用户头像

发布了 90 篇内容, 共 12.7 次阅读, 收获喜欢 10 次。

关注

评论

发布
暂无评论
发现更多内容

继续,来看看 TiDB 3.0 在 AP 方面的进步

TiDB 社区干货传送门

DM的dmctl中sql-skip使用

TiDB 社区干货传送门

补充 RECOVER 导致 TiDB Binlog 同步错误处理

TiDB 社区干货传送门

【精选实践】TiDB 在 360 商业化的应用和实践

TiDB 社区干货传送门

Spark Standalone集群升级步骤

TiDB 社区干货传送门

TiDB 在转转的标准化之路

TiDB 社区干货传送门

TiDB 在 UCloud 公有云上的实践

TiDB 社区干货传送门

物化视图的更新

TiDB 社区干货传送门

转转业务开发对 TiDB 的使用心得

TiDB 社区干货传送门

TiDB在威锐达远程诊断大数据中心的应用

TiDB 社区干货传送门

TiDB 在实时渠道转化分析的应用

TiDB 社区干货传送门

查看 TiDB运行 内存快照分析

TiDB 社区干货传送门

使用 Docker-Compose 部署 HAProxy 为TiDB-Server 做负载均衡

TiDB 社区干货传送门

TiDB 事务源码阅读

TiDB 社区干货传送门

TiDB 拓扑查询工具qtidb

TiDB 社区干货传送门

TiDB监控实现--存活监控

TiDB 社区干货传送门

周末了,一起来看看 TiDB 的 AP 能力

TiDB 社区干货传送门

转转数据库架构构建之道

TiDB 社区干货传送门

Raft一致性协议简说

TiDB 社区干货传送门

【精选实践】随手科技在 TiDB 的探索之路

TiDB 社区干货传送门

谈谈 DDL 的前世今生

TiDB 社区干货传送门

一体化数据同步平台 DM 1.0 GA 发布

TiDB 社区干货传送门

易果 TiDB 的使用以及数据中台的思考

TiDB 社区干货传送门

Hands on! 如何给 TiDB 添加新系统表

TiDB 社区干货传送门

TiDB DM 数据库同步 step by step

TiDB 社区干货传送门

TiDB MVCC 多版本保存机制及其对性能的影响

TiDB 社区干货传送门

【精选实践】爱奇艺实用数据库选型树:不同场景如何快速选择数据库?

TiDB 社区干货传送门

TiDB 常见问题处理 - 热点

TiDB 社区干货传送门

TiDB 新特性漫谈:从 Follower Read 说起

TiDB 社区干货传送门

TiDB PD 组件代码阅读

TiDB 社区干货传送门

TiDB 私有云实践

TiDB 社区干货传送门

从1到1000,业务拉锯战中如何打造一支千人精英研发团队_语言 & 开发_张海龙_InfoQ精选文章