我在Facebook学到了什么

　　王淮

　　我是2007年初加入Facebook，那时大概150人；2011年9月底离开，当时3200多人。经历了很多稀奇古怪但影响很大的项目，像Application Platform、Social Ads、News Feed、Gift Shop、Facebook Credits等等。在Facebook的这几年让我学习感悟了很多东西，很多东西融在血液中，写下10点经验和大家分享。

　　美国加州8岁女孩佩吉·麦克唐纳正在网上冲浪。新兴的儿童社交网站正在影响下一代孩子的生活

　　1.坚持你的远见，但灵活地把握细节

　　作为领导者，在远见上你只有依靠自己，至少在你自己负责的业务范围之内。人很难有效地处理10个以上的变量。我们需要一个更有可扩张性(scalable)的解决方案。我们希望把很多事情自动化，让机器人做更多机器擅长的事情。因此我们建立了一个共识——将我们绝大部分的规则逐步替换为机器学习获得的判断模型。

　　2.只和最好的人合作

　　一流的牛人只愿意和牛人厮守。他们聚在一起会更牛。一流人才无法容忍二流的人。只有一流人才组成的团队有很多好处。牛人们喜欢互相挑战。我记得一位工程师总监立下赌约——如果我们在规定时限之前完成网站翻译平台所需的代码修改，他将把头发染成蓝色。这样的挑战把“枯燥”的工作变成了挑战性游戏。在玩游戏中写程序比纯粹的写程序要有趣得多。当然我们也有很多更加认真的挑战。牛人们相互学到很多，每个牛人都有自己牛的地方，彼此有很多的互补。

　　你不想要二流的人，但如何远离他们？首先，慢点招人(Hire Slow)。其次，炒鱿鱼要快(Fire Fast)。使用二流人才就像服用慢性毒药，一天一点，迟早嗝儿屁。

　　3.树立高的期望值并加以衡量

　　作为领导者，你需要设定足够高但仍合理的期望，足够高使得你的团队不会感到无聊，仍合理使得他们不至于油尽灯枯。另外，你需要找到一个不容争辩的途径来衡量期望。

　　4.重视数据而不盲从数据

　　决定产品方向时，要的是想象力、激情和胆量，而不是数据。数据能让你的团队沿着正确的方向前进而不出轨，也有助于产品从“一开始是什么样”到“最后应该是什么样”的逐渐优化成型。但数据不能帮你决定方向。但你不能忽视数据。没有数据的支撑而一味靠直觉走黑路，很容易走岔道，甚至大错特错。

　　5.避免无谓的时间浪费

　　刚进Facebook做工程师的时候，我非常享受那种日夜泡在码海中的感觉。后来慢慢地，承担的项目责任越来越大、越来越多，写代码的时间越来越少(但绝大多数时候仍占大头)。我花了大量的时间在思考这些问题——哪些功能需要添加，哪些功能需要删掉，需要开始或停掉哪些测试，我们正在流血流汗的是不是现在最最重要的问题，我们是该花时间优化用户交互流程还是减少出错率，还是让系统更快等等。这些问题很伤脑筋，但这些问题很重要，甚至可能决定了你熬的日日夜夜究竟有没有必要。

　　有一个被经常忽略的原则——有意识地去思考哪些事情不应该做并且马上不做。例如，哪些是无谓的争论可以避免介入，哪些功能可以放弃，哪些关系不应该发展，哪些人应该开掉等等。我经常问自己一个很简单的问题：我现在正在做的是否对我的目标很重要。如果你清楚自己正在做的和自己想要的，答案会明了。加油(Go for it)。

　　 6.增进亲密感是减少紧张关系的有效方式

　　工程师和支持团队之间有着纠结的合作竞争关系(注意，合作在前)。如何让合作竞争保持在一种健康有序的状态？我觉得关键是促进人与人之间的亲密感。把人搞近了，事情就容易了。

　　7.习惯委托，但不要盲目，请谨慎

　　分配任务委托别人的重要性比较容易理解。因为你不是超人，当团队一大，事情一多，你一定要学会委托别人来负责合适的任务。

　　8.意见反馈应该一个持续性的，而不是一年一次或两次的活动

　　一年一度或两度的意见反馈在硅谷公司是非常常见的。它的目的不是设置起来给员工难堪，让他们互相责难的；它的目的是希望员工对自己对他人有更全面的认识，以助进步。意见反馈有自我反馈和同事反馈两部分。自我反馈是自己评定自己，完成了哪些目标，错失了哪些目标，哪些方面做好了，哪些方面还待进步。但由于是自己踢球兼裁判，难免有失偏颇。同事反馈，就像一枚镜子，让你看到180度之外的自己。在Facebook，360度的正式意见反馈是一年两次，并且和薪酬挂钩。除了季度性的轻型意见反馈，日常的意见反馈如果有的话应当立马传递，趁热打铁效果更好。

　　9.你可以比你想象的做得更好

　　牛人们总是不断地超越自己。给他们一个离谱的目标，配以应有的工具，适当的帮助，足够的信心还有一定的时间，他们会让你大吃一惊，也会让自己大吃一惊。但做到这一点有一个前提——不能害怕犯错。

　　10.不要过多设计或者过早优化

　　有些工程师有一股出于本能的冲动，想把自己的程序规模化，甚至是在这些程序还没看到大规模使用的曙光之前。我在Facebook开始的时候，也是冲动型工程师一类。但经历过几次失败的产品之后，我牢记了这个教训。不要过多设计或者过早优化，把核心功能设计得简单精练。只有在看到产品有被大规模使用的趋势后，才来增加功能或增加规模量。

　　Friendster这个网站的失败就是其基础架构的性能长期无法应对急速增长的用户，以致网站很慢甚至崩溃。在用户增长高潮来临之前，你应该已经在架构上做了足够多的前戏，否则搞不好就要像Friendster收摊子散伙。但同时也要意识到，你所看到的用户访问模式，你的网站功能，在你只有10万用户的时候，可能和你有1亿用户的时候会很不一样。所有太多太早太频繁的架构上的大动作可能会适得其反。这一点上，你要小心判断。