Move fast and break things.

快速发布,允许出错。Facebook的这句标语要分两部分来看。

天下武功,唯快不破,敏捷开发是工程师的基本修养,并不仅仅是写代码写得很快,其中的核心是运用迭代来管理开发,我认识的很多工程师都没有真正理解敏捷开发的管理方法,初级工程师很容易陷入到纯粹的技术问题上,而对一些思想和管理方法没有了解,导致层次仅限于人们常说的“码农”。

允许出错,是一个Facebook特色的理念,因为Facebook从早期是一个只有Web产品的公司,Web产品的发布特点是随时可以从服务器端修改,这样即使出错了,修复成本也很低。而且在早期,一个产品更重要的是验证是否满足了用户需求,而不是稳定性,所以快速发布比控制质量更有意义。对于我们现在做的iOS平台产品,发布是由Apple审核团队严格控制的,每一个版本的发布周期都比较长,如果线上版本出现bug,发布下一个版本修复问题需要至少一周的时间,所以每一个版本都应该追求阶段性完美,如何规划版本在iOS平台上成为一个重要的问题。现在Facebook已经是一个影响亿级用户的服务,这样的服务即使中断几秒钟,也是损失巨大的,而且随着员工数量的增多,哪怕每个员工只有千分之一的概率犯错,加起来也是不小的错误率,所以现在Facebook已经去掉了后半句,只保留了Move fast。如果是我们团队,我建议改成Plan things and move fast

开放环境

Facebook员工在这里改变世界。 env

开放式的办公环境我很喜欢,虽然V2EX上讨论时比较有争议,有人喜欢也有人不喜欢。不喜欢的人主要是认为如果在这种环境沟通,很容易影响别人。团队讨论对无关的人来说是一种噪音。几个人凑在一张桌子上显得拥挤。我认为这些问题都是可解决的:

  1. 讨论区跟办公区相隔一定距离,尽量不干扰别人。讨论去会议室是个好习惯。
  2. 桌子要大,每个人的可用面积至少要能摆得下3个显示器那么大,要有足够的置物空间。
    在腾讯的时候每个人的座位比较宽松,可是每个人的座位是一种半开放的隔间,你和你对桌的人是有一块挡板隔起来的,你必须要站起来才能看到对桌的人。这样容易给人更多的隐私空间,但是不便于员工之间互相交流。老大们还有自己的办公室。
    而Facebook选择这种开放式环境跟它的文化有关,它的愿景是Make the world more open and connected,开放的观念体现在Facebook的方方面面,从员工起就是这样,所有员工是一种扁平化的结构,没有强烈的层级观念,从事管理和技术工作的人没有高低之分,只是工作职责不同,连Mark Zuckerberg也是跟其他人坐在一起,座位并不比其他人大。相信不少人都见过这张照片,Zuck的桌上那张Stay focused & keep shipping的批萨盒很显眼。
    desk
    Zuck在公司内有固定时间,回答员工的任何问题,但是明确规定不允许员工对外人透露公司内部的情况,因为员工只有做到对外守口如瓶,才能做到对内知无不言。公司文化要求每个员工不是为了自己、为了团队、为了部门而工作,而是为了整个公司而尽力,所有人沟通顺畅,则事半功倍。在腾讯的同事都知道“部门墙”这个概念,表示部门与部门之间像有一道墙一样的沟通障碍。如果一个大公司能够保持Facebook这样的开放文化,真的很不容易。

黑客文化

业内人士应该都知道由大公司举办的几个开发者大会,例如Apple WWDC、Google I/O、Facebook F8,其中F8这个名字是怎么来的?有人说是因为Facebook总共有8个字母,实际上是因为每次F8大会最后都有8个小时的Hackathon(黑客马拉松)活动,8是为了强调Facebook的黑客文化。关于Facebook的黑客文化,丰富到可以单独写一篇文章来阐述,这里只能点到为止。

学习和创造

没有黑客会喜欢重复劳动和没有创造性的工作。黑客的最核心价值观是“所有信息都应该是自由传播的”。黑客的驱动力不是偷窃和破坏,而是学习和创造。Zuck作为公司的首席黑客,每年都会给自己定下挑战,2009年是坚持每天打领带,2010年要学中文,2011年是只吃自己亲手屠宰的动物(素食主义者),2012年坚持每天写代码。

自己决定做什么

