王淮：我在Facebook的十点经验分享

作者: 王淮 发布时间: 2012-04-20 22:28 阅读: 1478 次 原文链接 全屏阅读 [收藏]

我是 2007 年初加入 Facebook，那时大概 150 人。2011 年 9 月底离开，当时 3200 多人。经历了很多稀奇古怪但影响很大的项目， 像 Application Platform, Social Ads, News Feed, Gift Shop, Facebook Credits 等等。碰到的很多的问题都是全新的，规模是互联网历史上最大的。当时的心惊肉跳现在回想起来是很让人怀念的旧时光。到我离开 Facebook 的时候，我负责支付安全和工具研发部门，还有部分的支付后台研发组。

现在我在全职做天使投资，给看对眼的团队在早期产品技术团队搭建给予一些力所能及的帮助。有兴趣的朋友可以关注我的微博@王淮 Harry 哥。

在 Facebook 的这些年让我学习感悟了很多东西，很多东西溶在血液中，现在我换了时间来思考最值得分享的 10 点经验和大家分享。希望能给创业的朋友一些启发。

在我们开始之前，先来一段免责声明“

1. 这里所有的东西都是从我自己的亲身体会和实践中获得的。不一定都是新的，但都是真实的。

2. 所有的这些在 Facebook 的文化下能有效，但不代表对你的公司一定有效。好的种子还要有合适的土壤。

3. 不是所有的点都对你有用，但只要有一点对你有用，我就开心了。

OK. 我们开始吧。

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

作为领导者，在远见上你只有依靠自己，至少在你自己负责的业务范围之内。你是老板，意味着整个公司；你是经理，意味着整个部门。为你卖命的兄弟姐妹们是依靠你来给他们提供远见。什么是远见? 就是对最终状态的一种描述。是让你的团队在疯狂的飞行之后最终着陆的地方。是辛辛苦苦忙忙碌碌之后的新生活。它是北极星，它来指明方向。举一个例子，当我一开始建立支付安全部门的时候，我们只有人工规则引擎。规则是人写的。一条人工规则是有少数变量的简单逻辑，比如“如果(注册在 30 天之内和支出大于 100 美元和是首次支付和用户来自印度尼西亚)，那么 (拒绝交易)” 但这里有个问题 —— 人写的东西容易出错. 人很难有效的处理 10 个以上的变量。我们需要一个更有可扩张性(scalable)的解决方案. 我们希望把很多事情自动化，让机器人做更多机器擅长的事情。因此我们建立了一个共识 —— 将我们绝大部分的规则逐步替换为机器学习获得的判断模型。这一远见让我们组新加了一位机器学习领域的博士和另一位之前有过机器学习体系开发经验的工程师。赌注巨大，但是一个更好的未来需要下这个注。

但你需要对细节灵活把握，永远都有条条大路通罗马. 你需要给团队足够的空间来施展拳脚，只要他们在朝着正确的方向以合适的速度前进。另一个故事：在 classification 算法上一度我对决策树的兴趣比回归要大。但玩算法的工程师告诉它们之间的差别可以忽略。我可以坚持己见（当时我是真心觉得决策树要更合适），但我信任他并让他放手去选合适的算法。同设计师(Facebook 的整个研发有设计师、产品经理、工程师三类物种) 合作的过程中也有趣事发生，他们对于字体、颜色、行距等等都很龟毛。我通常都会忍让， 只要服务于产品的主要功能。我们精力有限， 吵架要选择正确的战争，关乎全局的战争，而不是纠缠于某个局部战斗。

2 、只和最好的人合作

一流的牛人只愿意和牛人厮守。他们聚在一起会更牛逼。一流人才无法容忍二流的人。那什么是“最好的人”？我的理解是能够尽其所知，用其所长，学其所不能， 从而迅速完成目标并远超期望。他们的本能是挑战自己， 超越别人的期望，超越自己的期望。对他们来说，仅仅足够好是不够好。

只有一流人才组成的团队有很多好处。

(1) 这让你更加愿意委托。从我的经验来看，牛人不会轻易信任不熟悉的人。如果你还没有证明自己和他们一样出色甚至更出色，他们宁愿自己独立工作劳累死也不愿接受你的帮助。因为他们担心你会搞砸。但当你证明自己之后，他们会信任你，放心的把事情交给你一起合作。一个互帮互助的牛逼团队才能做到1+1远大于2.

