Noter
相关记录

[ 摘记 ]    in《 创业笔记 》
推荐序 学习Facebook文化

文/李开复 创新工场CEO

认识王淮是在今年初的天使大会上，薛蛮子是这么介绍他的：“这个年轻人刚从Facebook回来，是斯坦福大学的高才生，Facebook的早期员工，最早的中国籍工程师之一。现在回中国想做点事情。” 王淮很腼腆地笑了笑。年轻人看起来蛮和气，不像其他的一些工程师那么nerdy（无趣乏味）。这几个月来，数次与王淮交流合作，也都非常愉快。

后来王淮请我为他介绍Facebook文化的书写序，我欣然答应。为什么我答应得这么快呢？

第一，Facebook绝对是一家伟大的公司。硅谷每5到10年出一家改变世界的公司，Google（谷歌）之后就属Facebook了！Facebook从哈佛的学生宿舍中走出来，逐渐成长为全球最大的社交网络巨人，成为10亿人每月都会登录使用的网站。这意味着全球范围内每7个人中就有一位是其用户。

Facebook上面有1400亿张图片，已然成为世界上最大的图片库。如果你到美国，你会发现公司、品牌、电影已经不对外广播自己的网址，而告诉大家如何在Facebook上关注自己！这样的一个公司，是我们每个中国创业者和投资者都梦寐以求的。

王淮作为Facebook早期员工，一定可以原汁原味地把Facebook成长成功的故事讲给我们听。对于Facebook文化中的精髓，王淮做了很深入的观察和分析。当然，作为早期员工，他同时也是参与打造Facebook文化的贡献者之一。我相信王淮是非常有资格解释Facebook怎么做，但更重要的是为什么这么做的人。

Facebook成为如此伟大的公司既有偶然也有必然，既需要运气但更需要实力。我们不需要过多关注其运气， 就好像在国际象棋界中有句名言“只有好的棋手才会走运（Only the good players are lucky）”，我们应该关注Facebook究竟先进在哪里，哪些东西支撑着它走到今天，哪些东西可能适合中国的互联网行业去借鉴学习。

第二，Facebook的创始人和CEO（首席执行官）扎克伯格是绝对值得关注和学习的创业者。雅虎、Google和Facebook都属于快速成长的公司，但是前两个公司的创始人自身成长速度无法跟上公司成长速度，不得不从外部引入CEO。但是，扎克伯格能够和Facebook同速成长，CEO从19岁创业做到今天。

扎克伯格最喜欢三句话。1.维吉尔：“天佑勇者。”2.毕加索：“每一个孩子都是天生的艺术家，问题是长大后如何保持童心。”3.爱因斯坦：“凡事都应简化到不能再简化。” 这三句话也让我们看到他的心灵深处和博学多才。相信阅读王淮的书可以让我们更好地理解扎克伯格。

第三，王淮本身就是一个很好的学习对象。扎克伯格无论多牛，他毕竟是100%的美国人，而王淮则是100%的中国人。

我相信，王淮作为一名早期员工加入到一个创业型的公司，是需要实力和勇气的。据我所知，进入Facebook绝非易事。Facebook在人才济济的硅谷坚持非常苛刻的面试标准，他们“只和最好的人合作”的招人策略被执行得非常彻底，更何况是在早期的时候。

加入Facebook也需要勇气，毕竟创业公司失败的概率远高于已经找到成熟商业模式的公司。这个过程，非常考验团队的耐心和毅力，以及面对逆境时的坚持。尤其是国人对工作的稳定性和绿卡都非常看重，创业公司对于此有劣势。所以很多很出色的工程师更愿意选择像Google、微软、雅虎等成熟的科技公司。但王淮选择从当时状态仍非常不错的雅虎加入还未爆发的Facebook，从一个工程师成长为团队管理者，可见他有一颗无法安静的心，一颗追求刺激和追求成长的心。而这些，也在《打进Facebook》和《从个人成长为团队管理者》两章中得到充分的验证。对于在创业的年轻人，在职业生涯早期的年轻人，相信有很多借鉴价值。

他从一位工程师到研发经理的成长过程，对于职场的很多新人应该有所启发。接受挑战进入不熟悉的支付领域是给予他的一个机会，一个有巨大风险的机会。从零开始打造一支团队，相当于在公司内部进行再创业。对那些非创业型的工程师，王淮的经验也会有价值，因为他做到了工程师到管理者的成功跨越。

