在Facebook 工作的十点经验总结
来 源:福布斯中文网发表日期:2012-06-01
我是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。当然, 紧急的问题另当别论应当马上处理。