逍遥右脑 2014-05-10 13:19
我在Facebook学到的10个经验
1、你的远景，但要对细节机动。
作为一个领导者，你需要依附你自己的远景（至少在你负责的业务领域内）而那些和你一起或为你工作的人将依赖你的远见。什么是远景？就是对最终状况的一种描写。是你需要你的团队着陆的处所。是生效之后的新生涯。它是北极星，和方向。这里有一个例子，当我启动支付危险团队的时候，我们只有规则引擎。规则是人写的。一条规则只是一个领有无比有限变量的简单逻辑，例如“如果注册日期少于30天并且支出大于100美元并且是首次支付并且用户来自印度尼西亚，则谢绝交易”
人类难以有效的处置10个以上的变量。咱们需要更加的可丈量化。我们想要使很多机器比人更善于的事件主动化。从而我们建立了一个远景，将我们重要的规矩置换为机器学习模型。这一前景驱使我们增加了一位机器学习范畴的博士和另一位在参加facebook以前有相似实操教训的工程师。赌注宏大，然而将来需要这个。
但你需要对细节灵巧，因为条条大路通罗马。你需要给你的团队以足够的余地空间（wiggle room），只要你的团队是朝着正确的方向以合适的速度前进。另一个故事：一度我对决议树的兴致比回归要大。但是实验算法的工程师告诉我在选择算法的时候他们只有可以疏忽的差别。我可以坚持己见（这确实是当时我实在的想法）但我信赖他并让他撒手去选适合的算法。同设计者合作的过程中也有趣事产生，他们对于字体，色彩，行距及其他都有着求全责备的偏好。我通常让他们由着性子只要对最终结果有利就行。我们想要选择正确的战场开火，这样的战场必须关乎全局，而不是纠缠于部分战斗。
2、只和最好的人配合。
牛人只想和牛人一起工作。他们聚在一起就更牛逼。一流的人通常无法容忍二流货色。什么决议了“最好的人”？我的懂得是那些可能疾速尽其所知，学其所不能，从而完成事情并远超盼望。他们的本能是超出冀望，甚至他们自己的期冀。对他们来说，足够好本身素来都不够好。只占有最好的人在团队中有很多利益。
⑴这让你更加乐意交付。救我的经验来看，牛人不会信任不熟习的人。在接受你的帮助之前，他们需要知道你同他们一样杰出甚至比他们自己还强。否则，他们情愿尽其所能的独立完成。但如果你业已得到证明，他们将会非常信任你并乐于托付给你。一个有着有效托付的牛逼团队简直无所不能。
⑵他们相互为模范，并且籍此提升工作表现。这是很好的关注压力。如果使用切当，可以构成团队的良性轮回。
⑶牛人们彼此挑衅。我记得一位工程师主管曾就我们是否在划定时限之前完成网站翻译所需的代码修正来打赌，他将把头发染成蓝色。这样的挑战往往是的“单调”的工作变成了游戏。成为游戏的一部分将非常有趣。当然往往会有更严正的挑战，而且牛人爱好挑战（不论是挑战别人还是接收挑战）
⑷牛人们互相学到很多。如果不是因为这里有这么多可以学习的话我不会在facebook呆4年。对缺少经验的人来说，这显得越发正确。我们雇佣非常聪明的毕业生，这些人被激发来证实他们的牛逼之处。他们不愿来到一个舒服并且没有挑战性生活的公司。他们想学很多来丰盛他们的经验，完成不可完成的任务并晋升他们的职业门路。他们想要证明“是的，他们可以”。他们想和牛人一起来实现这些。
你不想要二流货色但如何远离他们？首先，慢点招人。在给offer的时候执拗一点。我曾无数次的在应聘决策会议上发现那些有着辉煌履历的人无法得到雇佣只是因为某个口试官觉得这人无法给他以深刻印象。在其他例子当中，那些取得一致通过的候选人仍旧无法失掉雇佣机会因为每个人都只是觉得他将将合乎要求而已。在雇佣问题上，绝大多数情况下，你要风险躲避。（顺便提一下我们也会雇用那些没有全票通过的候选人，只要有一两票强烈推举?你将乐于在信任你员工的问题上冒险）其次，炒鱿鱼要快。让二流货色存在就像服用慢性毒药。一天一点，逐渐但毕竟你会为此挂掉。你要紧你所能的把二流货色踢到鱿鱼轨道上（在某些情况下，法律不让你这么做）我见过一些慢悠悠的鱿鱼，那对团队造成的负面作用可不是闹着玩的。
3、树立高期望并且权衡之。
作为领导者，你需要设定高但现实的期望。足够高使得你的团队不会觉得无聊。现实使得他们不至于油尽灯枯。你要给他们发明一段经验使得旅程停止回想时，他们会说：妈的，我都没想到我竟然做了这个。这个?爆了。在Facebook，象其他硅谷高技术公司一样，期望同回报相联合，因此树立明白的期望本身就至关重要。并且你需要找到一个不容辩论的道路来衡量期望。我花了大量时间来和团队一起刻画我们在下季度里最重要的3-5个目标。目标被分辨委派给单个或一组分工不同的攻城狮，或者被他们抢走。在这一情况下，我们不仅有一个由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。同样，我请求我自己的团队在组织和参加会议的时候要稳重，也常常问他们想想看自己花在会议上的时间是不是多了。一个做法是把可能的会议都整合在一起。有一个例子。早些时候，我们会时常收到来自支持团队的比拟随便的会面要求。这让攻城狮的一天被会议宰割得四分五裂。写代码的都知道没有3-4个小时的持续时间是不容易高潮的。而且这种会议通常效力很低。于是，我们转变了做法，每周部署固定的答疑时间（office hour）和支持团队嗑主意然后follow up。当然，紧迫的问题另当别论应该立刻处理。
有一个被经常忽略的准则–有意识地去思考哪些事情不应该做并且马上不做。例如，哪些是无谓的争论可以避免参与（比如和方舟子的–个人意见），哪些功能可以废弃，哪些关系不应该发展，哪些人应该开掉，等等。我经常问自己一个很简单的问题，我现在正在做的是否对我的目标很重要。如果你明白自己正在做的和自己想要的，答案会明了。Go for it。
6、爱好能有效地下降人们间的缓和。
工程师和支持团队之间有着纠结的合作竞争关系（注意，合作在前）。互联网技术公司中很多人（尤其是聪明人）总是希望工程师对所有问题给出一个让人会意一笑的解决计划。但现实是，不是每一个问题都可以或者应该在技巧框架下解决。对于一些详细的问题，客户支持和经营部门会有一些非常深入独到的看法。工程师未必行。究竟很多见解需要不同的专业常识，依附实地经验。没错，工程师可以在代码中自动log大量的原始数据，但从原始数据中提炼牢靠的insight却并不总能如愿。就像大炼钢年代扔进去的是铁，出来的是铁疙瘩，而非奢望的钢。和很多其他公司的客户或支持部门不同，我们的支持部门招募了品质相称好的员工（很多来自美国名校–在我直接接触的反欺诈支持组20来人中就有3名斯坦福校友）。因而，当两群都很聪明的人观点相左时，该听谁的呢？紧张关系再所不免。
不同的工程师团队也存在着合作竞争关系。反垃圾邮件、保险和反欺诈（我的团队）这几个团队之间存在亲密的工作合作关系。这些团队也都尽可能地相互学习，分享经验和技术。但是，有时候各团队独立处理类似但不同的一些问题时，都试图向对方倾销自己的解决方案和理念。
如何让协作竞争坚持在一种健康有序的状态？我认为症结是增进人与人之间的密切感。把人搞近了，事情就容易了。我花大批时间用在建立和其他团队的关系上面。例如两周一次或者一月一次和其他团队老大们的1对1碰头会。越相关的团队，头碰得越频繁。我自己或者我的团队成员会有挑选性的常常参加一些其余团队的会议。当为一个独特的大项目工作时，我曾支配不同的部门成员（工程师、支持、数据分析、金融财务）坐到一起进行项目冲刺。这是拉近相互之间距离的非常有效的一个做法，尤其对于减少扯皮的机遇。因为互相之间经常会请或被请喝咖啡。我也会经常和一些人商定吃工作午餐，经常聊的是家常，增的是情感。有的时候一次长间隔的漫步也更能让人畅所欲言。而这样的严密关联，在我们面对一个极具挑战性的项目的要害时刻，会赞助大家牢牢的抱团闯关。
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年半很好玩。我学到的感触到的远多于以上的十项。但希望这个分享能对友人们有点帮助。同时祝所有的朋友在自己当初表演的角色上都有好运。