最后，这本书可读性很强，而且“干货”很多。王淮曾经摘选过部分发在他的博客上，其中一篇介绍Facebook文化的文章叫作《我在Facebook的十点经验分享》。如此一篇过万字的长文获得过万次的转发是非常罕见的。里面提到了很多他在开发产品、打造团队过程中的经验，比如“树立高的期望值并加以衡量”、“重视数据而不盲从数据”“不要过多设计或者过早优化”，等等。这本书对他的经验和体会做了广度和深度的扩展，并提供了更多的故事。

所以，无论中国是否能出一个Facebook或扎克伯格，我相信理解Facebook，并从王淮的亲身体验学习，对于中国的创业者、工程师、学生都会有莫大的帮助。
原文出处：http://www.huxiu.com/article/8536/1.html;
关联记录：
   转记    评论
[ 摘记 ]    in《 创业笔记 》
我在Facebook的十点经验分享

我是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年半很好玩。我学到的感受到的远多于以上的十项。但希望这个分享能对朋友们有点帮助。同时祝所有的朋友在自己现在扮演的角色上都有好运.
原文出处：http://www.huxiu.com/article/8536/2.html;
关联记录：
   转记    评论
[ 摘记 ]    in《 创业笔记 》
自序：亲历Facebook爆发的5年

2007年4月23日，忐忑不安的我加入了一家名不见经传的创业公司——Facebook（国人称脸谱）。我应该算是Facebook第二位中国籍工程师，也是第一个中国籍研发经理。加入的时候，公司不到150个员工。收入，嗯，可以忽略不计。我加入的就是刚刚组建不久的广告组，这个组开始尝试赢利模式。那时我认识所有的工程师。

Facebook最早加入的一批中国人当中，大多是我推荐的。后来的一大批人是这些我推荐的人介绍的。我开玩笑地对这些人说：“悔恨当年没跟你们签订关于推荐费的分成协议啊！” 在比较长的一段时间内，我位居公司推荐成功榜首。我花了很多时间去结识和说服这些牛人，刺激他们对Facebook产生兴趣并加入Facebook。为此，和其他几位同事一起，我们收到过首席运营官桑德伯格 （Sheryl Sandberg）亲自写的感谢信。
  zhuo注：找人：花时间、想办法，激发他们对海洋的热爱！   (2013-01-04 18:00)  评论 (0)    

我记得我第一次把Facebook弄得无法访问，并持续了半个小时左右时的情景。在修复完仍惴惴不安的时候，我记得一位公司前20号的资深工程师对我说“Harry（我的英文名），you cannot claim you are a Facebook engineer if you have never brought the site down!（如果你从来都没有让整个网站崩溃的话，你就不能说自己真正是Facebook的工程师！）”

2010年6月，在创建和管理支付安全和工具组6个月之后，我终于通过考验，从技术线转到了管理线，成为第一位中国籍研发经理。从技术到管理，要在管理代码之外，学会管理团队。Facebook的逻辑很简单：在你正式获得一个新的职位之前，你必须已经在这个职位上成功地运作了6个月。这个组里的每一个人都是我自己从新兵营或者其他组挖过来的，我很怀念这当中的艰辛。

一转眼，4年半过去了。2011年9月底，我带着激动、带着不舍离开了一起生活了4年半的同事。我记得同样很早加入的一位老美同事和我说：“Harry, we built Facebook. Be proud of it.（我们打造了Facebook，为此骄傲吧。）”我走的时候，Facebook有3000多员工，800多工程师，有8亿左右的活跃用户，年净收入在10亿美金左右。大多数工程师我不认识。Facebook已经从一开始的大学生社交网络渐变成一家几乎无人不知的社交巨无霸。

这是Facebook爆发的5年，黄金发展的5年。看着全世界的人逐渐被连接到一个网络中的5年，这是改变人类历史的5年。