(2) 通过艰巨任务的完成，牛人们互设榜样。你会想“牛，这哥们竟然能把这玩意做出来了，咱得加油了”。这种 peer pressure 合理的利用可以大幅度的提高工作表现并在团队中形成良性循环。

(3) 牛人们喜欢互相挑战。我记得一位工程师总监立下赌约 —— 如果我们在规定时限之前完成网站翻译平台所需的代码修改，他将把头发染成蓝色。这样的挑战把“枯燥”的工作变成了挑战性游戏。在玩游戏中写程序比纯粹的写程序要有趣得多。当然我们也有很多更加认真的挑战。因为牛人们天生(贱命，哈)容易对挑战上瘾， 不管是挑战别人还是接受挑战。

(4) 牛人们相互学到很多. 每个牛人都有自己牛的地方，彼此有很多的互补。如果 Facebook 不是有很多东西可以学习的话，我不会呆 4 年多。对缺乏经验的人来说，这点很给力。我们雇佣非常聪明的毕业生(潜在牛人)，这些人希望引爆自己来证明他们的牛逼之处。他们不愿到一个舒适无挑战的公司过日复一日的生活。他们想学很多来丰富他们的经验，完成不可能完成的任务并在他们的职业生涯上前进。他们想要证明“yes, we can”。和其他牛人一起才能更容易的实现这些。

你不想要二流的人，但如何远离他们？首先，慢点招人 (Hire Slow)。在招人的标准上固执一点。训练你的面试人员让他们明白他们需要招(某些方面)比他们更强至少不会拖后腿的人，如果不是，拒绝平庸，不要屈就。我曾好几次在招聘决策会议上发现黄金履历者无法拿到 Offer, 只因为某个面试官觉得这人无法给他深刻印象没有让他惊讶。但在另外一些例子当中，那些获得一致通过的候选人仍被放弃因为大家都只是觉得他仅仅符合要求而已， 没有出彩的地方。在招人问题上，绝大多数情形下，你要小心不要冒进。（顺便提一下我们也会雇用那些没有全票通过的候选人，只要有一两票是强烈推荐 —— 因为对于已有员工的强烈推荐你是不应轻易忽视的，这时可以冒险）其次，炒鱿鱼要快 (Fire Fast).。使用二流人才就像服用慢性毒药，一天一点， 迟早咯屁。Facebook 要求所有的管人经理对于员工的表现要特别敏感。经理发现员工分配的任务或者答应的事情经常没有做到，如果是客观原因，一定要尽力帮助解决；如果判断为人才质量问题，走法律允许的程序迅速将人炒掉。我见过几次炒的比较慢，那对团队造成的负面作用可不是闹着玩的。

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

作为领导者，你需要设定足够高但仍合理的期望. 足够高使得你的团队不会感到无聊。仍合理使得他们不至于油尽灯枯。你要给他们创造一段经历，使得在旅程结束时，他们回过头来看会说 —— "他妹的， 我都没想到我居然做到了这个，这个屌爆了。" 在 Facebook, 和其他硅谷高技术公司一样，期望同薪酬相结合。每半年 Facebook 都有5-6个公司级的大目标，所有人的奖金算法中都会考虑该目标的完成情况。因此树立明确的期望本身就至关重要。

另外， 你需要找到一个不容争辩的途径来衡量期望。我花了大量时间和团队一起制定下季度里最重要的3-5个目标并有数据化的衡量指标(一个目标背后可以有多个指标)。根据工作量把目标分别委派给单个或多个攻城狮，或者让他们自己揽。在这一情况下，我们不仅有可衡量的目标，使得我们可以迅速地说出来我们在做什么做到哪了，同时也知道每个具体目标后面的负责人是谁。团队的表现和个体表现挂钩，所以他们失败了我即不成功。例如， 当年我们团队最大的成果就是在一年时间里，通过每季度不同的指标，让信用卡支付的投诉率降低了75%.

有一点要强调的是 —— 期望还是要基于现实要合理。在你只有 10% 的市场份额的时候却幻想 10 几倍的收入增长无疑不现实。Steve Jobs 乔老爷是这方面的老手，非常善于推动他的团队超越潜能但同时也榨干他们（虽然他们后来还是为他们所做到的而自豪一辈子）99.9% 的领导者不是乔老爷，也不需要是。更可行的是在团队的真实极限中找到一个可持续性的驱动来激励团队超越自我。

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

