目录 开场介绍：

1. 好的人才最好通过自己的人脉来挖掘 1
2. 研发经理最重要的是尽量将团队工作自动化 1 Facebook开发产品的一些基本思路和方法

1. picture the vision &set goals 1  做事前，先考虑清楚究竟想做出一个什么东西、要解决什么问题、需求是什么？ 1  定好目标再去做计划 1  goals set 的五个讨论的点 2  goals setting要aggressive一点，但又要realistic 2  set goal的时候要focus 2  根据你所有的资源选择120%能力范围内能够做的事情 2
2. 产品的idea是从哪儿来的？ 3  EM、PM、engineers都可以提供 3
3. Brainstorming 3  根据每个goals，先列出和每人相关的Idea，并组织讨论 3  讨论时不要将过多时间用在判断想法好坏上，要抑制直接做判断的冲动 3  最终讨论结果要保证实施计划部分留出： 3  20%时间花在infrastructure、quality，保证我们的系统能够稳定运作 4  20%的时间花在risk、controversial project上面，这样你的公司明天很可能变成跟今天很不一样 4  60%的时间是用在predictable work，我确定今天要做什么事 4  Facebook有一个特点：超过三个月的东西没有去想太多，超过六个月的东西基本不大想（至少在IPO之前是这样） 4  需要做什么不做什么都围绕着impact，最终要服务于公司的那个top six或者top five goals 4
4. 尽量使用工具来帮助你完成工作 6  每一项启动之后都会变成Bugzilla上面的一个task 6  做engineer在Facebook很大的一个思路是尽可能的用tool去自动化很多步骤 6
5. finalized一个plan 6  相关的所有人至少有这个机会知道这些plan，然后给这个机会可以听听他们的声音、想法 6  final review：有一个较完整的plan后邀请相关的audience，成员包括组内的engineer、OPS和相关工程组 7
6. design product 8  一个挺重要的事情就是你要邀请你希望跟这个product相关的、有能力提供建议的人来提建议 8  坚决避免做完美的产品 8  产品越简单越好，但是不要简陋 8
7. Get the help as much as you can 10  可以大致独立，但尽可能在某些自己欠缺的地方找到最好的支持 10
8. Be owned customer 10  你要知道自己手头工作的产品应该有什么功能 10  只有自己想做用户的人才会有passion 10
9. Do not cheat profession 11  一个项目、一个产品由一个人来承担最大限度的责任，他可以有一个合作人。但是当谈到项目成与败的时候，我们要有问题去了解这个项目的时候我们就问这一人。但最多的奖励也是到他那边去的 11
10. Cicelies and standard report 12
11. 关于产品发布 12  do it slowly and steadily，gate launch 12

开场介绍：

1. 好的人才最好通过自己的人脉来挖掘
2. 研发经理最重要的是尽量将团队工作自动化 本次讲座主要讲Facebook产品开发的一些流程、一些思路，对产品和技术的朋友会更加相关。 先简单的做1个自我介绍。我一直说我在Facebook最重要的事情就是给它招了很多非常顶尖的工程师。像最早期的中国人、印度人，都是各种途径我拉过来、挖过来或者招过来的，在一段时间内我是公司referrer最多的。我非常想强调的是，最好的员工都是通过自身积累的，至少我认识的朋友都很牛，最好的那批人的话，你有办法收拢他们，看是否对你公司感兴趣，拉过来，对你公司的发展是一条最有效的一条路，比起在网站上面发招聘广告会有意思很多。朋友跟朋友在一起都是牛人的话，一起做事情更有默契。我觉得技术经理做的最主要的就是多使用工具，尽量团队的工作自动化掉。我的团队从一开始的一个人到最终的九个人，最后越做越少，因为我们把很多的东西都自动化掉了，所以要维护在开发这个系统需要人员比较少，我觉得这也是比较重要的一条思路。 Facebook开发产品的一些基本思路和方法