这个题目很嚣张——“打造Facebook”。谁有资格可以说这句话呢？当然，扎克伯格最有资格，但他不会亲自来告诉你，至少从目前的情况来看，近几年都不大可能。而且，Facebook不是一个人的公司，公司里的每一人，尤其是工程师，既是公司文化的承受者，同时也在不断地改造着公司的文化。我想强调的是团队，是团队的力量打造了Facebook。而让团队凝聚在一起并充满战斗力的，是其文化。这种文化，包括一些做事的方式、为什么这么做的原因和对这些做法和原因的认同。写这本书，是想剖析Facebook文化的精髓，还有这里面的思考过程和前后的变化，详细解释当中最有价值和最值得学习的那几点。尤其作为早期员工，我们奠定了这些文化的基础。

我希望这是一本充满“干货”的书，能给所有对Facebook、对硅谷文化感兴趣的朋友一个机会，从内到外地了解这种工程驱动、产品导向的方式究竟如何打造科技创新公司。

而对于创业的朋友，里面提到的问题，比如，新兵训练营运作文化、工具文化、导师文化、开发速度和质量的平衡、开发流程，或是个人发展、团队管理的一些经验，等等，都希望能有一些启发。尤其对于中国这样一个充满互联网创业机会的国家，有这么多非常聪明、非常勤奋的创业屌丝们，这本书也许能帮大家少走一些弯路。

所以，在磨铁和我磨了一段时间后，我终于答应写这么一本书，这是全世界第一本也是唯一一本前员工对Facebook文化所做的思考和介绍，没有之一。希望有用也有趣。此外，谨将此书献给我的太太黄茜茜，感谢她这么多年来一直对我这个工作狂的支持。Have fun reading!（愉快地阅读吧！）
原文出处：http://www.huxiu.com/article/8536/3.html;
关联记录：
   转记    评论
[ 摘记 ]    in《 创业笔记 》
要点： 导师Mentor文化   
读点：寻找一个你可以信赖的Mentor

前段时间和著名的社交数据科学家Andreas Wegiend(weigend.com)在@杭州TCOFFEE做一个活动的时候，在问答阶段，有人问道，对于数据挖掘和分析这方面的知识积累非常不够，如何提高。Andreas提出了找一个合适的Mentor，帮助他们提高这方面的能力。我强调了我对Mentor作用的认可。我在Facebook的这4年半，有过3个Mentor；他们对我在为人处事，认识自己的不足并如何提高都给了我很大的帮助。更重要的，他们是作为朋友作为前辈在帮我这个人，而不仅仅因为我们是同事才这么做。

什么是Mentor？为什么需要Mentor？

Mentor，就是一位生活中的朋友，他愿意在某一方面帮你提高。Mentor直译成中文就是导师，但更应强调的是真心的帮助，而非教和授，师和生的关系。为什么需要Mentor呢？每个人都在建造自己的生活，但很多前人成长的经历对于你应该很有借鉴价值。一种笨的办法是所有的困难都自己扛，通过自己的摸索去解决。另外一种聪明的做法是有一个Mentor能够真心诚意地提供他的经验和建议，帮助你找到一个更加高效的方式成长。当然，真正的问题还是需要靠自己去解决，Mentor给你的只是他的经验，他的建议，你不能依赖他来帮你做决定；他只是你的参谋，不是你的老板。你是你自己的老板（老美经常说的“You are your own boss”）。如果你有这个一个人，他愿意帮你，他能够帮到你，那他将是你人生中的贵人。我对Mentor只有两个条件，一个和我聊得来，有chemistry，愿意帮我，也就是中国人常说的缘分；另外一个就是在某一方面，他有比我更多的想法，经验，他能够帮我提高。

我的Facebook寻找Mentor的经历

我在Facebook的这4年半，有过3个Mentor。这里谈两个。
一个是我刚加入Facebook时候的顶头上司。他后来成为Facebook第一批的三位工程总监之一，但后来并不负责我所在的组，所以在业务上我和他没有直接或者间接的上下级关系。我非常欣赏他在工程师文化和管理方面的很多想法，原来直接带我的时候关系也很好。我给他发了一封邮件，表明了我非常欣赏他，希望他能做我学习工程师管理方面的Mentor，我无以回报，只有感激。很快，他回信说没问题。我们安排了每两周一起到公司周边的餐馆吃午餐。我带着在团队建设中碰到的各种问题以及我所思考的应对方法，然后再和他建议的比对讨论，看看如何去吸收他的思路以改进想法。我们的一对一午餐会坚持了快一年直到他离开Facebook。我能感受到，他是作为一位朋友一个前辈在帮我这个人，而不仅仅因为我们是同事。