决定产品方向时， 要的是想象力， 激情和胆量， 而不是数据。数据能让你的团队沿着正确的方向前进而不出轨，也有助于产品从“一开始是什么样”到“最后应该是什么样”的逐渐优化成型。但数据不能帮你决定方向。举个例子，当我们在人工智能(机器学习)上压上我们团队所有的资源的时候，我们忐忑不安。但是我们坚信一点，现有的基于人工规则引擎的防欺诈系统会很快成为死胡同，因为它太死板而且不易规模化以处理大数据。所以，就像在电影指环王中 Frodo 明知通向 Mordor 的道路很黑很冷很危险，但那是一条他必须要选择去走的路；我们选择了在机器学习上压上所有的宝。失败，整个团队会很难看；但我们决定走艰难但我们认为是正确的路。这种思路同样应用在如何设计用于用户报告(外部工具)和案例审查(内部工具)的工具来应对潜在的欺骗行为。我们最后决定的方向是“进行自动处理”和“建立反馈机制”。直接抛给人工来处理总是很容易被选的一条路， 因为只要建立一个人多人傻的客户支持团队即可。Lame! 我们希望通过自动处理来解决大部分的欺诈案例，而把精力则放在那些确实需要单独处理的特殊案例上，同时把从业务支持团队(即客户支持部门)的处理意见自动采集并集成到下一轮的机器学习中去。由此，我们的机器判断会越加精确和聪明且与时俱进.

但你不能忽视数据。没有数据的支撑而一味靠直觉走黑路， 很容易走岔道， 甚至大错特错。有一段时间我们认为爬行工具(通过分析关联的cookie, 信用卡)可能可以找到很多欺诈的同伙。通过实验结果却发现， 这种预期是否成立很大程度上取决于当前流行的欺诈行为的特点。比如，当失窃或贩卖信用卡的案例非常普遍的时候，关联分析是一种有效的方法。但如果主要情况是帐户被黑或小宝们冒用妈妈的信用卡去网游消费时，关联分析就作用不大。直觉在现实前面碰了一脸的灰。不过幸运的是我们很快意识到这点且把这个项目叫停了， 所以没有浪费太多的资源。

另外， 顺带提一下A/B测试。A/B测试并不会告诉你去做什么产品，但它可以帮你确定实现产品时的哪个细微版本更能揪住用户大爷们的心。

5、避免无谓的时间浪费

刚进 Facebook 做工程师的时候，我非常享受那种日夜泡在码海中的感觉。后来慢慢的承担的项目责任越来越大越来越多，写代码的时间越来越少(但绝大多数时候仍占大头)。有时候更多的是把时间花在决定产品的方向和设计上。很多事情是和产品经理设计人员一起搞的。但在 Facebook 攻城狮们有很大的发言权，甚至有些时候是拍板的权力。Facebook 希望攻城狮们有王者风范。Facebook 希望攻城狮能决定自己要做什么应该做什么，而不是总是"被决定"做什么(一种流行的说法是，write your own job description). 因此，我花了大量的时间在思考这些问题 —— 哪些功能需要添加，哪些功能需要删掉，需要开始或停掉哪些测试，我们正在流血流汗的是不是现在最最最重要的问题，我们是该花时间优化用户交互流程呢，还是减少出错率， 还是让系统更快，等等。这些问题很伤脑筋，答案经常不确定，比一个劲码到手抽筋要难。但这些问题很重要， 甚至可能决定了你熬的日日夜夜究竟有没有必要。建议所有的攻城狮思考思考代码之外的这些问题，团队领导者就更有必要了。当然，攻城狮的大多数时间还是应该花在代码上。

那究竟哪些时间不应该被浪费呢？

很多，但我只举两个我认为最重要的例子。

邮件。不是所有邮件都发而平等。有些邮件纯粹打酱油的，有些邮件是不需要马上处理的。我尝试使用过滤规则来踢掉打酱油的邮件，突出需要马上处理的重要邮件。对此，分享两点。

