我在Facebook学到的10个经验

我在Facebook学到的10个经验
1、坚持你的远景，但要对细节灵巧。
作为一个领导者，你需要依赖你自己的远景（至少在你负责的业务领域内）而那些和你一起或为你工作的人将依赖你的远见。什么是远景？就是对最终状态的一种描写。是你需要你的团队着陆的处所。是生效之后的新生活。它是北极星，和方向。这里有一个例子，当我启动支付风险团队的时候，我们只有规则引擎。规则是人写的。一条规则只是一个占有非常有限变量的简单逻辑，例如“如果注册日期少于30天并且支出大于100美元并且是首次支付并且用户来自印度尼西亚，则谢绝交易”
人类难以有效的处理10个以上的变量。我们需要更加的可丈量化。我们想要使很多机器比人更善于的事情主动化。从而我们树立了一个远景，将我们主要的规矩置换为机器学习模型。这一前景驱使我们增添了一位机器学习范畴的博士和另一位在参加facebook以前有相似实操经验的工程师。赌注宏大，但是将来需要这个。
但你需要对细节机动，因为条条大路通罗马。你需要给你的团队以足够的余地空间（wiggle room），只有你的团队是朝着正确的方向以合适的速度前进。另一个故事：一度我对决议树的兴致比回归要大。然而实验算法的工程师告知我在取舍算法的时候他们只有可以疏忽的差别。我可以保持己见（这确切是当时我实在的想法）但我信赖他并让他撒手去选适合的算法。同设计者合作的进程中也有趣事产生，他们对于字体，色彩，行距及其他都有着求全责备的偏好。我通常让他们由着性子只要对最终结果有利就行。我们想要挑选正确的战场开火，这样的战场必需关乎全局，而不是纠缠于部分战斗。
2、只和最好的人协作。
牛人只想和牛人一起工作。他们聚在一起就更牛逼。一流的人通常无法容忍二流货色。什么决定了“最好的人”？我的理解是那些可能快捷尽其所知，学其所不能，从而完成事情并远超希望。他们的本能是超越期望，甚至他们自己的期望。对他们来说，足够好本身素来都不够好。只领有最好的人在团队中有很多利益。
⑴这让你更加乐意托付。救我的经验来看，牛人不会信任不熟习的人。在接受你的帮助之前，他们需要知道你同他们一样杰出甚至比他们自己还强。否则，他们情愿尽其所能的独立完成。但如果你业已得到证明，他们将会非常信任你并乐于交付给你。一个有着有效托付的牛逼团队简直无所不能。
⑵他们相互为模范，并且籍此提升工作表现。这是很好的关注压力。如果使用切当，可以构成团队的良性循环。
⑶牛人们相互挑战。我记得一位工程师主管曾就我们是否在划定时限之前完成网站翻译所需的代码修正来打赌，他将把头发染成蓝色。这样的挑战往往是的“单调”的工作变成了游戏。成为游戏的一局部将非常有趣。当然往往会有更严正的挑战，而且牛人爱好挑战（不论是挑战别人还是接收挑战）
⑷牛人们互相学到很多。如果不是因为这里有这么多可以学习的话我不会在facebook呆4年。对缺少经验的人来说，这显得越发准确。我们雇佣非常聪慧的毕业生，这些人被激发来证实他们的牛逼之处。他们不愿来到一个舒服并且没有挑战性生涯的公司。他们想学很多来丰盛他们的经验，完成不可实现的任务并晋升他们的职业门路。他们想要证明“是的，他们可以”。他们想和牛人一起来实现这些。
你不想要二流货色但如何阔别他们？首先，慢点招人。在给offer的时候执拗一点。我曾无数次的在应聘决策会议上发现那些有着辉煌履历的人无法得到雇佣只是因为某个口试官觉得这人无法给他以深入印象。在其他例子当中，那些取得一致通过的候选人仍旧无法失掉雇佣机会因为每个人都只是觉得他将将合乎要求罢了。在雇佣问题上，绝大多数情况下，你要危险躲避。（顺便提一下我们也会雇用那些没有全票通过的候选人，只要有一两票强烈推举?你将乐于在信任你员工的问题上冒险）其次，炒鱿鱼要快。让二流货色存在就像服用慢性毒药。一天一点，逐渐但毕竟你会为此挂掉。你要紧你所能的把二流货色踢到鱿鱼轨道上（在某些情况下，法律不让你这么做）我见过一些慢悠悠的鱿鱼，那对团队造成的负面作用可不是闹着玩的。
3、树立高期望并且衡量之。
作为领导者，你需要设定高但现实的期冀。足够高使得你的团队不会觉得无聊。现实使得他们不至于油尽灯枯。你要给他们发明一段教训使得旅程停止回想时，他们会说：妈的，我都没想到我竟然做了这个。这个?爆了。在Facebook，象其他硅谷高技巧公司一样，冀望同回报相联合，因而建立明白的盼望自身就至关主要。并且你需要找到一个不容辩论的道路来衡量奢望。我花了大量时间来和团队一起刻画我们在下季度里最重要的35个目标。目标被分辨委派给单个或一组分工不同的攻城狮，或者被他们抢走。在这一情况下，我们不仅有一个由3到5个权衡指标组成的名单，使得我们可以籍此疾速地说出来我们在干嘛，同时也知道每个详细目标后面是谁。团队的成功同个体表示非亲非故。例如，我当年团队最大的奉献是在一年时间里，通过每季度不同的指标，终极下降了信用卡支付争议率75%。
有一点要强调的是?你仍是要现实。在你只有10%的市场份额的时候却空想10多少倍的收入增加无疑不事实。史蒂夫乔老爷十分擅长推进他的团队超出潜能但同时也榨干他们（只管如斯他们是这样为他们所做的而骄傲）99。9%的引导不是乔老爷，当然他们也不须要是。但你依然能够通过驱动一个可连续性的团队来获得胜利同意识到他们的极限并无抵触。
4、倾听数据但不要单纯依附之。
决定产品方向时，要的是设想力，豪情和胆量，而不是数据。数据能让你的团队沿着正确的方向前进而不出轨，也有助于产品从“一开始是什么样”到“最后应该是什么样”的逐渐优化成型。但数据不能帮你决定方向。举个例子，当我们在人工智能（机器学习）上压上我们团队所有的资源的时候，我们局促不安。但是我们深信一点，现有的基于人工规则引擎的防欺诈系统会很快成为死胡同，因为它太呆板而且不易规模化以处理大数据。所以，就像在片子指环王中Frodo明知通向Mordor的途径很黑很冷很危险，但那是一条他必需要选择去走的路；我们选择了在机器学习上压上所有的宝。失败，整个团队会很丢脸；但我们决定走艰巨但我们认为是正确的路。这种思路同样利用在如何设计用于用户讲演（外部工具）和案例审查（内部工具）的工具来应对潜在的诈骗行为。我们最后决定的方向是”进行自动处理”和”建立反馈机制”。直接抛给人工来处理总是很容易被选的一条路，因为只要建立一个人多人傻的客户支持团队即可。Lame！我们希望通过自动处理来解决大部分的欺诈案例，而把精神则放在那些确实需要独自处理的特别案例上，同时把从业务支持团队（即客户支持部门）的处理意见自动采集并集成到下一轮的机器学习中去。由此，我们的机器判定会越加准确和聪明且与时俱进。
但你不能疏忽数据。不数据的支持而一味靠直觉走黑路，很轻易走岔道，甚至大错特错。有一段时光我们以为匍匐工具（通过火析关系的cookie，信用卡）可能可以找到良多讹诈的同伙。通过试验成果却发明，这种预期是否成破很大水平上取决于当前风行的欺诈行动的特色。比方，当失贼或贩卖信誉卡的案例无比广泛的时候，关联分析是一种有效的方式。但如重要情形是帐户被黑或小宝们冒用妈妈的信用卡去网游花费时，关联剖析就作用不大。直觉在现实前面碰了一脸的灰。不外荣幸的是咱们很快意识到这点且把这个名目叫停了，所以没有挥霍太多的资源。
另外，顺带提一下A/B测试。A/B测试并不会告诉你去做什么产品，但它可以帮你确定实现产品时的哪个轻微版本更能揪住用户大爷们的心。
5、远离时间吞噬者。
刚进Facebook唱工程师的时候，我非常享受那种昼夜泡在码海中的感到。后来缓缓的承当的项目义务越来越大越来越多，写代码的时间越来越少（但绝大多数时候仍占大头）。有时候的是把时间花在决定产品的方向和设计上。很多事情是和产品经理设计职员一起搞的。但在Facebook攻城狮们有很大的发言权甚至有些时候是拍板的权利。Facebook愿望攻城狮们有王者风范。Facebook盼望攻城狮能决定自己要做什么应当做什么，而不是总是”被决定”做什么（一种流行的说法是，write your own job description）。因此，我花了大量的时间在思考这些问题?哪些功能需要增加，哪些功效需要删掉，需要开端或停掉哪些测试，我们正在流血流汗的是不是当初最最最重要的问题，我们是该花时间优化用户交互流程呢，还是减少犯错率，还是让体系更快，等等。这些问题很伤头脑，答案经常不断定，比一个劲码得手抽筋要难。但这些问题很重要，甚至可能决定了你熬的日日夜夜毕竟有没有必要。提议所有的攻城狮思考思考代码之外的这些问题，团队领导者就更有必要了。当然，攻城狮的大多数时间还是应该花在代码上。
那究竟哪些时间不应该被浪费呢？
很多，但我只举两个我认为最重要的例子。
邮件。不是所有邮件都发而同等。有些邮件纯洁打酱油的。有些邮件是不需要马上处理的。我尝试使用过滤规则来踢掉打酱油的邮件，凸起需要马上处理的重要邮件。对此，分享两点。
（1）建立一个适合你的邮件过滤系统。我会对重要和紧急的邮件做即刻回复，而暂缓处理那些可以等到晚上再回复的邮件（尤其是发自我自己的团队，产品经理，兄弟连和顶头的不顶头的上司们的邮件）。但是，我要确保在我挣扎的爬到床上之前，把这些邮件全体处理掉，读的读，回的回。对于那些仅供参考的邮件，过滤系统会将其塞到某个固定的角落，我隔三差五去瞅瞅。此类邮件诸如某酒鬼讯问NapaValley哪个酒窖比较误点等等。这些邮件通常比较有趣，挖的坑很大很深所以也很耗时间，我通常不跳或者不马上跳。
（2）广而告之你的个人邮件处理策略。我让我身边的战友们知道我是如何处理邮件的，并把这个政策放到我所有的邮件末端。如是说?“正在尝试个人邮件处理策略为了戒掉Email瘾，我将逼迫自己每隔三小时或以上查看一次Email，急事请电话/短信/IM我”这么做的是让别人明确不要指望马上得到回应。实在我查email比每3小时要频繁，但至少不必马上逼得去回每个email了，我可以憋着悠着点。因为如果然的很急，我的iPhone应该已经响过了。而且，批量处理真的效率要高很多。不骗你。
会议。开会太容易变成一群人互相在扯对方的蛋。糟蹋时间而且开完后发现没有论断且很蛋疼。但开会对于teamwork许多时候是必要的。如何主持会议是门学识，这里不细谈。不过，你不可能也不需要参加每个邀请你的会议。当你认为你参加某会议于己于人都无太多价值的时候，倡议你斟酌不去。假如想要有礼貌一点，那就写个email问问主持人你是否可以缺席。通常当你想过这个问题决议发这样的邮件时，谜底通常都会是yes。有些时候我也会很可耻的让我的产品经理替我去开会。当然，我会勉励他也争夺不要去。Only make the meetings you really have to。同样，我请求我自己的团队在组织和参加会议的时候要稳重，也经常问他们想想看自己花在会议上的时间是不是多了。一个做法是把可能的会议都整合在一起。有一个例子。早些时候，我们会经常收到来自支持团队的比拟随便的会见恳求。这让攻城狮的一天被会议宰割得四分五裂。写代码的都知道没有34个小时的持续时间是不容易热潮的。而且这种会议通常效力很低。于是，我们转变了做法，每周支配固定的答疑时间（office hour）和支持团队嗑主意然后follow up。当然，紧迫的问题另当别论应该立刻处置。
有一个被经常忽略的准则?有意识地去思考哪些事情不应该做并且马上不做。例如，哪些是无谓的争论可以避免参与（比如韩寒和方舟子的?个人意见），哪些功能可以废弃，哪些关系不应该发展，哪些人应该开掉，等等。我经常问自己一个很简单的问题，我现在正在做的是否对我的目标很重要。如果你明白自己正在做的和自己想要的，答案会明了。Go for it。
6、爱好能有效地降低人们间的紧张。
工程师和支持团队之间有着纠结的合作竞争关系（注意，合作在前）。互联网技术公司中很多人（尤其是聪明人）总是期望工程师对所有问题给出一个让人会意一笑的解决方案。但现实是，不是每一个问题都可以或者应该在技术框架下解决。对于一些具体的问题，客户支持和经营部门会有一些非常深刻独到的见解。工程师未必行。毕竟很多看法需要不同的专业常识，依附实地经验。没错，工程师可以在代码中自动log大量的原始数据，但从原始数据中提炼牢靠的insight却并不总能如愿。就像大炼钢年代扔进去的是铁，出来的是铁疙瘩，而非期望的钢。和很多其他公司的客户或支持部门不同，我们的支持部门招募了品质相称好的员工（很多来自美国名校?在我直接接触的反欺诈支持组20来人中就有3名斯坦福校友）。因此，当两群都很聪明的人观点相左时，该听谁的呢？缓和关系再所不免。
不同的工程师团队也存在着合作竞争关系。反垃圾邮件、保险和反欺诈（我的团队）这几个团队之间存在亲密的工作协作关系。这些团队也都尽可能地相互学习，分享经验和技术。但是，有时候各团队独立处理类似但不同的一些问题时，都试图向对方倾销自己的解决方案和理念。
如何让配合竞争坚持在一种健康有序的状况？我感到症结是增进人与人之间的密切感。把人搞近了，事件就容易了。我花大批时间用在树立跟其他团队的关系上面。例如两周一次或者一月一次和其他团队老大们的1对1碰头会。越相干的团队，头碰得越频繁。我本人或者我的团队成员会有抉择性的常常加入一些其余团队的会议。当为一个独特的大项目工作时，我曾部署不同的部分成员（工程师、支撑、数据分析、金融财务）坐到一起进行项目冲刺。这是拉近彼此之间间隔的非常有效的一个做法，尤其对减少扯皮的机遇。由于相互之间常常会请或被请喝咖啡。我也会常常和一些人商定吃工作午餐，时常聊的是家常，增的是情感。有的时候一次长距离的漫步也更能让人畅所欲言。而这样的严密关联，在我们面对一个极具挑衅性的项目标要害时刻，会辅助大家牢牢的抱团闯关。
7、拜托并使之生效。
调配任务委托别人的重要性比较容易理解。因为你不是超人，不能端茶倒水什么都做吃喝拉撒什么都管。有些时候，你往往还不是最合适的人选。当团队一大事情一多，你一定要学会委托别人来负责合适的任务。对有些领导者而言，委托别人一个重要的目标可能不是很放心，觉都睡不好；但我非常习惯委托别人，有时候可能太习惯了。这是我一位前老板给我指出来的一个问题。有一次我给一位组员分配了一个既有技术难度又有和谐挑战的困难。过程比较迟缓。但我给了他太多的时间空间来折腾，而事实上他在某些方面需要一些增强，有些方面需要我的自动的帮助。我老板指出来，如果我要让别人随便折腾的话，前提是我需要有足够的信心。我需要有事实来逐渐证明我的决定是正确的。需要谨慎委托。因为如果项目失败，对他而言，最终负责的人还是我，不是别人。所以我不能以别人不行来给失败的委托埋单。
如果你有一个重要的任务需要委托给别人，你要么
（1）已经对此人异常懂得。晓得他战役力不凡可以搞定；或者信任他可以敏捷学习进步打鸡血搞定；
要么
（2）需要在一开始手把手教他，时不断问他，直到你对他有足够的信心。
详细我是这么做的。项目开始时，我让被委托人给我一个整体打算以及几天内可以完成的任务。一开始经常会面跟进，然后肯定后几天的任务。依据每次完成状态来估量他能不能”高快狠”地完成最终的目标。信心逐渐建成后可以减少关于该项目的细节讨论。此时的委托可以放得更开。但有一点要留神，如果跟的太紧的话，可能让人认为你对他不释怀，他也会做得敢作敢为，这可能比盲目的委托还更差。所以在委托和谨严之间，有一个奥妙均衡。
8、反馈是一个持续过程，不是一个一年一两次的事件。
一年一度或两度的意见反馈在硅谷公司长短经常见的。它的目的不是设置起来给员工为难，让他们互相非难的。它的目的是生机员工对自己对别人有更全面的认识，以助先进。意见反馈有自我反馈和同事反馈两部门。自我反馈是自己评定自己，完成了哪些目标，错失了哪些目标，哪些方面做好了，哪些方面还待进步。但因为是自己踢球兼裁判，未免有偏颇。同事反馈，就像一枚镜子，让你看到180度之外的自己。在Facebook，360度的正式意见反馈是一年两次，并且和薪酬挂钩。（经典语录 ）但近年来，意见反馈和薪酬评定逐步离开。好比我做的一件事就是季度性的意见反馈，时间和正式评定错开。在那几天中，我要求所有相关组的同事在被迫的条件下给我写写对于我直属组员的意见反馈，短短几句都行。我会收集，综合，最后在11碰头会时反馈给我的组员。
如果需要等半年才来收集意见的话，很多相关故事早以忘得一尘不染。故事越长远，记忆越含混，意见越空泛，说了即是没说。而且，意见反馈和薪酬绑在一起，正凡人（即便是牛人）都会很天然的把心眼的放到薪酬上，而不是意见本身。
除了季度性的轻型意见反馈，日常的意见反馈如果有的话应当立马传递。趁热打铁后果更好。
如何有效传递收拾好的意见也很重要。有句话是说“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年半很好玩。我学到的感触到的远多于以上的十项。但希望这个分享能对朋友们有点帮助。同时祝所有的友人在自己现在表演的角色上都有好运。
0
7

版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请发送邮件至 lxy@jiyifa.cn 举报，一经查实，本站将立刻删除。