邮箱订阅

订阅即可免费获取优质的设计资讯!

邮箱订阅

感谢你的支持!

分享到微信朋友圈:

Close

打开微信,点击底部的“发现”,使用 “扫一扫” 即可将网页分享到我的朋友圈。

热门文章

Mockplus是什么?

Mockplus,更快更简单的原型设计工具。快速创建原型,一键拖拽创建交互,团队协作省事省力。微软、华为、东软、育碧、Oracle、西门子、IBM等全球知名企业和全球300多所高校都在用,你也可以免费开始你的设计!

了解更多

Facebook研发团队的高效秘诀

EGO 2015-05-05 20:49:04 阅读:27316 zaodula.com

4月22日晚极客邦科技旗下的技术人社交网络EGO首场活动在北京国际会议中心举行,阿里巴巴赵海平在活动上分享了Facebook研发团队的高效秘诀,一个是公司文化,一个是整个内部组织结构,最后讲Facebook的人,他的思维的方式是什么样子的。

4月22日晚极客邦科技旗下的技术人社交网络EGO首场活动在北京国际会议中心举行,阿里巴巴技术保障部研究员赵海平在活动上分享了Facebook研发团队的高效秘诀,以下为正文。

——————————

大家好今天主题是讲研发团队高效秘诀,我想说,我要讲的很多Facebook团队的特点,都是跟它的历史是有关系的。我会讲(Facebook)这个团队怎么样的从小到大,一点一点起来,才慢慢形成自己的风格。这个团队我其实并没有系统的研究过,我就简单的讲几个大的方面,一个是公司文化,还有就是整个内部组织结构,最后可以讲一讲Facebook的人,他的思维的方式是什么样子的。

Facebook公司文化:Hack

第一个讲讲公司的文化。这个文化特别明显,叫Hack,它不是说黑客,而是很快的把事情攒出来,攒出来之后不一定特别好,第一个版本往往很差,但是不要紧,可以后续再迭代改进。在Facebook早期的时候,总共就三四十人,每个人负责的事情很多,一个人要负责网页上的一大块内容,你其实没有很多时间把事情想清楚再做产品,你肯定是急急忙忙把它攒出来的。

于是慢慢形成这样一个情况,做任何一个产品的时候,第一个版本不在乎是不是做的好,它可能漏洞百出,但是我可以确定两三天或者三五天就可以上线,做出来后放到网页上马上就得到反馈,来自用户和周围同事的反馈,或者你自己看出毛病,然后你就知道朝哪个方向改,然后第二个版本就好一点,第三个版本更好一点。这个思路就是,我不求这个迭代很快达到我最终想要的那个样子,但要求每次迭代速度很快,这样很快我就朝着正确的产品方向走了。因为很可能你花了很多时间精力,坐那儿想了两三个星期,觉得这个东西不错,想的特好,然后推出去,结果用户发现这个东西不是他想要的。尤其我们在做面向用户的服务或者产品,经常有一种现象,你自己觉得不错,自我感觉特别良好,但是拿到外面,用户反映完全不是那回事。Facebook就是这些年从小到大,摸爬滚打中渐渐总结出这样的经验。

还有一点,恰好Facebook用的语言是PHP,PHP早年在公司争议特别大,我一进公司的时候大家就讨论说,PHP这个语言太有问题了,咱们要形容特别好的语言,说它像花一样,PHP简直就是草嘛(笑)。PHP的设计也有问题,或者某些方面很欠思考,结果就会发生很多奇奇怪怪的事情。但是,PHP非常适合Facebook早期发展的特点,就是特别容易去Hack,三五行代码就把一件事情做完了,当然这三五行代码深究一下都不完美,你可能用JAVA把这三五行代码写完是三五十行,会包装的很完美,但花的功夫也要远远超出。

