在所有的WEB 2.0公司中，Facebook可以说是独树一帜。美国市场研究机构Altimeter Group发布统计报告称，2012年Facebook营收为50.89亿美元，而该公司员工总数仅为4619人，因此其每个员工贡献的营收达到110.18万美元。相比起来，互联网巨头Google每个员工贡献的营收仅为94.6万美元。吴军老师在《浪潮之巅》和《文明之光》中也对Facebook作出了高度评价，认为未来如果有一家公司能够挑战Google的霸主地位，那么这家公司就是Facebook。
为什么这么多人都看好Facebook？为什么Facebook开发的产品总是那么的酷呢？我想，它的产品开发流程必然会有不寻常之处。在《打造Facebook》一书中，作者详细描述了Facebook的产品的开发流程。总结起来，总体流程如下图所示。 
作者认为，为了做出引领潮流的创新产品，在产品开发流程中的每一步，Facebook是这样做的：
描绘远景，设置目标
对于远景，要思考以下几点：
第一，为什么设这个目标而不是另外一个目标？
第二，在做一件事情之前，脑子里应该有这件事情完成之后是什么样子这样一个画面，接下来很多事情都是围绕着这个最终画面来进行的。
第三，计划做些什么事情来实现这个远景？
我们可以采用“SMART”规则来设定目标：S—非常详细具体的(Specific)，M—是能够衡量的(Measurab1e)，A—要够有难度、有挑战性(Aggressive)、R—现实的(Rea1istic)、T—要有实现的期限(Time-bound)。
收集想法并排出优先次序
想法可以来自任何人和任何地方。在Facebook，一般是由技术经理、产品经理、工程师贡献大量的想法。
收集了想法之后，接下来要做的是先列出设定的目标，再在这个目标的指引下去思考哪些想法可以为之服务。
等有了足够多的、不错的想法之后，接下来最为关键的—步就是分析想法，即如何挑选出最可能产生效果的想法。
关于时间分配，有一个“6-2-2”原则：60％左右的时间放在那些能够预期的工作上，20％的时间花在后台架构和产品质量上，20％的时间花在比较有风险、有争议的、可能会带来某种颠覆性的后果的那些想法上。
如何挑选那些接下来要去实现的想法呢？要注意以下几点：
第一，季度性计划主要是指导性的，不会强求把它们变成必须要遵循的工作计划。
第二，围绕着每个想法的影响力进行辩论。
第三，“120％”规则，即尝试去实现120％的想法。
第四，要保证一些底层架构和产品质量的工作是在这些想法之中的。
最终挑选出要做的想法后，会整理出一个项目计划。计划上的每个项目都对应着一个想法，每个项目都会列出明确的责任人，一个项目下可能有多项需要完成的任务。
对于小组特别关注的最最重要的目标，会在黑板的一边列出来，相关责任人的名字、预期的时间点都放在上面。另外一边用温度计的样子来显示完成的进度，非常直观。
跨团队沟通
两类人是特别需要沟通的：一类是不同职能之间的沟通，另外一类是相关的工程兄弟组之间的沟通。
跨团队沟通也让不同的团队事先都清楚自己在一个项目中的角色和任务，知道哪些人将会在一起合作，各个组可以做出事前的安排。
告知所有可能关心的人
召开一次最终的计划定夺会议。整个计划定下来之后，会发—封邮件给所有关心该计划的人和相关工作的人。
设计产品
任何一个项目具体执行中一般都涉及四个维度：有哪些功能，预期完成时间，预算(主要是人员，还有服务器、带宽资源、金钱等)，完成质量(包括可扩展性、性能等)。
很重要的一点是，设计产品时，要大概知道第一版本是什么样子的。
在Facebook，为了在项目开始时尽可能获得高起点，很多组采取产品预览(Product Rev1ew)或者技术预览(Technica1 Review)的做法。
一个原则是：有好的开源系统，就用开源的；有好的商用产品，就购买商用的；必须自己开发的或者跟Facebook核心竞争力息息相关的，则集中力量开发一套。
Facebook从不期望由一个人去完成某个项目所有的事情。
对于产品设计，有以下一些基本理念：
第一，不要过度设计。
第二，产品越简单越好，但并不意味着简陋。
第三，对于自己做出来的产品，你必须是它的用户。
第四，产品要确实有用，主要流程尽可能顺畅。
第五，不追求完美。
第六，保留最基本的质量底线。
指定项目责任人
对于每个项目，都要指定一个明确的责任人，一般都是工程师。这样做最大的好处是责任非常清楚，每一个项目都有非常清晰的拥有者；第二个好处是锻炼员工的才能；第三个好处是方便交流。
定期碰头会
对于每个开发中的项目，要清楚地知道具体进展，因为今天做好的东西是明天的基础。
召开碰头会时，所有跟这个项目相关的人都要过来，围绕着这个项目把所有相关的任务及其进展迅速过一遍。
了解进度，汇总报告
对于负责一个团队的研发经理而言，要对自己组里正在进行的每个项目都有深入和及时的了解，知道最新的进展：哪些项目处于绿灯状态，哪些处于黄灯状态，哪些处于红灯状态，并对此进行思考、采取相应行动。
编写简报的注意事项：
第一，简报应该能在一分钟之内被人阅读完毕。
第二，在简报的最开头一段，可以明确列出这周的核心数据的变化。
第三，应该只涉及组里最重要的3～5个项。
第四，每个项目只用最最重要的一两句话去阐述清楚进展。
第五，项目进展的描述要着重在动词上面。
发布产品，监测数据
发布前评估，就是在发布之前，根据具体的产品或者该次发布的特点，做一些诸如发布策略、需监测的核心数据、产品演示、核心算法改变等方面的讨论。一些经验：1)要短；2)形式可以多样；3)人员选择可以多样；4)内容可以多样。
一种发布工程的做法是阀门控制式的灰度发布(Gated Launch)，就是有所控制地选择发布的人群及其比例。
需要监测的有两类数据：一类数据反映当前的系统状态，另外一类数据反映新功能的用户影响。
所谓Post-mortem，就是通过分析过去发生的问题，从中总结可以采取的行动方案，以避免类似的错误再次发生。
Post-mortem会涉及以下几个方面：
第一，发生了什么？
第二，影响多大？
第三，问题的原因是什么？
第四，事件发生的具体时间表？
第五，如何避免将来犯类似错误的行动方案？
从以上的总结中，我们可以看到，Facebook的产品的整个开发流程注重的是工程师的自主性、流程的合理及规范性、产品质量的可控性及可监测性、产品版本的持续完善性。与之相对的，国内很多IT公司的做法是这样的：
第一，软件工程师只需要实现需求工程师给出的需求，根本没有直接与客户进行交流的机会。工程师的很多想法都会被无情地驳回，以至于其创造性及主动性消失殆尽。
第二，开发人员只顾编码实现需求，而不重视对开发出来的软件进行测试，抑或是随便设计一些测试用例就了事。每当客户返回软件问题之后，又要占用大量的工作时间来“救火”。
第三，代码质量完全由作者本人说了算，没有同行评审流程。即使有，也是流于形式。在提交软件版本之前，也没有人来对代码的规范性和版本的完整性进行检查。
第四，不注重产品的用户体验，缺乏一种从用户的角度看问题和以用户为中心的理念。单单强调产品功能，而忽视了其易用性。
作为一家引领时代创新潮流的公司，Facebook的诸多经验值得广大IT公司学习和借鉴。就像李开复老师所说的：“无论中国是否能出一个Facebook或扎克伯格，我都相信理解Facebook，并从王淮的亲身经历学习，对于中国的创业者、工程师、学生都会有莫大的帮助。”
欢迎大家关注并支持本人新书《C程序员从校园到职场》。