另外一位就是我在商业组的老板。当时我老板想要升我做经理，但Facebook的理念是升职到一个职位前，必须已经在这个新的职位上非常顺畅的运作三到六个月；所以是行事在前，升职在后。由于我之前没有任何的管理经验，我老板在我转职之前要培养我在这方面的能力。但让自己的老板做Mentor是比较难处理的一件事。Mentor给的建议，是否采纳，如何采纳，都是自己的事。然而，老板作为Mentor，他的建议究竟只是建议还是任务；采纳的结果如何，会直接影响他对你的评价，还有你对他的评价；这种利益上的考量会让双方在交流中有所顾忌和保留。虽然我老板对我成长的帮助非常大，但中间让人纠结的时候也很多。基于这样的原因，我不建议在和自己在业务上有上下级的人当中寻找Mentor。

如何去寻找Mentor和如何Mentor相处？

我觉得下面的五点很重要。

1）是朋友。如果不是真正的朋友，对于Mentor这种出力但没有直接利益的事情不会有人愿意去做。他可以开始是你的老板，是你的老师，是你的前辈，是你的校友，是你的合作伙伴，但他认可你的为人，赏识你的潜力，和你做了生活中的朋友。这种朋友关系是Mentor关系的基础。

2）在某一个领域能够帮你提高自己的价值。我在Facebook的Mentor中，大多数是关于管理方面。因为在产品技术方面，我并不需要一个Mentor的帮助来成长。当时管理对于我来说是一个黑盒子。但我在Facebook的朋友中找到了这方面的牛人，他们可以作为我学习的对象。记得，Mentor的最终目的是帮你修炼某一方面的内功，而不是给你提供解决方案，帮你介绍人这些具体的事情。

3）积极主动。一个某一方面的牛人朋友，是不会主动说我来做你的Mentor，这样显得太自作多情。一个好的Mentor，是需要你去争取，去主动开口。你在主动争取的同时，别人可以看到你是一个真心上进的人；如果是你的朋友，如果他不是已经忙的昏天暗地，他是会愿意帮你的。

4）对待Mentor的帮助要心怀感激。心怀感激绝对不是指物质报酬。需要依靠报酬去激励的Mentor那是付费的Consultant（咨询顾问）；他们可以帮你办事，但不关心你个人的发展。你需要非常尊重Mentor的时间，在交流前做好准备，带着话题带着案例去，让一个讨论有很好的基础。而不是天马行空，胡侃瞎聊。比如，在管理方面，一个“如何激励员工自发超越期望去完成目标”的主题，加上一个团队里的真实案例，可以让这个话题在理论层面和实践层面都可以有很好的讨论，这样的交流帮助最大。

5）对每次和Mentor的交流都做总结做记录。如果你把每次的交流当做一次提高的机会，那对交流做总结可以极大化这种提高。对交流的总结让你可以反复思考对方的建议和经验，看看他以前碰到的问题对你现在的问题，对你以后面对类似的问题有没有真正的帮助。把这种思考总结记录下来，可以让自己的思绪更加清楚。等回头看看之前的交流记录，你会发现自己在某一方面清晰的成长轨迹。

后语

Mentor文化在美国非常盛行。一位广为认知的例子就是Facebook的COO谢丽尔·桑德伯格（Sheryl Sandberg） 和原来她在哈佛的教授后来的Mentor 拉力·萨姆斯（Larry Summers）的故事。桑德伯格当然很幸运，但好运都是为了积极主动的人所准备。你可以从很多中高端人才的背后看到这样的故事。在生活中工作中寻找合适的Mentor帮自己提高，在美国很常见。这样的例子中国还非常欠缺。一个很重要的原因就是中国人比较害羞，不容易主动开口。感觉如果是一个牛人，那么他高高在上，不屑于花这个时间来帮你。其实不然，如果一个生活中的牛人朋友了解你赏识你，他是会愿意帮你的。如果真的被拒了，比起从来没问过，你也不会损失什么。朋友，环顾你的四周，看看谁是有可能做你的Mentor，开口试试。
原文出处：http://www.huxiu.com/article/8536/4.html;
关联记录：
   转记    评论
[ 摘记 ]    in《 创业笔记 》
要点： 工具文化   
以FB为案例剖析科技公司应有的工具文化