公司早期说Hack这个词很少,那时候大家都忙着攒网页,攒这个那个,后来大家慢慢意识到Facebook的文化就是Hack文化。后来我们搬了很多次家,到最后搬到现在这个最大的楼,我们就在大的水泥地上写了四个大大的字母“HACK”。这个真的是一个公司多年文化的结晶。

即使到后来公司发展壮大,有了团队区分的时候,大家还是讲究这个,要Hack,不要担心自己的第一个版本不完美。因为人的思维永远是有局限性的,你就是坐那儿想十天,也不会说那个完美的程度达到十倍,想十天可能达到两倍的完美,这是不值得的,万一你产品更改方向,你不是白白坐那十天吗?所以说Hack文化是一个特别有效的手段。尤其我觉得公司还小的时候这招还是挺管用的,因为小公司没有那么多人力物力,不太容易把一个产品搞的那么完美,所以你可以Hack一下。

我还想说Hack是可以传染的,既然你Hack我也Hack。如果你Hack的话,我不用Hack就比你慢,这个人花三天时间就推出来,我不用就要十天。一旦形成Hack文化,它会慢慢波及公司各个方面,大家都开始Hack。但是大家不要觉得Hack是不敬业,或者对产品不追求完美,它只是说把对产品完美的追求分成多步去走。像是说你看我们公司都是什么什么学校毕业,都是能人什么的,但是我们不求把自己做的东西搞的很神秘很高大上,说要推出一个震惊世界的产品。初期的产品不用特别好,只要你做出来就行了。

Facebook早年的产品都是这样的,早年的照片分享功能看着就是一个很烂的东西,但是慢慢的发展到最后越变越好,现在非常受欢迎。每个产品都是给我这样的感觉——这样的产品也敢往上放,但是这些产品经过迭代也逐渐变好了。然后所有产品汇总起来,发现一些共性和特性,就成了社交网络Facebook。所以Facebook不是说一上来有一个人坐在这儿,说我要开始创建一个社交网络产品,发展方向是如何如何等等。而是从Hack一个个小项目发展起来的,每个人都从自己角度看这个社交网站是什么样的,Hack之后汇总再看,原来我们是要做这个,然后你在更高的层次上再推出产品,因为它有这个基础。

公司的文化在很大程度上就是这样一个词所总结的。其实我刚刚进公司的时候,并不是说我完全接受这样的文化,因为我是完美主义者,我的东西我一定要做的超级完美才拿得出手,但是跟这些同事一起共事,渐渐就领略到Hack的高效,它实际上有一个非常坚实的理论基础,我们也很幸运,在Facebook早年的时候,就吸取这么一个公司产品开发的一个做法。这是公司文化上一个很大的特点。

组织结构:去中心化,避免依赖

再有一个我想讲一下这个公司的组织结构。Facebook说白了,它就是一个非常去中心化的组织,并且尽量避免对别人的依赖。一个团队只管自己的事情,不但如此,在做自己事情的时候,尽量不依赖别人。这个也跟公司里边的人工作方式有关系,很多小孩他们一直工作到夜里三四点钟,中午睡到十二点,下午一点才到公司。假如夜里三四点工作遇到问题,你让他找谁?所以他不愿意自己有依赖性,不愿意他团队做的工作对公司有依赖性

这不意味着公司不愿意分享Code Base,事实上Facebook只有一个Code Base,任何人都有权限修改。有时候代码有可能会搞坏,但是搞正确的可能性更大。如果说搞坏损失十万块钱,但是搞对了对我们今后一直是有好处的,Facebook一直不断地在靠这个创造收入。所以最后平衡下来,衡量下来还是要去改的。

