| layout | title | description | category | tags |
|---|---|---|---|---|
post |
《打造Facebook》读书笔记 |
##Move fast and break things.
快速发布，允许出错。Facebook的这句标语要分两部分来看。
天下武功，唯快不破，敏捷开发是工程师的基本修养，并不仅仅是写代码写得很快，其中的核心是运用迭代来管理开发，我认识的很多工程师都没有真正理解敏捷开发的管理方法，初级工程师很容易陷入到纯粹的技术问题上，而对一些思想和管理方法没有了解，导致层次仅限于人们常说的“码农”。
允许出错，是一个Facebook特色的理念，因为Facebook从早期是一个只有Web产品的公司，Web产品的发布特点是随时可以从服务器端修改，这样即使出错了，修复成本也很低。而且在早期，一个产品更重要的是验证是否满足了用户需求，而不是稳定性，所以快速发布比控制质量更有意义。对于我们现在做的iOS平台产品，发布是由Apple审核团队严格控制的，每一个版本的发布周期都比较长，如果线上版本出现bug，发布下一个版本修复问题需要至少一周的时间，所以每一个版本都应该追求阶段性完美，如何规划版本在iOS平台上成为一个重要的问题。现在Facebook已经是一个影响亿级用户的服务，这样的服务即使中断几秒钟，也是损失巨大的，而且随着员工数量的增多，哪怕每个员工只有千分之一的概率犯错，加起来也是不小的错误率，所以现在Facebook已经去掉了后半句，只保留了Move fast。如果是我们团队，我建议改成Plan things and move fast。
##开放环境
Facebook员工在这里改变世界。
开放式的办公环境我很喜欢，虽然V2EX上讨论时比较有争议，有人喜欢也有人不喜欢。�不喜欢的人主要是认为如果在这种环境沟通，很容易影响别人。团队讨论对无关的人来说是一种噪音。几个人凑在一张桌子上显得拥挤。我认为这些问题都是可解决的：
- 讨论区跟办公区相隔一定距离，尽量不干扰别人。讨论去会议室是个好习惯。
- 桌子要大，每个人的可用面积至少要能摆得下3个显示器那么大，要有足够的置物空间。
在腾讯的时候每个人的座位比较宽松，可是每个人的座位是一种半开放的隔间，你和你对桌的人是有一块挡板隔起来的，你必须要站起来才能看到对桌的人。这样容易给人更多的隐私空间，但是不便于员工之间互相交流。老大们还有自己的办公室。
而Facebook选择这种开放式环境跟它的文化有关，它的愿景是Make the world more open and connected，开放的观念体现在Facebook的方方面面，从员工起就是这样，所有员工是一种扁平化的结构，没有强烈的层级观念，从事管理和技术工作的人没有高低之分，只是工作职责不同，连Mark Zuckerberg也是跟其他人坐在一起，座位并不比其他人大。相信不少人都见过这张照片，Zuck的桌上那张Stay focused & keep shipping的批萨盒很显眼。
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甚至做了类似Collabedit或sync.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）。每次讨论结束，会制定行动项目，避免空谈。下属会在当天电邮一个简短的会议记录，主要就是书面写下行动项目，方便下一次对照。每天讨论，我们会关注在以下几个方面：
- 工作开不开心(Happiness)？
- 效率高不高(Productivity)？
- 工作的影响大不大(Impact)？
- 有没有学习成长的机会(Growth Opportunity)？
总结起来，叫做Happy PIG（快乐小猪）理论。
##成熟的流程与制度 在本书的后半段，都在介绍Facebook的一些产品研发流程，以及考核激励体系。这些方法在大公司都差不多，跟腾讯的几乎完全一样，没有什么特别值得一说的。
##总结 看来国内外的公司在流程制度上都差不多，主要的差别还是在前面所说的部分，核心就是工程师的素养，我认为这是中国工程师普遍需要提高的部分。Facebook的很多理念和思想，是值得很多公司学习的，但是映射到自己的场景里，是否同样适用，就需要自己根据实际情况去思考了。