前段时间和大众点评的CEO张涛聊天的时候碰到内部工具这个话题，我们都非常推崇一个优秀的技术公司应有有一个非常强势的工具文化。在工具上，我有很深的体会，我说那不如我把我的理解通过Facebook的一些实践例子来阐述一下，希望对科技公司有些帮助。

不断发展、改进公司的内部工具，可以极大提高每个员工的工作效率，可以减少运营人员的数目；这样既改善了整体协调，又减少了整体开支。

为了帮助工程师更好地进行产品开发，Facebook对于内部工具（Tools）是非常非常关注的。招聘我进公司的总监黄易山，就是这方面一个最有力的倡导者，他极度建议，公司要把最好的人才放到工具开发那一块，因为工具做好了，可以达到事半功倍的效果，所有人的效率都可以得到提高，而不仅仅是工程师。

Facebook有两个工具组。一个叫研发工具组（Dev Tools），专门负责研发工具的开发和维护，所有有助于工程师开发速度和质量的工具，主要服务对象是内部工程师。另外一个叫网站支持和工具组（Site Support and Tools），主要负责公司里面所有的通用工具的开发和维护，关注的主要是方便用户和Facebook的交流以及Facebook内部的沟通，主要都是通讯工具，服务对象是用户和所有员工。

研发工具有哪些呢？

一开始新的工程师加入Facebook，需要分配自己的开发服务器，Facebook就做了一个工具来管理分配所有的开发专用服务器。在一个页面上你可以很清晰的看到所有的开发服务器,包括哪些人是现在的使用者，什么时候申请分配的，服务器的操作系统版本，配置信息等等；对于空余的服务器，你可以一键申请，并自动初始化该服务器。这让刚加入的菜鸟们可以迅速的获得自己的研发活动空间。

工程师最重要的工作就是写代码。针对代码管理，Facebook做了很多工具，这里解释部分工具供参考。Facebook的代码库管理是通过一种叫GIT的开源管理系统，为此开发了一些工具来集成GIT。比如，一个工具是在提交代码之前自动的检测所修改的代码是否符合公司代码规范，如果不符合，该工具会自动警告，但把决定权交给工程师。Facebook提倡对修改的代码写测试案例，在代码提交时会自动检测是否存在覆盖这些修改的测试案例，如果没有，会警告，但工程师仍然可以强制提交。但这种情况下代码若出错给网站带来巨大危害的话，工程师可能会被严厉批评，因为这本是可以避免的错误，是人性的狂傲忽视了工具的提醒。在代码审查（Code Review）方面，Facebook做了一个可视化的工具，现已开源，叫Phabricator [1]；工程师可以在页面上非常方便的针对每一段（单行或者多行）代码进行交互讨论；负责审查的工程师可以接受代码改变，可以提出疑问要求原作者继续修改，可以提出自己不适合以推出该代码审查，等等。只有代码被明确接受之后才能被工程师提交到服务器端的代码库，这一点集成到提交工具中强制执行。基本理念就是凡是被很多人不断重复的好的习惯，要将其自动化，绑定到工具之中。以“Don’t make me think”的方式来推广好的practice。

Facebook的代码发布是灰度发布，所以做了一个方便设计灰度发布的工具。在这个工具中，工程师和产品经理（也可以授权给其他非研发人员）可以设计新产品发布的目标人群特点（比如年龄，性别，地域，教育，等等方面做出限制）及发布的人群比例（在0-100%之间自由调整），所有的改变不需要代码的改变，只需要在工具页面上点击鼠标即可，让灰度发布变得很轻松。

发布的过程由一个利用点对点（BitTorrent）算法实现的工具进行多线程同时发布，对于更新几十万台机器只需要几十分钟。由于是不间断的发布，对公众的服务不可以停，所以Facebook会将一部分的机器从公众服务状态中拿下来，更新之后再放回，然后继续下一批，知道所有机器都被更新。这样就可以保证在任意状态都有足够多的机器来支持用户访问。整个工程都是通过工具来自动实现。而监控这个发布工程的进展，也有一个工具检测并且将其进度可视化，你可以很方便的看到哪些服务器更新了，现在正在更新哪些服务器，整个网站的进度是百分之几，等等。