在Facebook经常说的一句话,就是我不怕失败,我不怕把这个事情搞砸了。这个是真的,在Facebook历史上搞砸的次数太多了。有一个高中毕业的学生,被Facebook直接录用来了,原因很简单,非常有才华,写代码又快又好。来Facebook看这儿不好那儿不好要改,这么一个有激情的男孩儿,你怎么让他不改呢?那是不对的。所以他就改了,改了第二天就出事了,整个网站都被他弄宕机了。我们来了以后都面面相觑,原来那哥们儿把网站的header-cache改了。那时候大家把他嘲笑一顿,说你怎么能够把自己的网站搞宕掉呢?他自己也很害羞,自己去喝闷酒。但是不会有人说,不应该这么做,这个我觉得特别的关键。

你要鼓励他去失败,这样的话他才会意识到自己是主人翁,才会让每个人都觉得,整个code base,每件事情都是我来管,这样的话我才对其他的团队没有依赖性,在没有依赖性的情况下你的团队才走的最快。你自己应该很明确自己要干什么事情,任何阻挡我把这件事情完成的东西都要排除掉,这样的话才能真的很快把这个东西做出来。只有你养成这种习惯后才能影响周围的人这样做。只有大家都这样做的话,公司才会很快速的发展。所以07-09年,Facebook任何的产品都是以飞速的,甚至大家觉得是不是有点太快了的速度在发展。

不过,每个人都可以改代码库造成一个问题,最后我们的PHP的Code Base变得五花八门,因为每个人都有自己的想法和主张,就把整个代码改的乱七八糟的。这个时候就需要有一个Key Person,这个人非常强,他站出来说不行,同学们,这个代码被你们改成这样了,我要重写一下。Facebook早期的员工真的是有这样有才华的员工,他可以花几天几夜时间把Code Base重新写一下。

所以在实行Hack文化的时候,一定要有特别重要的人,他让你在乱中还有一些静,能够重构和梳理公司的代码,因为Hack出来的代码肯定是很乱的。大家看到他把我的混乱的代码处理好了,特别感激他,然后下一次我就遵守他制定的规则。这种情况在Facebook屡见不鲜,总有人站出来说这个不行,我要来树立一个章法。在树立章法的时候,也是一个民主的过程,不是说靠奖金什么的,而是靠技术,这样的话,在技术的引领下,很多工作就这样慢慢展开了。

当时我做PHP Profiling的时候,也有人提出其它的看法,要不然咱们干脆停下来把网站改成Java,也有说要不然就把PHP改了,这些路不是没走过,但是都不通。因为你做这些事情就对其它团队造成依赖性了,实际上你在央求别人停下来去做你让他们做的事情,这个在Facebook是行不通的。在后来2011年、2012年有个很厉害的人总结过一次,他跟整个Facebook的人说,我看了一下,Facebook所有成功的项目都有一个特点,就是真的不对其他任何团队,不对其他任何人有依赖性,只要是透明化项目,只要你这个项目做出来不需要太多其他人参与的,做出来对大家都是有益的,这些项目是容易成功的。在这么纷繁复杂的组织里,不是说他不认可你的想法,他有自己的本职工作,所以你不能依赖他,他说我很忙,我把你这个事安排在下个月,渐渐这个事就泡汤了。

不过,我把这个(去中心化)讲的特别好,并不是说它没有弊端,其实有时候它是很有弊端的。举一个特别极端的例子,扎克(马克·扎克伯格)向大家抱怨,他说,你知道吗,本来我想做一件事,可是我找不着任何人帮我做这件事,因为大家手头都有自己的事情。他说我想做这个,为什么没有人帮我做这个事情。他就在那儿哭诉这个事情,我们大家都笑了,就是没人理他。这种事情在早年发生的特别特别多,到后来公司的人多了,公司有大的项目的方向,人也多了,可能扎克就能找到人帮他做这件事了。

再讲一个极端的例子,好还是不好,我也不知道。就是我们没有一个小组去帮助其他的团队去QA,没有专门的QA团队。因为大家不希望产生这种依赖性,怎么依赖?你说他是QA团队,难道我的产品发布之前还要征求他的同意?QA也不愿意依赖你的团队,我今天在这儿QA了,明天你就把这个方案改了,我的工作还没有完成。QA会在公司造成一种依赖性,这个依赖性在某种意义上来讲会让产品减速。当然,这个问题仁者见仁,智者见智。Facebook一直灌输这样的思想,不能用QA,用的话我这个产品怎么才能第二天就可以推出来?就是在这样的文化下,QA很难产生。