1. picture the vision &set goals  做事前，先考虑清楚究竟想做出一个什么东西、要解决什么问题、需求是什么？  定好目标再去做计划  goals set 的五个讨论的点  goals setting要aggressive一点，但又要realistic  set goal的时候要focus  根据你所有的资源选择120%能力范围内能够做的事情 picture the vision &set goals，我们做一个产品之前的话，通常脑子里面会有一张图，你究竟想出一个什么样子的东西？你要解决的问题是什么？需求是什么？而不是马上开始这样子那样子的功能，这些东西最后是为了什么样的目的，我们得有一个big picture在脑子里面。Vision就是我们要做什么，解决什么样的问题，我们为什么要做它。我不知道大家有没有读过一本书叫高效人士七大习惯，当中有一点就是这个。 其实做东西的时候可以想想看，你的目标是什么，从这一点上去看要做什么，然后才去做plan，我们做什么才能达到最终的那个点，然后这边举了两个goals，这都是我们组的一些goals，reduce dispute rate by 30% by Q2。 我想通过这个例子，来说明做goals set 的五个讨论的点，这是非常典型的， 叫做SMART，他希望你在做goals setting 的时候定的非常清楚，没有找一个路人甲，路人乙，看一个这样子的一个goal，结果两个人解读不一样。第二个是measurable，是可以度量的，只要这个弄好了，我们就可以度量它。 Aggressive 这个东西不是阿猫阿狗就可以做的，不是你花了80%就可以做成的。我刚才讲到像我做goals setting的时候，要做到需要整个团队120%的精力去做，就是aggressive一点，但又要realistic一点，不要太夸张，你说你建一个搜索公司，想在一年之内打败百度，非常的aggressive，但是no realistic，不可能会成功的。所以这两点又像是相互矛盾的，看你如何去调整。 time-bound必须有一个实现，就像这样的一个Q2。这样子的话，goal才有意义，我们经常set goal的时候要focus，我们具体要做什么要围绕着goal，就是所谓的focus。有了这些vision，我们要做的具体要达到一个目的之后，你需要什么样的想法，有了什么样的想法之后，最后才做prediction。你要考虑你的这些想法对你要达到的这些目标分别起到什么样的作用，然后进行排序，最后根据你所有的资源选择120%能力范围内能够做的事情。
2. 产品的idea是从哪儿来的？  EM、PM、engineers都可以提供 idea大部分是从这几个方向来的？EM、PM、engineers都可以提供。在这个时候提供他们的想法，尤其在infrastructure project上面，因为做事情的时候我们想做出一个什么样的东西？要做成这样子那样子？这些很多的功能性、产品性之类的东西有时候会忽略掉，这样基础架构要跟得上，所以经常强调说大家有意识的在这上面多花点时间我们接下来三个月我们在架构上的一些事情，保证在接下来做产品的时候不会超越太多。 你的产品出去之后，消耗的资源的CPU、内存、硬盘相应的要求会包起来。如果你的基础架构没有跟上的话，这些东西都无法持续。还有一个是business folks，像我们做payments的话，跟engineer打交道非常多的，他们看用户支付的诉求、抱怨的东西，可以从中看出支付的流程一些问题，安全上的一些问题。他们很多在一线的反馈我们也收集起来。通过email的方式、当面聊天的方式和我们的一些核心数据报表上面，从中反馈出一些我们想要的东西。
3. Brainstorming  根据每个goals，先列出和每人相关的Idea，并组织讨论  讨论时不要将过多时间用在判断想法好坏上，要抑制直接做判断的冲动  最终讨论结果要保证实施计划部分留出  20%时间花在infrastructure、quality，保证我们的系统能够稳定运作  20%的时间花在risk、controversial project上面，这样你的公司明天很可能变成跟今天很不一样  60%的时间是用在predictable work，我确定今天要做什么事  Facebook有一个特点：超过三个月的东西没有去想太多，超过六个月的东西基本不大想（至少在IPO之前是这样）  需要做什么不做什么都围绕着impact，最终要服务于公司的那个top six或者top five goals 因为一个团队，我们会同时做好几个project，对应不同的goals，每个goals下面，有跟他相关的idea x.1 idea x.2。首先我们会现将这些都列出来进行讨论，讨论的时候不要将过多的时间放在判断想法好坏上面，这时候我们大多是提：你觉得相关的提在那边，但是不要去急着做判断，尽可能的抑制住这种做判断的冲动。然后才是选择方案，这时候大家可以思考一个goals，我们经常想的一个问题就是什么东西是“top X”，不同的team，不同的公司，自己来定。像我们组有3-5个goals，像Facebook每半年6个goals，把自己的performance给link上，这就成了我们最大的关注，“top x”—important ideas fist。 从现实来分析，80%的效果都是从20%的工作中来的，你如何去找到那20%的工作，至少有意识的思考分析，比你什么都不做，从事后来看总能够看出80%是从哪些20%的工作来的，你的效率会提高很多。提早想一想，不一定能够猜对，但是至少提高一点猜对的概率。做一下这方面的练习，rank and pick 刚才说到了，就是把idea能够选出来，然后在做下注。这起码是我们这个大组的一个分布,每个公司可能不一样，就是说百分之多少的时间分别花在什么样的事情上面，我们20%的时间是花在infrastructure、quality，保证我们的系统能够稳定运作的。20%的时间花在risk、controversial project上面，这样可以保证你的公司明天很可能变成跟今天很不一样的一家公司，这些project通常是很难判断的，可能从现在看是可有可无的，但是如果不这样做一个思考的话，我们永远只做跟今天相关的东西， 明天后天都是很难预料的，我们希望有一些比较有意思，比较激动的项目。还有60%的时间是用在predictable work，我确定今天要做什么事，我不做明天会死的，类似于此的project。我们组基本就控制在这个范围之内。 每家公司都有适合自己的allocation，首先强调的是，这两块的东西有时候在时间上，并不是每个员工每个engineer都要花时间思考，但是engineer manager 要特别看一看你分别花在这上面的时间有多少，看看是不是适合的，做一下这方面的判断。 像我们那边每天计划是一个指导性的，我么不用严格按照每天计划选出东西，每天计划相对自由一些、松散一些。但我们的每个月的计划我们都是严格执行的，因为时间短，如果一个月的执行都在那里前后摇摆，更改很快的话很容易让一个组处于非常不确定性的状态中。engineer其实很讨厌每周都在那里改的，希望至少在一个月之内是相对稳定的。但是Facebook有一个特点，每个月我们做的东西都非常不一样的，所以超过三个月的东西我们没有去想太多，超过六个月的东西基本不大想，至少是在IPO之前，之后就不知道了。需要做什么不做什么都围绕着impact，对公司的影响。对公司的影响是不同理解的，跟我们组关心的指标相关的，并不是说A组跟B组影响都一样，可以完全不同。但是最终要服务于公司的那个top six或者top five goals。不知道360目前是什么状况，但是最好你们组制定的目标最好能够跟公司的目标能够link上，这样impact才能够比较好的显现。 互相讨论的时候对方说，我们不喜欢做这个东西，尤其是我们定下来的时候要做这三到四个ideas或者project。通常我觉得一个问题是，如果做你想的那个idea的话，我们现在讨论的最重要的这三个东西，哪个应该被推出去，这个是促使对方能够用积极的思考下去的问题，他的思考可以减少使我们陷入无谓的争论，这个责任变成对方那边了，他先思考了，带着他的答案我们再来讨论这个问题。 刚才提到了120%的rules，这个目标就是为了aggressive but Still reasonable，make sure 技术结构的事情在里面。
4. 尽量使用工具来帮助你完成工作  每一项启动之后都会变成Bugzilla上面的一个task  做engineer在Facebook很大的一个思路是尽可能的用tool去自动化很多步骤 很多都是这样子的，project x 对应着 Goal X，然后下面有这样的task。每个上面都有一个当前的状态，然后就非常清楚。做了很多project update、weekly的时候就是经常绕着这个东西来做。这边提一点就是说我们这些修改大部分都是手动的，手动的话，project management cost 就变得比较高了。我们通常每一项启动之后都会变成一个Bugzilla上面的一个task。我们把bugzilla改了一下，把它变成我们内部的一个task management，只要上面Bugzilla这样一个task，这个state是自动跟着task的state变化的。 在这里我顺便提一下做engineer在Facebook的一个很大的一个思路是尽可能的用tool去自动化很多步骤，到会你会看到很多地方，只要你看到不需要人工去参与的话，尽可能的用工具。所以很长一段时间之内，不能保证说现在是这样，最可能的把最好的人放到制作工具上面去。因为这个工具做出来，可以减少所有人的开发、运作成本。这种工具适用于工程师，也适用于非工程师。最最重要的是我们用一个比较土的办法，把它放到墙上面，每次走过的时候，就可以看得到。所以我觉得其实也是瞎玩吧，把它变成一个value得东西，每天走过的时候都能看得到，这些事看起来会重要一点，没有其它太多的原因。
5. finalized一个plan  相关的所有人至少有这个机会知道这些plan，然后给这个机会可以听听他们的声音、想法  final review：有一个较完整的plan后邀请相关的audience，成员包括组内的engineer、OPS和相关工程组 ok，有了这个plan之后，因为都是协同作战的，并不是说你们一个组做什么事情都自己说的算，我们希望不同组之间有相同合作的，他们的齿轮是能够对的上的，所以这边有一个协作方面的需求，相关的之间能够对的上，需要不同方面的人员，engineer、PM、design等跟你做的东西相关的，engineer之间也需要这种协作。Facebook有另外一个组和我们组用的体系架构非常像。一开始我们各做各的。但是后来我们把它整合了，我们用了他们的基础架构在上面开发跟我们相关的一些调整啊，一些mold machine mold的事情。所以我们做一些事情的时候需要他们架构上面进行配合，他们必须在下个月的计划中有这个计划，不然我们只做了这个，他们不做，就变成这个事情没办法做。 这个plan是协同下边，其实我们大家都准备在这个上面下注，没有人保证能够成功。就是这一点我们也用的很明确，我们不能说做这件事情一定能成功，但是这是我们想出来的最好的计划。能够接受的做planning的时候，相关的所有人至少有这个机会知道这些plan，然后给这个机会可以听听他们的声音、想法。你可以选择不把别人的想法放到你的产品、计划当中，但是你至少考虑过别人的东西，给别人一个答案。最后是在协同出来的计划上面，所有人都参与了，不要带有情绪，我在那里强推我们组的东西，然后强迫对方一定要花时间在这上面配合我们的，而不是因为它同意我们为什么这么做，在根本上面buying to our ideas，这种合作是非常不高效的，是带有情绪化的。 我们最不想看到的就是surprise。当我们做这些东西的时候，跑到对方那面去，能不能给我做个这个东西，我们明天后天大后天就要，完全就是打乱对方的一些想法。在最开始的时候我们通常是这个做的，但随着项目越来越大，并不是你们组做什么事情说了算，大家就是完全独立的来做事情，我们希望不同组之间有相同合作的，他们之间的齿轮能够对的上。所以这里有一个allurement 的需求但你项目越来越大的时候，越来越多的时候，这种做法就是绝大多数下我们想要去避免。 有了这个plan之后，虽然我们小组小组之间都弄好了，我们关心payments ,在Facebook做payments 的等加起来大概会有一两百人在当时。我们做lineament 肯定没有那么多了，但是在这方面我们希望他们可以交流的，这个过程非常重要。我们交流呢主要是做这两件事情。一个就是final review, 我们有一个比较完整的plan ,然后邀请相关的一个audience,数目比较好控制的，我们组的engineer 会来，OPS 那边一两个人回来，相关的工程组的一两个人会来，整个是控制在7、8个人以下，我们做一个30分钟的review。大家比较清楚我们准备要做什么。然后就是send the email with the cram 基本上他表达的意思是说这是我们在下一个月要做的，如果你们有什么问题的话，这是给你们提出来的一个机会。这就是我经常发的一个master email, 这有一个link，告诉人家最一开始我给大家展示的，project adds, tasks,这样子一个页面。这个页面是说我们完成的一个goals 。 有了这个计划之后，我们才开始去做这个design product。顺便提一句，我们这个不是线性的，遇到这种事情的时候，它同时在做3个项目，目前他手头正在做的事情，而不是停下来，每天都是在做这种事情，搞这种planning,我们现在讲尽可能减少planning 带来的这种cost。engineer最喜欢的就是，在实际的问题，有一个code，他可以在那里写，这样他们很开心，所以我们想尽量减少这方面的成本。
6. design product  一个挺重要的事情就是你要邀请你希望跟这个product相关的、有能力提供建议的人来提建议  坚决避免做完美的产品  产品越简单越好，但是不要简陋 还是希望有些思考再去做一些东西，所以一开始可能不是这样子的。我们有一个想法就是经常一个原型直接抛过去，搞了一夜出来在这个基础上面自己改啊改，然后就推出去了。后来是把designer 稍微大一点，designer devote，designer可以给一些 work up .然后在我们那个product meaning 的时候，相关的人discuss，觉得这个地方需要改一改，然后再回去。其实product tap engineer来做和designer来做也有类似的。我们做了一个非常简单的product tap 也没有什么 basis lawing 处理，就感觉这product做成这样子的，我们就讨论一些小的事情。第二天他改完了我们再接着讨论，每天花上半个小时的时间来做这样的事情，有时候更快，我们坐在那里，坐一下午，我们就现场改现场去思考，现场去提问。做这个product design 有一个挺重要的事情就是你希望跟这个product相关的有能力提供建议的人过来，而不是什么人都叫过来。在有些公司呢，他有一个技术委员会，Facebook没有。很多技术性的决定都是local做的，这个组做的但是我又不希望我们这个小组如果在某些方面欠缺的话导致这个出来的质量不好。所以我们把我们认为好的人邀请过来，在我们做product design 的时候能够听听他们的声音，能够有他们的力量在里面发挥。 很多时候做product design 的时候，那么就是在这四个方面有很多的取舍，feature set，要做什么样的功能；time to market, 什么时候launch; budget,这要花多少钱；quality，我们要做到什么程度的质量可以支持同时100万人上线，1000万人上线。基本上都是在这四个方面做取舍的。打个比方，你做的，你不能按时完成了，无非就是要么砍功能，要么延长时间，要么多放点人，那么把你的质量下拉到100万人，比现在1000万要做到更快点。一个最重要的是知道自己的V1，就是接下去要发布的，你的V 2，V3这样你要达到目的的一个趋势，不要一开始focus 在 fashion上面。我们Facebook就是这样，我们最终要做到一个perfect product ,所谓理想的产品.但是做每一个版本的时候，我们坚决避免做完美的产品，这个只会让我们没完没了。我们对自己的V1定义的非常清楚。这里面做事情就是互相妥协吧。 在做产品设计的时候一些理念，do not over design,在你的V1，当你每次在prove concept 的时候，你没有必要做到同时支持100万用户在线.就像360，你如果一个产品出来通过push 到所有的desktop 上面，你可能必须要做到同时支持千万人，一亿人上线，那这就变成了一个定性需求了.知道自己一个design scope 是什么，不要超越它。 越简单越好，但是不要简陋，可能不同的product上面对这个简单简陋要求不一样。简单就是说你的步骤越少越好，feature 越少越好，需要让用户思考的点越少越好。但不是少到你要解决的问题解决不了，就是简单是简单，但是最后我想要的东西没有，搞了半天，这个产品基本上就是不work，那这种就是简陋了。
7. Get the help as much as you can  可以大致独立，但尽可能在某些自己欠缺的地方找到最好的支持 我们不希望说这个东西交给你了，这里面所有东西都由你一个人来做。我希望你能够在大致独立，但尽可能在某些自己欠缺的地方找到最好的支持。现在做infer-traction ，尤其是很多大型的项目经验非常重要。对一个经验不够但是极度聪明的人来做，我们是希望它能够有一个做infers traction 有个check success story 的人过来帮他，在一些想法方面给他进行一些完善。在做这个design review 的时候至少在那里能够参与的，以防我们做出低质量的东西。
8. Be owned customer  你要知道自己手头工作的产品应该有什么功能  只有自己想做用户的人才会有passion 我们非常关注这点，你做这个东西，你要去使用它，在Facebook这点是问题不大的，在 Facebook的每个员工大多都是。在雅虎的时候就发现大多数工程师查东西的时候用的是Google，这就是一个big problem，如果不是用户的话，你怎么去做？有两点，第一个，你不知道自己手头在工作的产品应该有什么功能，第二个，只有自己想做用户的人才会有passion,把自己的事情做好。 这点刚刚提到了，这是Steve Jobs 非常推崇的一点，It should just work.不要让我想太多的问题。其实把这个东西变得更加容易实践一点的话，其实就是想想你的主要目标是什么，你要解决的最主要的那三大功能是什么.其实对360这样有现有有产品的还是有比较容易去监测的。因为你看一下记录的话，你会看到60%70%的产品他就是这么一个产品，这么几个流程过来，监控你的每一个按钮，可以make out 出来这个是什么。
9. Do not cheat profession  一个项目、一个产品由一个人来承担最大限度的责任，他可以有一个合作人。但是当谈到项目成与败的时候，我们要有问题去了解这个项目的时候我们就问这一人。但最多的奖励也是到他那边去的 在每一步都不要cheat，最终的目的是让产品达到最好，我觉得谈perfect的时候永远加个引号，因为这世界上不存在perfect的东西。我们希望一个项目，一个产品可以由一个人来承担最大限度的责任，他可以有一个合作人。但是当谈到项目成与败的时候，我们要有问题去了解这个项目的时候我们就问这一人。但最多的奖励也是到他那边去的。这个事情成与败，一个责任很清楚，你需要去push.需要去mental，需要去help，那个点就非常清楚。这个不是说，我跟他一起做事情，他不努力，我到时候有一个借口把这个责任推到他那边去，但如果只有1个责任人的话就没有办法做这样的事。大家可以看到，Alice加另外一个人，这时候前面那个人永远是最主要的，起主导性的一个人。每天或者每周通过你的project的情况再跟这个项目，可以是每天可以是每周，可以是10分钟，可以是30分钟，根据不同的project 可以找到比较合适的搭配。这个东西不要太纠结，你如果每天10分钟，发现大家没话可讲，那就改成每两天，每三天，你会发现10分钟还太少，你就改成半小时。不过每天半小时，我觉得永远都是太多了，大家可以根据自己的project看看哪种方式适合自己。所有重要的人都要在场，很多都是站着的，谈谈刚才那些tasks，昨天我们做了什么，今天我们做了什么，根据人，让每个人来讲，我说着三个task有一个怎么样的进展，会有什么样子的问题，我需要什么帮助等等，反正大家有一个了解。 不要给一些傻里傻气的借口就根本不回我的信，一天可以，两天我觉得马马虎虎，三天大家就知道这里肯定有什么问题了。对方不回你的信，你为什么不去催他，不跑到他面前求他，打他，做出你能够做出来的事情把他的项目往前推，不要说把这个借口拿过来为不能把这个项目往前推找理由，这就是我认为的silly excuses。
10. Cicelies and standard report 我以前的practice 是每周末尽可能的是把我们这周各个项目的总结写一个，每个项目我只写一句话。然后让对我们组感兴趣的人，我老板、我老板的老板还有跟我们合作的那几个负责人能够了解一下我们做的东西到什么程度。有点无聊，写这些东西的时候，开这个weakling meeting 的时候，但是我们不做的话，就很难让整个组动起来。这是我写一个stasis的样板，基本上就是keep it update,这个就是有点sensitive就把它给马赛克了。这个就是做的design，就写了两句话。我们做了什么就focus在这些action上面，我们做了什么，没做什么，还差什么。这样可能关心我们组的人有一个比较清楚的认识。
11. 关于产品发布  do it slowly and steadily，gate launch 产品到了一定程度之后总要碰上发布阶段，发布的时候大家都担心的是发布出问题了你怎么知道，该怎么办，我们在上面也有很多这问题的思考。因为你如果什么都不做，你什么都不知道，我们的思路是do it slowly and steadily,我们用的是gate launch。我们做了个tool叫做gate keeper, 这里面做的事情是允许你在做那个launch 的时候针对你的目标用户一开始的时候只launch 1%，5%、10%，然后每一步你监测数据，监测两个方面，你的系统是不是在支撑，是不是再crash替换一个你想要的一个效果。你说你做的这个系统revenue有10%的装满了在你的预计当中，但是实际上什么都没有发生，搞不好还下降了。这种就是basis impact 一个management ,基本上就是这两个东西。 我刚刚翻了6个东西，这大概是最完整的，绝大多数没那么完整，他可以跳1%，10% 100%都有可能，可以控制的一些属性呢包括年龄啊，性别啊，国籍啊，语言，我可以开始发布的时候，如果这个功能是针对学生，我可能一开始只发布给北大清华，发布给斯坦福，然后我在下面再观察一下这里面一些用户的反应再把它扩展出来。你的教育程度，哪家公司的，这些东西都是我们能够控制的，这个工具是非常好用非常强大的。 回过头来提一下preview launch review ，Facebook 也是在出了事故后去做。后来有发现有些问题如果事先去思考一下的话，可能我们会想再做一些防护性的措施，这个就叫做pre modem review。这个东西也是在review 之前，在发布之前，我们找相关的人坐在一起 go through 一下我们的lounge plan。一开始要lounge针对那些人，要monitor 的东西，那些人在那里监测，保证相关的人在这里看着，需要set up 什么样的alert，所有人都坐在电脑面前，从6点到12点都是没有问题的，结果大家都去睡觉了，到1点钟全部都要crash怎么办？就是有一些自动的报警，Facebook 有个团队，他们24小时轮班监控。那些人发现如果你的alert是critical 的，他们就会给你打电话，把你从床上拽出来这样的事情至少要做出来，有一个防护，在这个讨论中又发现有些点非常重要，我们什么都没做，基本上是在那里赌博的，那个时候我们要考虑一下要不要做，并不是所有这些东西都是要做的，否则的话这个事情就没有办法lounge ,我们有这样子的一个practice。 不是所有的组都做这样的事情，但是有一个事情可能会做：发一个邮件告诉全公司，至少给所有的工程师和产品，说我们要发布这样一个功能在什么时候针对什么样子的人，大致的一个发布的计划，至少会写这么一个邮件放在一个可以公开订阅的列表上面。 刚才说的每一步你在发布的时候，如果你要知道自己发布的成不成功，最重要的事情就是你要monitor，你要监测。监测一些核心的数据，可以使手动的，尤其是图形化的发布，你看看你关心的核心数据是怎么样一个走势，可以再那边看着非常直观。另外一个是out mat。自动的一些核心数据上面，有两个，一个是，你可能人脑来判断的和机器的判断会有差异，你看一会总会跑去睡觉吗，夜里的时候，机器自动来给你观测。 到了最后一刻的时候发布成功的时候，刚才那个top goal 我们就在那边把这个温度计填满，到达最满，拍一下照，开心一下，这个事情蛮好的，就是有一种成就感。这个部分完了，接下来就是个轮回了，到下一个cycle。 刚才谈的所有的东西之后我想就是，其他东西都忘掉了，我希望大家可以了解一下我们做这么东西的一个精髓。Shift shake out as you can as possible.但两点，一个是soon，在你的能力范围之内，质量保证的范围内把这个东西越快越早越好的把它扔出去。然后看一看你所关心的那些核心数据，在这个基础上再进行迭代，不需要什么东西等这个等那个，虽然我们刚才看到的，每一个组每一个流程并不是都在做这样的流程，根据你自己的需要，根据你自组的特点，有的东西你可以用成本更低的方式来处理，也可以完整的按刚才那套方案来进行项目运作。