1) 建立一个适合你的邮件过滤系统。我会对重要和紧急的邮件做即刻回复，而暂缓处理那些可以等到晚上再回复的邮件（尤其是发自我自己的团队，产品经理，兄弟连和顶头的不顶头的上司们的邮件）。但是，我要确保在我挣扎的爬到床上之前，把这些邮件全部处理掉， 读的读， 回的回。对于那些仅供参考的邮件，过滤系统会将其塞到某个固定的角落，我隔三差五去瞅瞅。此类邮件诸如某酒鬼询问 Napa Valley 哪个酒窖比较正点等等. 这些邮件通常比较有趣， 挖的坑很大很深所以也很耗时间， 我通常不跳或者不马上跳。

2) 广而告之你的个人邮件处理策略。我让我身边的战友们知道我是如何处理邮件的， 并把这个政策放到我所有的邮件末端。如是说 —— “正在尝试个人邮件处理策略 —— 为了戒掉 Email 瘾， 我将强迫自己每隔三小时或以上查看一次 Email，急事请电话/短信/IM 我”，这么做更多的是让别人明白不要指望马上得到回应。其实我查 email 比每 3 小时要频繁，但至少不用马上逼得去回每个 email 了，我可以憋着悠着点。因为如果真的很急，我的 iPhone 应该已经响过了。而且，批量处理真的效率要高很多。不骗你。

会议。开会太容易变成一群人互相在扯对方的蛋。浪费时间而且开完后发现没有结论且很蛋疼。但开会对于 teamwork 很多时候是必要的。如何主持会议是门学问，这里不细谈。不过，你不可能也不需要参加每个邀请你的会议。当你认为你参加某会议于己于人都无太多价值的时候，建议你考虑不去。如果想要有礼貌一点， 那就写个 email 问问主持人你是否可以缺席。通常当你想过这个问题决定发这样的邮件时，答案通常都会是 yes。有些时候我也会很可耻的让我的产品经理替我去开会。当然，我会鼓励他也争取不要去。Only make the meetings you really have to. 同样，我要求我自己的团队在组织和参加会议的时候要慎重，也经常问他们想想看自己花在会议上的时间是不是多了。一个做法是把可能的会议都整合在一起。有一个例子。早些时候，我们会经常收到来自支持团队的比较随意的会面请求。这让攻城狮的一天被会议分割得支离破碎。写代码的都知道没有3-4个小时的连续时间是不容易高潮的。而且这种会议通常效率很低。于是，我们改变了做法，每周安排固定的答疑时间(office hour)和支持团队嗑想法然后 follow up。当然， 紧急的问题另当别论应当马上处理.

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

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

工程师和支持团队之间有着纠结的合作竞争关系(注意， 合作在前)。互联网技术公司中很多人(尤其是聪明人)总是期望工程师对所有问题给出一个让人会心一笑的解决方案。但现实是，不是每一个问题都可以或者应该在技术框架下解决。对于一些具体的问题， 客户支持和运营部门会有一些非常深刻独到的见解。工程师未必行，毕竟很多见解需要不同的专业知识， 依靠实地经验。没错， 工程师可以在代码中自动 log 大量的原始数据，但从原始数据中提炼可靠的判断却并不总能如愿。和很多其他公司的客户或支持部门不同，我们的支持部门招募了质量相当好的员工(很多来自美国名校 —— 在我直接接触的反欺诈支持组 20 来人中就有 3 名斯坦福校友)。因此，当两群都很聪明的人观点相左时，该听谁的呢? 紧张关系再所难免。

不同的工程师团队也存在着合作竞争关系。 反垃圾邮件、安全和反欺诈（我的团队）这几个团队之间存在密切的工作协作关系。这些团队也都尽可能地相互学习，分享经验和技术。但是，有时候各团队独立处理类似但不同的一些问题时，都试图向对方推销自己的解决方案和理念。

如何让合作竞争保持在一种健康有序的状态? 我觉得关键是促进人与人之间的亲密感。把人搞近了，事情就容易了。我花大量时间用在建立和其他团队的关系上面。例如两周一次或者一月一次和其他团队老大们的 1 对 1 碰头会。越相关的团队，头碰得越频繁。我自己或者我的团队成员会有选择性的经常参加一些其他团队的会议 (我们称之为 Friends & Family meeting)。当为一个共同的大项目工作时，我曾安排不同的部门成员（工程师、支持、数据分析、金融财务）坐到一起进行项目冲刺。这是拉近相互之间距离的非常有效的一个做法， 尤其对于减少扯皮的机会。因为互相之间经常会请或被请喝咖啡 (可称之为"咖啡外交")。我也会经常和一些人约定吃工作午餐， 经常聊的是家常， 增的是感情。有的时候一次长距离的散步也更能让人畅所欲言。而这样的紧密关系，在我们面对一个极具挑战性的项目的关键时刻，会帮助大家紧紧的抱团闯关。

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