所以到后来,即使公司这么大了,我们现在去看整个Facebook,还是每一个团队负责自己整个的Stack,前端用什么,手机上是什么样,后端用什么,是不是用C++,全是这个团队来操作,如果出现了问题,自己团队来看。如果研发一个产品所有的工作,全是自己的团队来负责,这样就把依赖性很好地约束在自己管辖的范畴内,甚至所有的成员都在一个桌子之内,这样基本没有沟通成本。Hack文化和这个组织结构是息息相关的。在Hack文化下,工程师就不想要一个有依赖性的组织结构。在谁也不管谁,谁也不服谁的情况下,他可以随心所欲写Code,真的不在乎code的质量或者规范。真的有依赖的话,可能QA的人要QA我了,还要小心点(笑)。

思维方式:善于争论,用数据说话

第三个我讲的是思维方式,思维方式其实跟文化有一些类似的地方,Facebook的人有才华,他有自己的思想和主见,他对很多产品的方向,对很多的事情都有很强的想法。强到什么程度,强到员工之间经常争论不休,这个在早年的时候特别严重,到2010年的时候,公司说不行了,同学们,这样争论太伤感情了,大家互相之间还是要有同情之心,毕竟我们在一起工作了这么些年,还是要有一份爱在这儿的。这从另外一个角度来解读,就是Facebook人之间的争论,有的时候真的特别激烈。

但是争论归争论,我们很明确的知道,将来怎么解决这个争论。怎么解决?就是用数据去说话。你可以有你的想法,你说这个网页必须按照你的设计,我也可以有我的想法,我说网页是这样的。你可以争论,但是是骡子是马拉出去遛遛。

最后就是大家争论太多了,发展出来一个非常完善的AB测试系统。所以看Facebook软件系统真正的功能性的code写的可能有20%、30%,但还有40%的code都是去帮助这百分之二三十去搜集数据,去印证它好还是不好。它花了我们很多精力到网页上搜集数据,去反过来看我们这个运行情况是怎么样的。无论是UI的,还是整个流程,还是整个非常大的产品也好,实际上都是这样的,都是去试出来的。这个试出来的背后多多少少都是有争论在里面,因为真的是大家谁也不服谁。

甚至公司的这种思维方式有时候会非常极端,极端到什么地步?Facebook的人这样认为,任何事情我都可以评论,我都可以发表我的见解。大家认为我们公司的愿景啊这些,无论任何的事情,我们都是可以拿出来讨论的。

最逗的一件事情是差不多2008年时候,那个时候公司开始完善了,公司说,员工们,其实我们真的是一个公司,我们是有假期的。我们有三个星期的年假——HR的人说三个星期的假是指三五十五天的假。他发邮件的时候是说三个星期的假,但是很多人都理解三七二十一天。等公司公布的时候大家就开始争论,说这个不对,应该按二十一天,有人说你太可笑了,明明是十五天。结果你猜Facebook后来做了什么?Facebook把这个HR炒了,说你连邮件都不会写,让大家有这么大的争论。与此同时,Facebook直到今天也是每个人有21天的年假。这个虽说是一个可笑的故事,就是这么一个事情被Facebook争论成这样了,更不用说有理有据的争论。

这个思维方式就是这样,他认为我跟你争论是Ok的,我跟你争论并不是我不尊敬你。大家最常说的,就是我特别尊敬你的,但我不同意你的想法,我认为这个事情是这样,然后列出一二三四五。其实大家都在争论当中成长,达到共识,慢慢形成同样的思维方式。所以我觉得,如果说公司还小,真的可以花一些时间和精力去开发一批这样的工具,让公司内部员工可以很好的有一个地方去争论这些事情,而且不要怕大家争论,不要怕大家有不同的意见,这才是真正的公司员工,这是把心思放在你这个公司上的表现。