作者王淮在雅虎工作的时候,一个组提开发需求给另一个组,是需要很多次沟通的,而且需要提需求的小组老大找实现的小组老大沟通,然后另一方来分配工程师的时间。这样的官僚机构在Facebook是不可想象的,两边的对接工程师会直接沟通,自己定做不做、什么时候做、做到什么程度。这里有个前提是Facebook的工程师都具有较高的产品和项目管理素养,而不仅仅是一个完成别人分配任务的工具。

激发兴趣

Hackathon鼓励参加的人尽量放下日常工作,完全根据兴趣开发,可以天马行空,不受任何约束。每个人可以发布自己想做的项目,然后聚集起感兴趣的合作者来共同完成,这些临时的搭档会激发出不一样的灵感。

代码胜于雄辩

Code wins arguments. 黑客会迅速制作原型,看看是否行得通,而不是在会议室召开数天的马拉松会议来讨论最佳的方法。实际交付出东西的人比权力最大的人更能说服黑客。

工程师驱动

Facebook和Google一样具有工程师驱动的文化,因为他们都拥有一流产品素养的工程师。他们不见得花所有时间在写代码上面,而是有很多时间要用于思考、设计和跟产品经理的合作。在整个产品的开发过程中,工程师和产品经理主导的比例大概是60:40。

面试招聘

技术面试会细到要求你告诉面试官一行行代码怎么写,Facebook甚至做了类似Collabeditsync.in这样的实时编辑工具,应聘者自己在电脑上写,面试官在另一边就能看到。面试官可能会问到Facebook碰到过的真实问题,看看对方会怎么解决,说不定老问题可以聊出新的火花。并且最好能说明自己的思路,卡壳的时候面试官会给出提示。Facebook会回避类似脑筋急转弯的智力型题目,重点都在具体的编程问题上。

除了技术面试,面试过程中会有20%的时间用来做文化适应性面试,介绍公司文化,确定应聘者与公司的核心价值观不冲突。例如Done is better than perfect(完成比完美更重要);乐于团队合作,而不是单枪匹马;不要只听老板的话,要做一些自己的决定。最后是看应聘者是否有学习新东西的意愿和能力。

面试结束后,所有面试官会给应聘者打分,并给出具体的评价和理由。面试官必须在当天反馈评价,招人是Facebook第一优先级的工作。Facebook尊重每一个应聘者,希望这种高效率给应聘者留下好印象。就算应聘者不适合Facebook,也欢迎他们推荐自己的朋友来试试。招聘是竞争的第一步,业内一流人才如果没有进入你的公司,那他们就在竞争对手的公司服务。这意味着,产品还没在市场上正式过招,你就输在了起跑线上。

Facebook的招聘原则是Hire slow, fire fast。招聘标准很高,只和最一流的人合作,一流人才无法容忍二流人才,对于平庸的人才从不妥协。对一流人才来说,仅仅“足够好”是不够的,他们能尽其所知,用其所长,学其所不能,从而迅速完成目标并远超期望。这里并不是说没有包容心,而是说希望每个人都是为自己树立高标准、喜欢互相学习、互相挑战、能够完成艰巨任务的人。Facebook财大气粗,是可以提出较高的要求,如果是创业小公司,可能就没办法这样,因为往往也招不起高端人才,对招来的人扬长避短才是更实际的办法。

炒鱿鱼要快,任用二流人才就像服用慢性毒药。如果一个人确实是能力问题,需要迅速炒掉,否则会对团队造成极大的负面影响,他们造成的损失会多过给公司带来的正面影响。这一点我也深有体会,有时候一个庸才带来的损失,十个天才也弥补不了。

Facebook收购了30多家创业公司,主要原因就是觊觎他们的人才,而不是产品。

新兵训练营

所有新入职的工程师会参加称为Bootcamp的培训,学习代码库、工具和方法,最好在第一天就能提交代码。新人在进来之后并不会立即安排工作岗位,他们会随着融入Facebook的过程,找到适合自身能力和兴趣的小组。一般新员工有更大的主动权来选择,选定的组不能拒绝他。如果是认为他不行,那不如解雇他;如果不愿意让他来你的组但可以到其他组,这种想法违背Facebook文化,“我们都是为Facebook工作的,而不是为了某个小组工作”。