发布之后的数据监测更是重点。 Facebook做了很多工具让数据监测变得容易。数据收集只要1-2行代码即可完成，数据的整理分类存储皆在后台的上万台服务器上自动完成，数据的可视化报表只需要通过一个页面工具点点鼠标设置即可即时生成，而不需要任何代码；数据波动的自动警报也可以设置，可以自动发邮件发短信，可以要求24小时全球轮班的站点稳定工程部门（Site Reliability Engineering)按照你既定的反应方案，直到最后打电话给你，直接把你从床上拽起来。在4年半内这样的事件发生在我身上至少有10次了。

还有一种工具是人为的，我们组经常用。就是把最最重要的目标及相关的任务，目标日期，负责人等性息写到白板上挂到我们最近的墙。每天一抬头就可以看到，每次开会都会路过，时刻提醒我们最最重要的事情是什么。这种工具对我们组非常有效。

网站支持和内部通讯工具有哪些呢？

在所有通讯工具以上，是处理用户和Facebook之间通讯的工具。 针对常见的问题（尤其是关于如何使用某项功能的问题），Facebook在用户提交的时候，尝试将其引导到网站帮助或FAQ的网页。但这无法满足所有人，尤其是和个人特殊情况相关的问题，仍然有很大一批的用户会坚持提交问题，这时候Facebook内部的处理工具做得最重要的事情就是把相关问题自动分配到最相关的运营组（routing），比如和支付欺诈相关的问题应当自动分配到反欺诈运维组的那十几个人那边。然后工具会提供常见的通用解决方案，比如如果是选择退款，可以做到一键退款，绝大多数的回信内容自动产生（用户姓名，原问题等个体信息都会自动嵌入），运维人员可以选择要不要修改内容，然后选择发送。如果针对某一个功能的问题突然多起来，工具会自动发现，并提醒运维人员手动查看；运维人员可以根据实际情况决定要不要工程师介入寻找并修复可能的问题根源。所有用户问题的回复率，回复满意度，交互次数等等都会被统计或抽样统计，以保证客服服务的质量。

另外一个重要的工具就是招聘的工具。Facebook有一套专门的做题系统（Puzzle System）尝试去筛选可靠的工程师。这套系统是一个专门的Recruiting Engineering组做的，包括题库的管理和更新，自动提交系统和打分系统等等。如果在解题这个环节脱颖而出的话公司猎头（Recruiter）会给工程师打电话安排下一步的电话面试。另外一种活动电话面试的途径是通过内部推荐。所有的内部推荐都是通过专门的人才提交工具来上传简历，这个工具和整个招人系统结合，并注明这是一个内部推荐，谁是推荐人。而整个面试，包括谁应该参与面试，谁参与了面试，每一步面试官对应聘者的评价和打分，都在工具里被很好的记录和显示出来，当然还有必不可少的权限控制 – 只有参加面试的人员才能够看到关于应聘者整个流程的所有资料。最后，该工具允许打印所有的相关资料以帮助决策委员会讨论该应聘者时拥有所有相关数据。

还有一个重要工具就是每六个月一次的业绩评价工具。这个工具要允许员工自己对自己评价，员工互相评价，员工和老板之间互评，等等；还要考虑权限的管理。并不是一个很容易开发的工具。这个工具一开始是内部开发，但后来还是决定使用Rypple [2]来提供专业的业绩评价工具。

关于工具的一些思考

在Rypple的例子中要强调一点，Facebook是一个工具驱动的公司，但这并不表示所有的工具都要自己开发。工具开发是手段，而不是目的，Facebook的目的是打造一个最好的社交网站。因此，如果某个需要的工具有其他更专业的人做得更好的话，Facebook非常乐意付费买他们的服务，而把自己的精力集中在核心产品上。这就是为什么Facebook花大笔钱购买数据库软件MySQL的支持服务，购买Rypple的工具的原因。

还有很多其他的工具。Facebook希望通过工具的方式来解决所有可能想到的问题，比如要请假有相应的工具，你可以说明休息多长时间，你需要让哪些人知道这些情况等；所有新的想法的提出，讨论，让在线头脑风暴变成了可能；各种电子设备如电脑，手机等IT服务的请求和处理，也通过工具来解决……能够想到的地方就尽可能用工具。与物理工具不同，计算机工具可以实现“杠杆效应”的反复累积，通过组合这些“杠杆效应”可以达到更高的层级。