你可以去控制一下场面,让大家在争论的时候不伤和气,但是最后还是要鼓励员工百花齐放,百家争鸣的氛围。这个氛围其实Facebook到后来的时候是越来越弱了。要说2013、2014年大家都非常非常客气,就没有表面的冲突,别人要说一件什么事,要说有不同意见的人的话,他可能只是小小的,弱弱地问一句,再不然的话,就是底下很礼貌地讲一句话,你觉得这样好吗?其实这表面看起来很平静,但是没有把尖锐的问题拿到桌面上。

公司很小的时候,或者说需要一个高效研发团队的时候,你必须要把很多的问题拿到桌面来探讨,而且希望大家在争论的过程中,大家真正地意识到自己才是那个主人公,自己不是帮公司打工的那个人,自己正儿八经用大脑真正思考公司面临的问题。

创业公司要招强人

最后如果强调的话,就像我刚才提到的,Facebook早期的员工有一批人非常杰出,就像我刚才提到的那个高中毕业的小孩,他没有上过大学,但是他写代码的能力很强,是可以挑大梁的任务。早期至少有五六个人把这个团队的技术水平带到一个新的高度上,因此虽然用Hack文化,但代码质量并不特别差。所以在雇人的时候真的要做到宁缺毋滥,就是说我宁可花更长时间雇人,但是雇进来的人一定是一个特别强的人,因为他干的好的话,他会在无形中带动周围的同事。如果雇工作效率不是很高的人,这个团队就会跑偏了。所以刚开始的人还真是挺重要的。

我现在回想起来,我加入的时候有四五十人,这四五十人都是强手。现在即使回过头来,他们有人说,海平,你们这批人早期进来是Facebook的员工,是不是你们这帮人有运气?只是沾了早进公司的光,而后面进来的人比早期进来的人要强。我说这是毫无疑问的,后面会有更强的人,但是比例上来讲,后面的强人往多了算有20%就不错了,但是我们说早期的四五十人,强的至少在90%以上,这是一个很高的数字。90%的这些人甚至到六七年以后,能很轻松地负责一个大的团队产品开发。这些人具备快速学习的能力,他会迅速地把自己转化成所需要的那个领域的专业人士。早期的时候有了这批人,才能够把这个公司的文化给定住。如果说90%的人都是这样的话,那么剩下的10%的人形不成气候,而这90%的人把公司高效运转起来了,到了有五六百人的时候,有百分之五六十的人很强,以至于这个公司到后来越来越强。早期的员工在最后见面的时候,都有一种惺惺相惜的感觉,因为你打内心里是很佩服他的,你知道他确实很强。我不知道别人怎么看我,我就是很自信,大言不惭地分享自己的感想,我们这批人互相见面,就觉得我们就应该是那批成功的团队,我们当年就是做了很强的事情。

所以早期做的时候就要抓住这点,使自己的团队有这样很强的人,你可以花很长时间去招一个人,或者接触的人稍微有点弱,就不要他了。说实话,一般的人可能做某些事情很熟练,看起来快,但很强的人给他一点点时间,也能把事做了,并且从整体上会做的更好。所以当公司开始起来的过程中,招到强人是很重要的。


原型工具难上手、速度慢?试试Mockplus!

_____

Mockplus,更快更简单的原型设计工具。快速创建原型,一键拖拽创建交互,团队协作省事省力。微软、华为、东软、育碧、Oracle、西门子、IBM等全球知名企业和全球300多所高校都在用,你也可以免费开始你的设计!

免费下载
logo

咨询客服

帮助群:748169314 加入QQ群

服务邮箱:service@jongde.com

咨询客服

在线客服

置顶