问题目录

1. 你好，我想问一个关于公司的问题，360的规模也越来越大，在这种情况下，ops是怎么管理，弄个ops team还是每个team都有一个ops，出现报警，然后处理，是怎么样的一个流程，你能介绍一下吗？谢谢！
2. 我想问一下，刚才您提到Facebook是一个工具驱动的公司，有哪些适用的工具用在产品方面？谢谢！
3. 两个问题，一个是 chart你们使用web工具呢？还是用excel？另外在Facebook里面到底是怎么分工的，who is drawing a process？who make a final decision ？在Facebook是什么样的？
4. 我问一个比较常见的问题，就是在你的团队里面，技术人员对你的产品设计有强烈的疑问或者质疑，产品人员对技术人员实施细节的干预，在Facebook里面有没有处理的方法？
5. 你好，我问一个问题，最后的话所有的数据都会存到后台的数据库里面去，会有一些人去分析这个数据来做决策，这个地方能给我们分享一下吗？具体他们是怎么分工的？
6. 我问几个相关的问题，第一个是120%的界限，我想问的是，这120%在哪里，能不能告诉我你是怎么找到这120%的界限的？第二点，需要进行一些合理的员工激励，能不能告诉我们有哪些技巧，怎么样让员工高兴的完成你设定的120%的目标，谢谢！
7. 我这儿还有个问题，你招聘的话，你最看重工程师的哪些素质？
8. 我有两个问题想请教一下，第一个就是说咱们在做项目之前会有一个目标，但是在工作中我发现有些目标是不太容易被量化的。比如说我们做一个功能，这个功能是使产品本身的用户体验会更好，或者说让用户看起来我们的产品更专业，但是我们不一定真的让用户去使用它，像这样的情况下我们应该怎么样去设定目标呢？
9. 还有个问题就是说，这个项目他不一定在你的goal里面，这方面的项目怎么去管理，包括项目的计划？
10. 你好，我想问一个关于技术管理的问题，技术团队的组织在Facebook里面是一个大团队呢？还是有很多小团队，说一下吗？
11. Facebook是一个工具驱动的公司，这些工具都是工程师自己做的，还是有工具组？
12. 我问一个问题啊，产品发布之后出现问题了，你倾向于用哪种方式解决这种问题，增加一个流程呢，还是？
13. 我有产品发布的几个问题，第一个问题是我看你们发布的时候也有相关的量一个一个定义是吧？从1%开始到100%，我想问一下就是这个定义的标准是什么？什么样的产品是1%？什么样的产品是100%？第二个是如果顶级bug的修改，比如说产品出现了很多的问题，这样的产品发布的话大概是一个什么样的数字？第三个是服务端上线的时候，因为你说的是从1%到100%，有这么一个控制，服务端上线的时候，如何保证确实是一个比例来控制的，由谁来保证？
14. 我了解到Facebook是一个选人是非常严格的，我想问一下对于EM的选择，他会要求是比如说在你组里前三分之一水平比较高的才有机会吗？还是说前二分之一，有没有什么硬性的要求，如果有，其它的标准是什么？
15. 你好，我想问一下和开源相关的问题，在Facebook是怎么样选择开源项目的？怎么样使用开源项目的，谢谢！
16. 在Facebook中，在一个七八人的团队里面，一个产品是如何产生的？在众多的idea中哪些是产品可以实现的？还有一个就是，在对产品的打磨中如何控制这个度？第一个防止做的还不够，还要挖掘用户的需求，同时还要防止它过了，这种怎么处理？
17. 我不知道你是否在中国的互联网公司工作过，中国的互联网公司，包括百度、腾讯、360，很多的项目，产品都偏用户，所以在招聘的时候都是看你是否是从用户体验的角度，我通过看一些文章，觉得国外不是这样的，你认为哪种方式更为合理一点？
18. 再问一个开源的问题，Facebook有这么一个开源的项目，在项目中公司得到了什么，公司对开源项目有什么样的支持？
19. 现在Facebook有海量的用户，一般常用的用户反馈，我们对于用户的方法就是测试者。Facebook在挖掘用户的方法的话有没有自己独特的方法，有没有比较特别的？你刚才说的时间轴产品，我觉得不算是一个非常成功的产品，因为各方面数据不太好，或者是很少规划，这样的大数据你们有什么方法来优化？