因此，公司的工作效率，影响到你需要雇用的员工数，公司的成本究竟是多少，并将直接影响到公司内部产品的独创性。黄易山就认为，工具团队不应该是一个由二线员工组成的“事后诸葛亮”的后勤部门，公司里最有才华的工程师应该用公司自己的工具来工作，并且企业文化里要优先反映这些。当公司过了最一开始开发原型证明概念的萌芽阶段之后，开发出优秀的工具并继续加以改善、更新，这比寻找下一个伟大的创意更重要。

我最近跟国内一些技术公司的高管们讨论过有关工具的话题，有些人非常赞同，也想通过工具来解决很多工程性的问题。比如，你要在公司里推广一些规范性方面的规则，一种传统的方法就是反反复复地强调，另一种就是开发出好用的工具，把这些东西固化在里面，借助工具进行强制性地推广，就解决了很多问题。像Facebook没有专门的软件质量测试人员，都是工程师自己进行，公司也有这方面的工具，把测试过程中重复性的工作集中起来，自动化实现，只有一些必须要个性化处理的由工程师具体再去做。再比如我在开发反欺诈系统时，将欺诈案例识别直接抛给人工处理当然是最简单的方式，但我们希望通过自动处理来解决大部分的欺诈案例，而把精力则放在那些确实需要单独处理的特殊案例上，最后决定的方向是“进行自动处理”和“建立反馈机制”，设计出用于用户报告(外部工具)和案例审查(内部工具)的工具。这样一来，我们也可以自动采集客户支持部门的处理意见，并集成到下一轮的机器学习中去，工具会越加精确和聪明且与时俱进。

在Facebook 2005～2006年的发展中，公司根据不断增长的用户数量，聘请了成比例的客户服务人员。当后来有1,000万用户时，公司的客户服务人员不到20个。到Facebook的用户数量达到1亿时，很明显，公司不能用相同的速度来增加员工数量，所以公司让内部方案团队与客户服务分析师的工作配合得更加紧密，建立了更具创新性的工具和用户界面，极大地提高了客户服务部门的工作效率。通过内部工具团队的产品，他们分析了目前已完成建立的工作并创建了定制方案来提高效率，方法是让电脑去做可自动化处理的部分并优化用户体验，这样客户服务分析师就可以专注于人工最擅长处理的事务。

不断发展、改进公司的内部工具，可以减少运营人员的雇用，让每个员工的效率更高，这样既改善了整体协调（员工数量少意味着协调更容易进行），又减少了整体开支。如今，Facebook的每一位工程师服务的用户数超过100万，虽然用户数量的持续增长，这种效率优势更加明显。

工具文化的最大挑战

不过有一个现实的最大挑战是，工具团队要招聘新员工有一定的难度。Facebook的用户已经达到数亿，而且还在不断增长，如果你开发的是直接面向用户的产品，每天有那么多人在使用，那带来的成就感非常棒。而你要说服新员工去开发内部工具，说这样可以带给工程师以及其他同事更高的效率、最终帮助公司做出更好的产品，相对是间接并缺乏吸引力的。 所以，工具团队在招聘上花了很多工夫，想各种办法找到合适的人。

一种方式是用一些具体的工具提高效率的案例和数据来做理性说服；这需要在开发工具的同时要检测工具使用前后的效率变化。当你有确确实实的数字来告诉最好的工程师，来吧，我们对公司的贡献不比做产品的那些人差，正是我们的工具让他们的效率提高了这么多，所以所有人的工作成果都有我们的一部分功劳。当然，为了吸引内部最好的人才愿意到工具团队，企业文化中也一定要着重反映出这一点：在不同的公开场合私下会面都不断的强调其重要性，让所有人都清楚，公司将内部工具视为持续的重要投资。另外一个可供参考的窍门就是集中精力努力说服几位整个工程部门认同的顶尖工程师加入工具组，具有很好的示范效果和磁铁效应。如果真正做到如此重视，最优秀的工程师是愿意加入工具团队的，可以大大提升同事们的效率，从而更好地服务于用户，这也是一种外部用户所感受不到的成就感。
原文出处：http://www.huxiu.com/article/8536/5.html;
关联记录：
   转记    评论