每个人会有一位导师,导师允许占用1/4的工作时间,负责解答新人的各种问题,从工作、生活到八卦。传递规章制度,比如休假、福利等等一些实用而琐碎的信息。第一次打开电脑后会收到6封电子邮件,1封是欢迎信,另外5封是介绍他们将要执行的任务,一般是简单的bugfix,目的是熟悉开发流程。

培训当中的课程会介绍公司的整体情况,让新人有全局认识,然后会介绍重要产品、技术框架和技术工具,最后会介绍非产品和技术的其他部门。

技术管理

迅速发布,再进行监测

Move fast and monitor closely. Facebook使用灰度发布方式,发布之后监控这个产品的几个最重要指标,从运营数据来看这个产品有没有达到预期。这一点上,我们还有很多路要走,我们的监控应该看到更加专业的运营数据,细到针对特性的指标。

工具文化

最优秀的人才不是在最赚钱的产品部门,而是放在工具开发那一块,因为工具做好了,可以事半功倍,所有人的效率都可以提高。Facebook常见的工具:

  • 给新工程师分配开发机器的管理系统,一键申请,自动初始化。
  • 代码库管理用git,集成一些hook,包括提交前自动检测是否符合代码规范,自动检测是否有覆盖的测试用例。
  • Phabricator,已经开源的code review工具。只有通过code review的代码,才允许提交到服务器端的代码库中。
  • 发布工具。灰度发布,可以选择用户特点(比如对年龄、性别、地域、受教育程度等方面的限制)。Bit Torrent算法实现分布式快速更新,几十万台机器发布只需要几十分钟。
  • 监控工具。数据收集只需要1〜2行代码,整理、分类、存储都在后台自动完成,可视化报表可以即时生成。
  • 告警工具。数据波动自动告警,发邮件、发短信,设定既定应急方案去解决。,如果不行,全球24小时轮班的站点稳定工程部门会打电话给你。
  • 最重要的目标、任务、目标日期、负责人写在白板上,挂在离我们最近的墙上。
  • 客服工具。用户提交的问题会被引导到网站帮助,解决不了的会被自动分配到相关的运营组处理。工具产生常见的通用解决方案,例如一键退款,回信内容自动产生(用户姓名、问题原文等个体信息会自动嵌入),可以选择是否修改内容。如果针对某一个功能问题突然增多,会自动提醒运维人员手动查看,然后决定是否需要工程师介入修复。所有用户问题的统计信息会被自动统计,以保证客服质量。
  • 招聘工具。做题系统、题库管理、自动打分、面试评价、权限控制。
  • 业绩评价工具Work.com。以前叫做Rypple。
    所有不断重复的好习惯,Facebook都会将其自动化,做成工具。如果有开源的工具,就用开源的,可以改造后再回馈代码给开源社区;如果没有开源的,那么符合需求的商业工具,Facebook乐意购买,并不是所有工具都要自己开发,因为不希望重复制造轮子。

一对一碰头会

这个有点像腾讯的PDI。上下级之间的碰头会,主要涉及的是个人发展和工作事宜,在半个小时或一小时里,只关心对他们重要的问题。一类是工作上的具体问题,第二类是个人发展上的问题,第三类是公司发生的一些事情的沟通。会议的主导方是他们,我们可以聊任何他们感兴趣或对他们有帮助的话题。他们需要准备好要讨论的问题,以及对上一次碰头会的后续跟踪(Follow-up)。每次讨论结束,会制定行动项目,避免空谈。下属会在当天电邮一个简短的会议记录,主要就是书面写下行动项目,方便下一次对照。每天讨论,我们会关注在以下几个方面:

  1. 工作开不开心(Happiness)?
  2. 效率高不高(Productivity)?
  3. 工作的影响大不大(Impact)?
  4. 有没有学习成长的机会(Growth Opportunity)?
    总结起来,叫做Happy PIG(快乐小猪)理论。

成熟的流程与制度

在本书的后半段,都在介绍Facebook的一些产品研发流程,以及考核激励体系。这些方法在大公司都差不多,跟腾讯的几乎完全一样,没有什么特别值得一说的。

总结

看来国内外的公司在流程制度上都差不多,主要的差别还是在前面所说的部分,核心就是工程师的素养,我认为这是中国工程师普遍需要提高的部分。Facebook的很多理念和思想,是值得很多公司学习的,但是映射到自己的场景里,是否同样适用,就需要自己根据实际情况去思考了。