Facebook研发团队的高效秘诀

阿里巴巴技术保障部研究员赵海平在活动上分享了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%的人把公司高效运转起来了，到了有五六百人的时候，有百分之五六十的人很强，以至于这个公司到后来越来越强。早期的员工在最后见面的时候，都有一种惺惺相惜的感觉，因为你打内心里是很佩服他的，你知道他确实很强。我不知道别人怎么看我，我就是很自信，大言不惭地分享自己的感想，我们这批人互相见面，就觉得我们就应该是那批成功的团队，我们当年就是做了很强的事情。

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

文章来源：EGO

关注“51CTO技术博客”扫一扫关注吧！