分配任务委托别人的重要性比较容易理解。因为你不是超人，不能端茶倒水什么都做吃喝拉撒什么都管。有些时候，你往往还不是最适合的人选。当团队一大，事情一多，你一定要学会委托别人来负责合适的任务。对有些领导者而言， 委托别人一个重要的目标可能不是很放心，觉都睡不好；但我非常习惯委托别人，有时候可能太习惯了。这是我一位前老板给我指出来的一个问题。有一次我给一位组员分配了一个既有技术难度又有协调挑战的难题，进程比较缓慢。但我给了他太多的时间空间来折腾， 而事实上他在某些方面需要一些加强，有些方面需要我更多的主动的帮助。我老板指出来，如果我要让别人随便折腾的话，前提是我需要有足够的信心。我需要有事实来逐渐证明我的决定是正确的。需要谨慎委托，因为如果项目失败， 对他而言， 最终负责的人还是我，不是别人。所以我不能以别人不行来给失败的委托埋单。

如果你有一个重要的任务需要委托给别人， 你要么：

1) 已经对此人非常了解，知道他战斗力非凡可以搞定，或者相信他可以迅速学习提高打鸡血搞定；

要么

2) 需要在一开始手把手教他，时不时问他，直到你对他有足够的信心。

具体我是这么做的。项目开始时，我让被委托人给我一个整体计划以及几天内可以完成的任务。一开始经常会面跟进，然后确定后几天的任务。根据每次完成状况来估计他能不能“高快狠”地完成最终的目标。信心逐渐建成后可以减少关于该项目的细节讨论，此时的委托可以放得更开。但有一点要注意，如果跟的太紧的话， 可能让人觉得你对他不放心，他也会做得畏首畏尾，这可能比盲目的委托还更差。所以在委托和谨慎之间， 有一个微妙平衡。

我觉得在这一点上我还要加强，这里也和大家提个醒。

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

一年一度或两度的意见反馈在硅谷公司是非常常见的。它的目的不是设置起来给员工难堪，让他们互相责难的。它的目的是希望员工对自己对他人有更全面的认识，以助进步。意见反馈有自我反馈和同事反馈两部分。自我反馈是自己评定自己，完成了哪些目标，错失了哪些目标，哪些方面做好了，哪些方面还待进步。但由于是自己踢球兼裁判，难免有偏颇。同事反馈，就像一枚镜子，让你看到 180 度之外的自己。在 Facebook, 360 度的正式意见反馈是一年两次，并且和薪酬挂钩。但近年来，意见反馈和薪酬评定逐渐分开。比如我做的一件事就是季度性的意见反馈，时间和正式评定错开。在那几天中，我请求所有相关组的同事在自愿的前提下给我写写关于我直属组员的意见反馈，短短几句都行。我会收集，综合，最后在1-1碰头会时反馈给我的组员。

如果需要等半年才来收集意见的话，很多相关故事早以忘得一干二净。故事越久远，记忆越模糊，意见越空洞， 说了等于没说。而且，意见反馈和薪酬绑在一起，正常人(即使是牛人)都会很自然的把心眼更多的放到薪酬上，而不是意见本身。

除了季度性的轻型意见反馈， 日常的意见反馈如果有的话应当立马传递，趁热打铁效果更好。

如何有效传递整理好的意见也很重要，有句话是说"it's not what you say that matters, it's how you say it". 我没那么极端，我觉得如何传递意见也同样重要。有两种方式我都试过，不确定哪种更有效。这里都谈一谈。一种是以问为主逐渐深入促其思考，比如"how did you think about the meeting you hosted yesterday"; 另外一种是赤裸裸的直入主题， "hey, let's talk about the meeting you held yesterday"， 然后开始谈我自己的感觉.不管哪种方式，一定要给对方一个解释自己行为的机会；永远假设并告诉他我相信他的意愿是好的。为了避免陷入“你昨天做了 xxx”，“"没有， 我做的是 yyy”，“我觉你是做了 xxx”的死循环式的争论，我首先争取和他们在"我们感知的即是事实"这一点上达成共识。基于这点前提， 我们把讨论的重点放在如何做能改变别人的感受，最后让事情能顺利完成， 毕竟大多数重要的事都有很多人一同协作完成。当他们认识到自己想要改进某个方面的时候，如何改是一个相对容易很多的问题 —— 聪明人一向能够找出改进的办法，我所做的就是配合他们做头脑风暴。最终谈话的目的是产生一个下次如何能做的更好的具体方案。