[ 摘记 ]    in《 创业笔记 》
《社交网络》“只有2%是真的”—穿的T恤和拖鞋

扎克伯格开玩笑说电影《社交网络》中只有2%是真的，而且那2%指的是电影里他经常穿的T恤和拖鞋。但他还是组织了全体员工去看，自己还参加了相关的电视娱乐节目。

2010年9月底，电影《社交网络》上映，在这部作品里，扎克伯格似乎成了一个不择手段捍卫利益的人。一天上午10点多，扎克伯格突然群发了邮件，邀请大家参加一个临时全体会议，希望所有人都放下手中的事情，尽可能参加。大家都聚集在一起，都猜不透他葫芦里卖的是什么药，有些人猜测可能要宣布IPO的消息。结果他告诉大家，公司已经包了大巴集体去看电影。对于这部电影，扎克伯格的评价是，98%的内容都是虚构的，只有2%是真的，那就是他穿的T恤和拖鞋。

电影上映几个月后，2011年1月，在美国NBC（美国全国广播公司）电视台的知名节目《周六夜现场》（Saturday Night Live）中，电影里扎克伯格的扮演者杰西艾森伯格（Jesse Eisenberg）开场介绍这部作品，然后由另一名演员安迪塞姆伯格（Andy Samberg）扮演扎克伯格，两人相互打趣，嘲笑扎克伯格的怪异性格。这时候，真正的扎克伯格突然上台，打断了两位假扎克伯格的对话，引得全场大笑。其实，安迪和扎克伯格私下里是好朋友，在2011年的F8大会上就由安迪假装扎克伯格进行搞笑式的开场。

由于早期跟温克莱沃斯兄弟（Cameron & Tyler Winklevoss）的官司，以及与创业伙伴之一萨维林（Eduardo Saverin）的纠纷，加之电影《社交网络》虚构情节的渲染，很长时间里，外界对扎克伯格的看法都是负面的。其实，哪些是真的，哪些是假的，外界根本不清楚，他们所看到的扎克伯格也不过是如好莱坞般的“想象”，至少他不是一个为了财富而不顾一切的人。就在电影上映的同一个月，扎克伯格在与诺瓦克市市长科里?布克（Cory Booker）、新泽西州州长克里斯?克里斯蒂（Chris Christie）做客知名访谈节目《奥普拉?温弗瑞脱口秀》时宣布，将捐赠1亿美元用以诺瓦克市公立学校教学的计划。2011年12月，扎克伯格又和数十位美国富豪及他们的家庭一道加入了由盖茨和巴菲特发起的“捐赠誓言”（Giving Pledge）活动，宣布将捐赠自己的大部分财产。
原文出处：http://www.huxiu.com/article/8536/6.html;
关联记录：
   转记    评论
zhuo [ 摘记 ]    2013-01-04 17:30      对所有人可见

in 个人笔记本 创业笔记      对所有人可见

要点： Facebook   企业文化   

Facebook文化中最有价值和最值得学习的是哪几点？读《打造Facebook：亲历Facebook爆发的5年》
是团队的力量打造了Facebook。而让团队凝聚在一起并充满战斗力的，即其文化。这种文化，包括一些做事的方式，为什么这么做的原因，和对这些做法和原因的认同


原文：http://www.huxiu.com/article/8536/1.html;
转记       转记    评论
扫二维码手机打开本页面




新一篇

zhuo      2013-01-04 17:31
推荐序 学习Facebook文化 文/李开复 创新工场CEO 认识王淮是在今年初的天使大会上，薛蛮子是这么介绍他的：“这个年轻人刚从Facebook回来，是斯坦福大学的高才生，Facebook的早期员工，最早的中国籍工程师之一。现在回中国想做点事情。” 王淮很腼腆地笑了笑。年轻人看起来蛮和气，不像其他的一些工程师那么nerdy（无趣乏味）。这几个
较早一篇

zhuo      2013-01-01 20:54
要点： 团队一致性   
【团队一致性】一位CEO发现下属描述公司并不一致时，他决定统一信息，设计了一张卡片，上有四个问题和答案，做了全公司的员工培训，确保每个人都理解并解释：1）我们公司是做什么的？2）我们的产品为客户解决什么问题？3）我们有什么成功的客户故事？4）我们和竞争对手差别在哪里？