1. 你好，我想问一个关于公司的问题，360的规模也越来越大，在这种情况下，ops是怎么管理，弄个ops team还是每个team都有一个ops，出现报警，然后处理，是怎么样的一个流程，你能介绍一下吗？谢谢！ 答：Facebook有专门的ops team，有好几个ops team，像跟整个site相关的稳定性，有一个是SRO team，24小时的，有大的问题出现，这个组会第一时间的反应，它做的事情是排除一些机器啊、基本相关的问题。还搞不定，他会把你叫醒，有一个page，列了跟项目相关的人，还有就是hold call page，每个组这个礼拜hold call哪些人。你有两个选择，你如果知道这个project 是谁负责的，你可以直接找他，或者你找不到这么人，或者没有这个origin，你就可以找这个组同hold call person，可以给他email，发msn，可以给他打电话，都没有问题。如果说一个P1 的话，可以等待的是6个小时或者12个小时。如果是P0，我们希望你们还打电话。有这样的一个分类，对各种问题进行分类，people process在里面。另外一点我想讲的很重要的一个工具，Facebook是一个工具驱动的公司，在这里面我们做的xxx工具，经理可以上去setup一片，然后就可以自动轮回了，更新了。警报也是一个工具，你可以记住这个数据，它可以自动发到系统上面，系统会集成，每几分钟它可以做一个计算，图形你可以自己去点点点，所以工程师那边做了一件事情就是，主要做的一件事情就是用这个EPI copy一下，所有的图形只要设置就好了，不用做其它任何东西。图形可以设置，报警也可以设置，不用写任何的代码。我们通过这种工具让检测的事情变得越简单越好。基本上是这两种思路吧，有inter process，还有报警工具
2. 我想问一下，刚才您提到Facebook是一个工具驱动的公司，有哪些适用的工具用在产品方面？谢谢！ 答：我有在这方面做过一个总结， 写代码的时候我们首先用的是gate，360是用SVN还是gate？没有统一的。我们是这样的，gate是我们推动的一个方向，但gate是可以在SVN的基础上build的，后台的数据库，代码库，但是在前台gate是可以直接连的，没有问题。Gate做代码的话比SVN要先进很多，所以写代码我们用gate，我们要谁review，我们必须要接受，这个才能发布的，否则就会出错，所以才能让review变得非常直观，大家可以去查一查，现在目前公开的工具当中，我比较了三个，功能是最好的，360可以去看一看，借鉴一下，我们是公开的，开源的，还有一个discussion tool，没有什么idea，在discussion tool上面把它写在那边，然后有两类可以看到，一类呢，是在tool这一栏中填入的email list等，这些都会被收到，另一个呢，可以接收跟某个话题相关的人，你可以text相关帖子上面，这些人如果愿意就可以在下面作评论，就可以看得到，就像微博上一条帖子贴出来，下面有人评论，一样的。有这样一套体系让大家做一些idea，在上面discussion，还有PTO，比如说一个月之后我要休息七天，有这么一个tool可以记录起来，相关的人可以得到通知，这样做为了工程师之间，我最怕的是，我今天找这个哥们商量个事，提早的我就给他schedule meeting，结果就发现他去休假，休一个礼拜才回来，最主要还是解决这样的一个问题的，我就做了一个tool。还有产品，我再想想啊，一下子想不起来，有好多在operation, monitor上，就像gate launch，gatekeeper，在代码中说，我的程序是跟这个project相连的。在gatekeeper工具里面只要对这个project进行confide，1%，5%，我们不用做代码的变化的，只要在这个按钮上面按一按，按一按。不同的人可以用这个程序就可以在实际当中反应了，这样子是一个tool。好多东西我们都是通过tool来反应的，具体呢，这是一个很好的话题，我可以想想写篇文章。
3. 两个问题，一个是 chart你们使用web工具呢？还是用excel？另外在Facebook里面到底是怎么分工的，who is drawing a process？who make a final decision ？在Facebook是什么样的？ 答：我经常用的就是excel，Google Analytics，我不知道，我跟我的pm两个人就在那里瞎搞。如果是跟某个特定的project相关的，项目，idea特别的多，特别难搞的时候，就用Google Analytics，如果是相对稳定一点的，就用刚才那个wiki，就按那个一条一条来，我们没有固定的方式，哪个更加work我们就用哪个，但是大致知道是在这里面选。EM,PM在Facebook，我的感觉EM抓的东西要更加strong一点，很多时候我跟PM是分工的，我老板经常说的一句话是说，EM只是一个广义的pm，很多时候根据我们的兴趣，根据我们的background,长处，来挑我们组做的一些project，比如说， 相关的我的PM就没有必要参加了，因为很多关于我们很多data ，哪些模型我们要去尝试，哪些参数我们要去调整，哪些工作我们要去做，通常我去跟另外两个组员，还有外部的一些客户，我们做一些讨论的。但是说产品性质的， ，你察觉了这是一张黑卡，你手头没有这张卡的，你可以问他卡后面的那三位数，对吧？这种情况下如何嵌到产品流程里面，我的pm这种事情是参与的更多一点，但是做这个final decision 在我们那边通常不是PM，要么是EM，要么是engineer，PM很多时候是在产品上面提供很多的思路，他推动很多方面，以及跟外面的联系，做这种coordinated 角色更加明显，（Facebook就是说工程师比较强势的公司，是吧）不仅是强势，我经常跟员工说，你要去own这种东西，你own，其他的，比如说pm，engineer以及其他组的成员都是你的支持，你可以take input，但是到最后你要own这个最后的结果，跟你的PM call on这是最重要的，因为他有不归我管，我们的关系都非常好。EM，如果pm跟你关系不好的话，很容易出问题的。关系非常好的前提下，讨论问题ok，但是这个项目没有做到我想要的程度，进展比较慢的话，还是找engineer，不会找pm的。
4. 我问一个比较常见的问题，就是在你的团队里面，技术人员对你的产品设计有强烈的疑问或者质疑，产品人员对技术人员实施细节的干预，在Facebook里面有没有处理的方法？ 答：我感觉没有什么独特地处理方法，大部分就是让他们debate，产品最好不要过多参与技术实现技术上面的东西，我们说还是希望发挥你的长处，而不是各个方面都要去参与，engineer要增加自己的建议呢，你就要增加自己的说服力，除了你自己觉得可行的话，你可以找你认可的一个技术牛人，跟你关系比较好的组里面的或者外组的，跟他可以讨论讨论，看看他的意见，他的意见可能使你说服组里面的人，或者说服产品里面的人可能是一个帮助，除非你觉得他做产品也在技术上面有他的一些独特地亮点的话，比如说以前做过技术，你很信任他，那就好了，你可以听听他的话，这可能是比较踏实的做法。还有一个就是实在不行了，比较猛的做法，把他们关到一个屋子里，你们如果不把这个问题解决的话，你们都不要出来，我跟们一起关，这也发生过，最后总会出现一个东西，其实没有那么多可以纠结，只要你找对人了，对于有些事情可能关在屋子里面出来一个方案是不行的。但是只要关屋子的人找对了，关了半天出来的结果肯定不会差的，这些都是最好的人，最聪明的人，对这个东西是有他的思路的人，之间有一些不同的看法，通常最后选哪个都ok的，不会有太大的问题，所以关一会最后总会有一个结果，这就好了。除非他不想吃东西，一直关下去。
5. 你好，我问一个问题，最后的话所有的数据都会存到后台的数据库里面去，会有一些人去分析这个数据来做决策，这个地方能给我们分享一下吗？具体他们是怎么分工的？ 答：我看看我脑袋里想的是不是你想要听到的一些东西，如果不是到时候你再说一下，Facebook所有的数据都会存档案不错，但不是所有的组做产品的时候都是专门的分析数据来给前台决策，大概有三四个组特别的heavy，一个是gross，我们有一个gross engineer team，gross data analyst team，他们就是分析在很多个国家，很多个人群，他们行为的状态。比如说这个年龄的用户使用率，photo，message，note,他的活跃率在上升，或者在下降。通过他们的趋势来考虑做一些产品，给产品增加或者减少一些功能，他们这个组是非常heavy的。我们组也是非常heavy的，我们要做一些模型，所以数据要求就非常高，但是想一个结构的对这个要求就不高。大致的流程就是你在前台code里做一些organ得东西，然后ETL一些process，最远的数据他们不是直接hive的，我不知道那个东西叫什么，最后到hive中。然后每个组需要一些数据，提炼一些数据，做成一些表，再存到hive中，我们做的一个就是，又是一个tool，就是用UI的方式，不用学会写SQL等 ，相关的一些column都在那面，他们就点点点点点，这张表你可以让他点点点点点，最后出来的结果可以直接发到的我信箱当中。这类事情要把它变成 person ，你可以把他自动化掉，大致就是这样的一个流程，像前面说的gross team，data analyst team，他们整天在这些数据上面下文章，帮助工程师做一些experiment，最后做一些实验的设计，一些数据方面的话，他们就比较懂一点，不是不懂，主要不是工程师使用他们时间最好的方式，工程师最好的方式我觉得是用在写有价值的程序上面，我们要一些懂数据的人做一些数据配合工程师做一些实验。大致是这样子吧，我觉得提炼最重要的一点，我觉得就是说把整个big data，每步都做到比较简单的使用，通过一些工具也好，通过一些 来写，中间可以省掉很多步骤也好，尽可能简化当中的每一步。
6. 我问几个相关的问题，第一个是120%的界限，我想问的是，这120%在哪里，能不能告诉我你是怎么找到这120%的界限的？第二点，需要进行一些合理的员工激励，能不能告诉我们有哪些技巧，怎么样让员工高兴的完成你设定的120%的目标，谢谢！ 答：首先120%不是我设定的，我回过头来看，我们大概每次push基本上到这种程度，具体的通常的做法我是这么做的，我们讨论大致的一些goal，要做的东西，比较detail，我问他大致什么时候能够做成，做的东西能够出来的，他的答案的技术上面，根据我对这个答案技术的了解，我给他push一下，他如果回答需要一个礼拜，两个礼拜的，我说能不能少一点，能不能80%的时间，70%的时间，因为这个里面我觉得这个里面的fiction，有三个思路，一个他提出来的时间，一个就是我想的时间，但是当中打一个折扣，我的感觉这样子差不多就到120%了，否则这个东西没有一个科学的衡量标准，大致是通过这个方面。这个我觉得对engineer有一定的要求就是说，你对这个产品怎么做，尤其是技术性的东西，做engineer是比较容易理解的，system怎么去实现，有一定的理解，没有一定的理解你对别人在这上面讨论的话就相对不靠谱一点。这个在这上面就打一些折扣。刚才我还想说的另外一个东西，刚才第二个问题，激励是吧，激励最大的特点就是让他set这个goal，让他先提，然后我们在那里讨论，最后那个goal定下来之后，必须要他同意，所以我说这120%的goal不是我set的，是我们商量的，是他能够实现的，这个goal后面的名字就是他的名字，one person后面的ping point。我觉得主要还是通过每个人都有这个意愿，去keep他的promise，用这种办法来激励他在这方面进行努力的。没有说，你做好了我们就会给你一些奖金啊，一些现金啊。这些东西从来没有。大家都没做好，你的股票不值钱了，你的公司不行了，这种东西考虑的太远了，所以我们不经常讨论这些东西。我们通常讨论我们这一次要做的goal，我们team要完成的那些goals，surround这些goal讨论很多的，那种自我激励吧。没有什么太多的 keys ，我觉得。
7. 我这儿还有个问题，你招聘的话，你最看重工程师的哪些素质？ 答：我觉得最后我要判断的是这个哥们会不会是get it down，能不能把事情完成，（但是你跟他接触时间很短），要么就是跟他待的时间很长。我们宁可错杀，也不要说感觉这哥们还行，过来试试看，多花点时间，再去做下一步的决定，我们还是相信工程师当时的判断，如果这个哥们没有impressed 到你，你在某些方面有所触动的话，最好不要用hire这种决定，我们出现过，所有人都hire，但是我们不要这种情况，每个人都觉得他刚刚好。对我而言的话，比如说我的面试，我们有好几种不同的面试我都做过，那种market面试，很多，一般是在technical 一般是在cultural ，的面试大部分是focus在desire方面，你如何去设计Facebook的news fade，你会怎么去设计。还有纯粹是coding，关于智力型问题，能问的很多，但我绝对不问，我觉得这东西一点意义都没有。在这些问题当中，我要问的一个问题就说我所认为的能够做事情的人，能够花够各种力气，能够不择手段，不能说不择手段，做很多工作把事情往前推，我所希望的人跟我面前的这个人是不是匹配，最后我觉得还是要形成这么一个感觉，比方说，我要你coding question，跟我交流当中，跟我讨论当中，我觉得总是在鸡同鸭讲，不能往前push，出来的结果的质量。从交流中你就能有所感触的，最差的，最好的你都容易判断，中间那一层的根据你的感觉，但是大致的，我觉得这个哥们能够跟我共事，哪些方面比我强，我一般就是找这个哥们哪些方面比我强的。比如说这个哥们coding比我强，coding面试的时候大部分就没什么问题了，即使他交流起来有一点困难，不要太差啊。太差的话，工程师交流很幸苦的，即使他很牛，很多时候非常非常难说服。这种情况的话我就会给一个hire，如果是招那种kata leader，我觉得对他们的沟通要求就高一点，最后就是要达到get shit down，跟这个人水平相关的事情，这个人能够把事情做完，能够达到我的心理预期，我觉得我就给个hire，我就相信去的那四五个人都是带着这种心态来的，来招一个在某些方面比他们高的人，我觉得我们就可以组成一个bet。
8. 我有两个问题想请教一下，第一个就是说咱们在做项目之前会有一个目标，但是在工作中我发现有些目标是不太容易被量化的。比如说我们做一个功能，这个功能是使产品本身的用户体验会更好，或者说让用户看起来我们的产品更专业，但是我们不一定真的让用户去使用它，像这样的情况下我们应该怎么样去设定目标呢？ 答：我的感觉是不要做了，另外我觉得吧，不能被衡量的东西某种程度上就是猜的，有可能你猜的是对的，的确有这样的帮助，但我总觉得做这个东西没底，因为没有把这个resource放在你能够衡量的东西上面，刚才我说的6-2-2,60%的是predicate的，那个大体上是可以衡量的比较清楚地工作，还有20%是controversial的risky的project ，但同时应该是也能够衡量的，短时间内可能作用不大，但是长远的对于有一些核心数据可能会有一些变化的，如果你的项目能够到这一层的话，我觉得可以做。如果完全不能够衡量的，那我觉得就是瞎猜了，不如把这些东西放在可以衡量的上面，我不相信这个公司没有更重要的可以衡量的项目，可能是跟工程师背景的有关吧，这种项目我个人是不大看好，不大理解的。
9. 还有个问题就是说，这个项目他不一定在你的goal里面，这方面的项目怎么去管理，包括项目的计划？ 答：项目为什么不在你的goal里面，你要去做啊？（比如说我要改一些bug），bug我觉得必须要的，我觉得bug应该放在里面。Facebook对bug的态度一直在变的，有句话叫move fast and break thinks ，后来把break thinks去掉了。希望尽可能的，回到刚才tool的问题，我们见很多tools，来让那个text变得更容易，我们没有QA，我们的QA都是engineer来写一些test cases，我们通过tools来监视这些text cases，这方面的东西我们觉得是，要么放在infer- structure ，要么放在predicate box，早期的时候可能更关注move fast，break think还是ok，所以对bugs还是不要太关心，除非是很严重的，整个set down，我就是set down过，没有把break set down过的工程师不是好工程师，到后来的话，在这上面花的时间可能就越来越多了，对 coaly 越来越关注，我觉得在这上面必须要花很多的时间，我们要预留一些时间，然后figure out一些 process，比如说P0的，我们希望最好马上得到解决，fix可以 push出去，P1的有一定的时限啊，根据情况啊来判断，让engineer自己去做一些选择，可以把P1 降到 P2，把P1升到P0，等等。有这样的一个process在里面。但后来对bugs是越来越重视，我觉得这种在你的plan中就可以写好，要确定这个月的 P0 的次数是小于一次啊。我们做过，这个东西呢，是比较难用goal来衡量的，有时 P0 出现的越多。你最保险的不出现P0的方式就是什么也不干，但我觉得这是不能接受的，所以你定一个这样的goal可能有负作用，但是有些办法可以想的，比如说，我们让bugs从整体上降低多少，等等。我觉得还是可以想一些办法出来的，我非常同意bugs，是非常重要的一部分。另外再说一个，不是所有的都增加figure的，有时候砍figure是一个非常重要的事情的，Facebook最不吝啬做的事情就是砍figure。我发现我在Facebook做的绝大部分都被砍了。昨天看到一个消息，Facebook 要被break down，做了三年的一个虚拟货币，要被 break down，所以Facebook很多东西都是做实验的，两年前做的news fade 的后台和前台跟今天的后天和前台完全不一样，除了他们都叫news fade之外，所有的code都没了，所以从某种意义上说，你原来做的某些工作都没了，但是Facebook绝不吝啬把一些figure turn down，在做下一个版本，做一些改头换面的东西，Facebook一直都是这种做法。
10. 你好，我想问一个关于技术管理的问题，技术团队的组织在Facebook里面是一个大团队呢？还是有很多小团队，说一下吗？ 答：Facebook绝大部分是小团队，大团队非常少，比如说我举一个我们团队的例子，我们团队总共是有20个人左右，我在其中负责7、8个人，另外一个同事负责六七个人，剩下的就归我老板直接带，因为他没有找到一个合适的manager做这些东西，管理学讲的最活跃的团队可能是7个或者8个人的样子，再多的话有效性会降低，到一定程度就要去break，你想这个人能够熟悉这七八个能够做什么，能够给一些实际的引导，如果到了像Google这种模式你就会非常非常讨厌的，二三十个人直接report一个manager，manager给他们帮助的程度就会大打折扣，我们反正不喜欢这种模式，大部分是那种小team，也有20几个人report一个人，但是下面肯定有tech leader，他take over很多技术上面大的问题，manager就是跟他们讨论技术性的问题，他参与特别感兴趣的当中小组的一些讨论。二十几个人支持一个人的话从技术上讲是不大可能的。
11. Facebook是一个工具驱动的公司，这些工具都是工程师自己做的，还是有工具组？ 答：我们有专门的工具组，有两个组，一个是devil tools，是给工程师写程序啊，还有一个是text tools，cord review tools，Discussion tools全公司都用，像这些tools都是一个叫devil tools的team做的。这个team的人很少，大概有四五个，五六个人吧。他做全公司所有的tools。Make tennis development，involvement。有些东西不大好用，有些东西很好用啊，一直在那里改，一直在那里变，都是他们组做的。另外我们叫support and tools team，他给全公司做tools，interview我们也有tools，custom support tools 所有的用户发过来的email，投诉啊，都是他们做的，那个组挺大的，那个组加起来大概有二十几个人，大概就是这样。
12. 我问一个问题啊，产品发布之后出现问题了，你倾向于用哪种方式解决这种问题，增加一个流程呢，还是？ 答：你刚才说的都有，我觉得我们做post 的时候，讨论这几个东西，what happened？ 究竟发生了什么？搞清楚究竟发生了什么，因为搞不清楚发生了什么的前提下，我们就讨论做什么的工作来防止在发生，我们就没有一个底，在那里扯淡呢。搞清楚了究竟发生了什么然后根据每一步，想想看那些东西是我们可以做的。在各部讨论的前提下，我们在进行一个ranking，哪些东西可以做的，并不代表你一定要去做，有时候cost可能更高的。头三个，头五个，你觉得成本不是特别的高，但是他带来的作用是最大的，可以是process，可以是新的tools，大家做事情的时候特别注意一下这些knowledge，各种具体的东西我们都有，但是通过讨论我们分析出来，这五项东西，这三项东西使我们要做的，其他的是我们可以做的，是v tool，action plan of tool ，一个礼拜，两个礼拜要set up 好的，做的一些东西，所以比较实事求是吧！
13. 我有产品发布的几个问题，第一个问题是我看你们发布的时候也有相关的量一个一个定义是吧？从1%开始到100%，我想问一下就是这个定义的标准是什么？什么样的产品是1%？什么样的产品是100%？第二个是如果顶级bug的修改，比如说产品出现了很多的问题，这样的产品发布的话大概是一个什么样的数字？第三个是服务端上线的时候，因为你说的是从1%到100%，有这么一个控制，服务端上线的时候，如何保证确实是一个比例来控制的，由谁来保证？ 答：第一个，从一到一百，有自己组说的算，大部分呢，你这个项目比较复杂的，你做的功能比较多的，而且这个东西是set的等都可以从1%甚至是0.1%开始，出错的成本太高的走的步骤就比较缓一点。如果是改一个bug，上去就100%，这种情况下，所以这个改bug从新的bug set down，最后我觉得我们就是把这个东西交给工程师来做自己的判断，大致的就是这个。你出现错误的成本决定了你步子迈的小一点呢，还是大一点，就是这些。第二个问题，紧急的bug的修改也是看bug的程度的，在修改bug的时候分好几步，好几个等级， critical的,Facebook出现一次的样子，比twitter好多了，全公司跟他相关的工程师都在这上面，找bug，找修改，最后马上修改。把手中所有的事情都放下，把bug修改掉，这个每季度大概一次，比如说我们的一个小的bug，文字出错了，打个比方，visa 结果s写成5了，这种非常低级的错误，那我们就可以百分百，等一天等两天，很难接受，除非写的及其不专业，那个时候就是不同的情况不同的判断，像低级错误我们当天就会修改掉，因为太不专业了，你想想看，支付的用户本身就占用户的1%，2%这种的，当中的1%或者2%碰到这种问题的，如果什么都不做，这种bug就会在下次的时候自动发出去，如果是需要马上发布的，或者是当天就修改，主要是为了一些bugs，你可以用tool，relate、request tool，把你的commit fix 申请一下，然后今天把它发出去，根据不同的情况，让工程师做出判断。第三个问题，ok，靠的是信念，对一群人的信念，我以前就说过，我去问我的老板，不是老板，是另外一个工程师，我怎么能够保证，我是1%的人看到的确是1%的人看到，他要我要有一点信念，有一点trust，有点信心啊，因为那批人把这个东西做出来了，1%，我相信他们做了一些testing，比如说我希望1%的看到，我就可以lot，只要看到这个人的UID，这段时间内所有的touch，这块code， 做的事情无非就是判断一下，这个UID是不是在我的要求范围之内，1%的用户，他会做一个判断，在这里面我可以做一个log，把这些涉及到这块的UID记下来，回头处一处就知道是不是1%，做这些功能的时候全部测试过，所以对他们多一点信心。如果这种情况下出问题了，Facebook只出过一次啊，这个工具运行了大概两年，三年的话，当中出过一次，是gatekeeper错了，没有达到你想要的目的，那没办法，如果每个人都怀疑的话，cost实在是太高了，就是相信他们，take他们的for granted。
14. 我了解到Facebook是一个选人是非常严格的，我想问一下对于EM的选择，他会要求是比如说在你组里前三分之一水平比较高的才有机会吗？还是说前二分之一，有没有什么硬性的要求，如果有，其它的标准是什么？ 答：没有什么硬性的要求，但是我觉得前三分之一，前四分之一这种比例差不多，前四分之一可能，通常做manager，都是you set engineer，manager必须要有好的textual foundation。我们在讨论技术细节的时候，框架的时候能够给一下我以前做这些东西的经验，帮你分析一下需要做哪一方面的工作，大致需要几天时间，我们进行有意义地讨论，而不是那种纯扯淡，我的经验的的确确是有意义的，我们希望manager能够做这样子的事情，对 要求还是比较高的，Facebook以前是 ，但是到 的时候没办法，提的速度太慢，培养是需要周期的，外面的确有很多很优秀的工程师，他们不是说愿意来Facebook做engineer，一步一步的重新开始，这帮人的确不错，他们过来的确是要给他们engineer manager的职位，他们可能也已经习惯了做这方面的事情，但是manager除了engineer需要的一些技能之外，除了一些积累吧，具体的coding对他们的比较少了，我是每周三把calendar设立起来，来写code，对manager写程序基本没要求。另外一个就是people skill，跟人打交道，能够激励别人，我觉得manager最重要的事情就是帮助他们超越自己，做一些有意义的事情，这种情况下，你如何了解发挥你的组员的长处，了解他们的兴趣点，了解他们感兴趣学习的东西，这些东西需要你跟他们都很强的交流，仅仅交流还不够，在交流当中对你形成一种信任，我觉得这种就是people skill，我们那边采取的一种方法就是deleted promotion，你做了一个对员工感兴趣的tackled，在manager职位上面没有title,你已经做了三个月的这种事情，而且结果是不错的，这种情况下再把它变成manager。不是说对你有信心，把你放到这个位置上面，然后再去看看你能不能做好，我们不做这些事情，我们是反过来的，所以说成本说高也高，说低也低，高就是你等的时间比较长，一般不会出现把一个不合适的人放到一个manager 位置上面，让他对这个团队造成伤害，另外一个，我们那边的manager要变回engineer非常的容易，如果你发现manager不适合你去做，因为你需要花很多时间跟人打交道上面，不是所有的engineer都愿意做这些事情的，你可以自由的转回去，而且非常欢迎，我这几天跟他们聊天发现一个非常有趣的事情，engineer工资比你高的比比皆是，很正常。在中国好像是比较少见的，在美国你要是把工程师的路走到底的话，没有问题。互相转换，只要你能够prove你这方面能做的，prove 你的people skill，你就可以做manager，如果你对这个不感兴趣的，而的确以前对engineer很感兴趣的，都没有问题。
15. 你好，我想问一下和开源相关的问题，在Facebook是怎么样选择开源项目的？怎么样使用开源项目的，谢谢！ 答：就谈几点吧，第一点是，能够做开源项目的我们就坚决自己弄，除非他是涉及核心竞争力的，打个比方，比如说news fade，外面有一套系统做数据的整理，做数据的ranking，这样的话，即使他做的再好我们也不会用，因为这是我们核心的东西，但是像数据存储，出于不同目的做存储的系统，我们就用这种开源的，我们尽可能的把自己的这种东西开源出来，给外界来用，所以是鼓励开源项目，如何去做挑选呢，大部分是做一些技术分析吧，有的时候是把想得到的看得到的开源的项目拿过来，我们自己做一个选项放在那边，然后有些就是说它的成本，效果啊，它是不是核心啊，进行一些分析吧，有时候不仅我们组参加这个讨论，比如说做hive，我们就把做hive的几个人找过来听听他们的意见，他们在这方面是专家，我们找专家在这方面给我们一些意见，决定在我们的，选择用在某个项目里面的决定，如果跟其他人相关的话，我们尽可能听取其他人的一些建议，最后做一下分析，做决定的人 make the final code。
16. 在Facebook中，在一个七八人的团队里面，一个产品是如何产生的？在众多的idea中哪些是产品可以实现的？还有一个就是，在对产品的打磨中如何控制这个度？第一个防止做的还不够，还要挖掘用户的需求，同时还要防止它过了，这种怎么处理？ 答：我觉得做什么产品的话有不同起来的方式，有的就像我们组做的相对比较简单，比如说我们的目标把用户的投诉率，返还率降到1%以下，这是我们的一个底线目标，我们会一起做很多产品上面的事情，根据当前的数据情况，根据当前的一些欺诈，做一些流程上的改变啊，数据上的一些获取啊，这种相对容易一些，有些是靠不住的，像timeline，要做photos，还要做news fade，从他那边影响出去的。还有就是每季度有一次全公司的人通宵狂欢，在那里做一些快乐的事情，像chat, email system 都是那个时候给email出来的，有一个demo meeting，三个小时，每个人上去花三分钟讲讲你做的东西，这上面又有些新东西，或者你对有些东西非常非常感兴趣，你可以组个团队，你要找的到，可以在业余时间出去做这样的一件事情。另外你只是想分享你的ideas，应该有这个功能，为什么他就不做呢？你可以找photo team manager跟他们谈一谈，可能出来很多的结果，你可以自己做这个picture，或者他被你说服，这样都特别possible的，像这种方式在Facebook也蛮多的，这大致就是产品，idea产生的方式吧，每个组都有几个goal吧。第二个问题，我们一般的项目的话不会超过三个月，如果这个项目，你要做的程度是超过三个月的话，那么就砍功能啊，砍质量啊，我们控制在最多不超过三个月，超过三个月之后在做产品的过程中变数太大，这大致是我们的一个极限吧，也有特殊情况，绝大多数，95%的项目都是在这个范围之内的，还有很多小项目两个礼拜，一个礼拜之类的，在这种情况下，我要把产品做成什么样子，在这个过程中知道哪些东西该做，哪些东西不该做。这些就对PM，对engineer的要求就比较高了，这些东西对你的 P1是最最重要的，在讨论的时候尽可能的把这些问题想清楚，越简单越好的把一些简单的东西做到极致，大致的项目在三个月之内都没什么问题，我们那边的项目都不大，engineer能够take的其实有很多很多事情，像news fade一开始就是一两个人做的，很长一段时间就是一两个人，在那里做这个东西，我们那边的组做项目的都很小，但是每次做出来的产品都有很多值得改进的地方，但我们绝对不是为了达到后面的那个目的而在那里等待，我不知道360的情况，产品都不一样，你宁可把它推到市场上面让你的用户来找你的问题，而不要说把它做得很好。
17. 我不知道你是否在中国的互联网公司工作过，中国的互联网公司，包括百度、腾讯、360，很多的项目，产品都偏用户，所以在招聘的时候都是看你是否是从用户体验的角度，我通过看一些文章，觉得国外不是这样的，你认为哪种方式更为合理一点？ 答：我没有在互联网公司工作过，但是有很多在你刚才说的公司里工作的朋友，跟我说过，我觉得还有一个很大的原因，我们队工程师的技能的要求可能不一样，对于纯coding的技术方面的infer traction对于这个就够了。但是对于产品的engineer我们要求它不仅仅是coding的能力，很多时候他对这个产品做成什么样子它有什么样的想法，一个产品经理等于0.4个PM加上engineer，这是我对产品经理的理解，就是说他有想法他要执行，他可能想的没那么细致，engineer他想的时候呢想的比较细致，他就把它做出来，没有考虑前前后后考虑太多的东西，人的需求很值得理解，对自己的需求，他是一个产品经理，他其实是engineer出身的，他以前的时候自己在那里做一些电子类的产品，他就是做自己想到的一些东西，他对这个产品有很强的一个把握的，在中国比较乱，就是他没办法把它交给像产品经理那样的人，如果有这样的人的话，他也会找产品经理去抓这个事情的，如果你懂这个需求，懂这个产品，你take it from pm他的说服力，他的productivity。中国的pm对技术的关注有点低，让这些人磨得话，你要花很多时间去打破，我说的那种engineer本来就是一个没有那种膜，我觉得这是现实的原因，没办法的。我是推崇的项目投资的话，CEO很多就是这种角色，technical出身的CEO他是一个很强的产品经理，他有一个很强的产品的想法，同时呢，同时有知道很多细节的工程师，来领导一定的方向，所以没有造成中国的这种现状。所以有些产品经理，有些朋友可以提高一下，他有这个能力，但是现状造成他没有这个机会，看看哪些场合有这么一个机会去秀一把。
18. 再问一个开源的问题，Facebook有这么一个开源的项目，在项目中公司得到了什么，公司对开源项目有什么样的支持？
19. 现在Facebook有海量的用户，一般常用的用户反馈，我们对于用户的方法就是测试者。Facebook在挖掘用户的方法的话有没有自己独特的方法，有没有比较特别的？你刚才说的时间轴产品，我觉得不算是一个非常成功的产品，因为各方面数据不太好，或者是很少规划，这样的大数据你们有什么方法来优化？ 答：得到了什么呢？美国的公司比较理想化，回馈这个社区，所以整个社区才能够往前啊，如果大家只知道获取不知道回馈的话，这个事情没办法长期的，我觉得老外在这上面想得比较透一点吧，远一点。第二点，你通过这一点你可以招到很好的人，你秀你们公司的technical ability，有很多工程师是非常好的，他对金钱的追求远小于technical excellent的追求，你能够说服他的话对你公司的发展有很好的帮助，蛮理想的工程师，所以做开源对吸引这些人是有帮助的，搞一个开源大会，有机会跟他们交流一下，顺便谈一谈有没有兴趣加入Facebook。我觉得主要就这两点吧，它的好处。有支持，比如说刚才说的那个开源大会啊，Facebook 有些项目很出名的，比如说hip hop，就是PHP 重写成C++，这个项目做了很久，做好了能用了，整个团队做了很久把它做成开源，这部分的时间如果做其他的话，Facebook可能又有其他的功能。他就是一个机会成本的问题，但是Facebook愿意放到开源上面，支持工程师做这些事情。我觉得这就是公司对这些人的支持。还有我们有一个开源的工程组，专门做开源的事情。
20. 现在Facebook有海量的用户，一般常用的用户反馈，我们对于用户的方法就是测试者。Facebook在挖掘用户的方法的话有没有自己独特的方法，有没有比较特别的？你刚才说的时间轴产品，我觉得不算是一个非常成功的产品，因为各方面数据不太好，或者是很少规划，这样的大数据你们有什么方法来优化？ 答：其实Facebook的作法，你如果用心去谈的话，没有什么，比如说你关机的那些key magic，在你代码当中做记录，把这些东西通过图形记录下来，比如说我们组关注的那些核心数据的话，我们就把它放在显示器里，有人一直更新这些数据，不用说想不到他，把它专门放到一个显示器里，通过数据的方式看看用户多给你一个链接啊还是没有，这样的事情，大规模用户的时候只能这样做，但是新产品的时候要特别的关注一些习惯，我们也有一个用户实验室之类的东西，邀请别人过来在一个小房间里面用，我们做两个事情，一个是，看看他的able，另外一个我们在另一个房间通过摄像头观察他的使用习惯，是不是我们所希望有的。这样项目的意义有多少呢？还得看pm，engineer这些人去解读了，大致的就这些吧，还有一些是praise的，媒体对这些东西的分析判断，Facebook看看有没有用，看看他们投诉的诉求是不是我们忽略了等等，还有就是跟外面的CEO 比较熟啊，经常问问他们的一些意见，产生他对公司产品的一种再解读，Facebook这样的事情也都做，等等等等。没有什么特别的技巧，我的感觉。第二个问题timeline是在我之后才发布的，在我走之前他就一直在做，做了很久了。我觉得Facebook肯定在检查一些数据，再考虑在改进，这些是百分百在做的，什么时候做什么样的事情的话，timeline 做了有一年了，这个作为他的top project之一，每周做review,做什么样的改进，我觉得他会说的算吧。另外一个呢，我觉得把它放在长远的计划的话，比较难有几次失败就把它砍掉。像Facebook reliance ，两大中心之一，做了三年最后决定终于砍掉了，中间做了好多好多的事情，做了很多的尝试之后，到了一定程度之后，我们回到最开始的问题上，我们要不要做，值不值的做，基本上就是扔白旗了，这些就是跟公司的大方向非常相关得东西，白旗的时间就很长。如果是小的功能的话可能做了一个月两个月三个月没有达到我们想要的预期的话，我们可能就考虑砍了，根据在公司的战略里面出于什么样的目的，具体做什么样的改变的话，都会参与提供的。