关于有效传递意见反馈， 另有 4 点提一下。

1) 意见反馈不见得都是负面的。它可以是别人的一个长处，你很欣赏，你希望他这方面坚持做，做得更多。比如一句"hey, I really love your weekly summary email with the key metrics at the top. Please keep them coming"，可能产生很好的激励效果。

2) 意见反馈必须摆事实和讲道理。如果你只是告诉别人他很烂，但不说什么时候烂过了以及为什么，除了给他添点火气之外无他用。所以我在相关人员包括自己写意见反馈的时候要求提供实例，比如一句 "I think he could make meetings transparent and shorter by having an agenda, like the weekly data review meeting on last Friday"比"his meeting is too long"，更有血有肉有效。

3) 意见反馈必须是可操作的。让人无从下手的意见意义不大。如果在提意见的同时提出一个方案以供参考就有意义的多。但注意，绝不能是命令的方式 (那是中青宝…)，比如前面的例子"I think he could make meetings transparent and shorter by having an agenda sent ahead of time…"就很容易操作。

4) (个人偏好) 在最近的两个评价周期中，我给 15 个左右的同事(一半不直属我)写过意见反馈。我把我写的直接分享给他们。出于这种想法，在我下笔时就少了很多冲动。因为他们会读，所以我无法做到背后捅刀。因为他们要读，所以我需要写得有意义，容易理解，并且加上很多例子。并且，我欢迎他们和我直接讨论。如此一来，他们也明白我写这些反馈的一片苦心是为了他们进步。

9、你可以比你想象的做得刚好

这不是说说而已。我自己就有一个亲身的例子，我们曾经认为把一个高得离谱的欺诈率降到所允许的范围内会很难，的确很难。但想想看我们最终牛逼了一把，把它降到了比允许上限的一半还要低，感觉很爽，很长一段时间内整个团队士气高昂信心爆棚做事像开了外挂。

牛人们总是不断的超越自己。给他们一个离谱的目标，配以应有的工具，适当的帮助，足够的信心还有一定的时间，他们会让你大吃一惊，也会让自己大吃一惊。这一点，乔帮主是行家，屡试不爽。

但做到这一点有一个前提 —— 不能害怕犯错。如果犯错是被要严惩的，失败是不允许的话，牛人们只能在框框中被圈养，没有办法实现突破。有一句话我经常挂在嘴上"ask for forgiveness, not for permission". 在 Facebook, 大胆行事犯错是容易被原谅的。

但反过来，有一点要小心，就像第 7 点所说的 —— 你不能随便把一个离谱的目标交给一个人，然后期待他来给你惊喜，盲目带来的可能是惊吓。你需要真正的牛人，至少是潜在牛人。而作为一个领导者，你的一个任务是帮助他们，鼓励他们，来引爆自己的潜力点。Facebook 不缺此类待引爆的牛人。

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

有些工程师有一股出于本能的冲动想把自己的程序规模化，甚至在这些程序还没看到大规模使用的曙光之前。我在 Facebook 开始的时候，也是冲动型工程师一类。但经历过几次失败的产品之后，我牢记了这个教训。不要过多设计或者过早优化，把核心功能设计的简单精炼。只有在看到产品有被大规模使用的趋势后， 才来增加功能或增加规模量。有一个我做的产品使用的上限是 200 万月用户(当时 Facebook 整个月用户群是 4000 万左右)，但我的实现已经做了很多额外的功来满足更多的用户，做的时候感觉很爽(感觉自己很牛，感觉再多人用产品也不会崩溃)， 之后感觉很惨。

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

结语:

在 Facebook 的 4 年半很好玩，我学到的感受到的远多于以上的十项，但希望这个分享能对朋友们有点帮助。同时祝所有的朋友在自己现在扮演的角色上都有好运。