解密Facebook产品的开发流程

　　【编者注】王淮是Facebook第二位中国籍工程师，也是第一位中国籍研发经理，他一手开创了Facebook的支付安全和客服工具领域。2011年他离开Facebook，回国成为天使投资人，希望用自己在Facebook的经验帮助创业者。

　　在详细说明Facebook产品开发流程的九大步骤之前，必须先讲清楚一点，这些是我用马后炮的方式来思考自己在Facebook做产品、项目的实践中可能出现的步骤。所谓的“流程”，在Facebook内部并不存在，这些步骤并不都是必须的。对于不同类型的项目，有些对时间要求高一些，所以更强调速度;有些对质量要求高一些，会更强调项目管理的流程(Process)。请读者在阅读时仔细斟酌，哪些符合自身的实际情况，则可以借鉴; 哪些不适合，要灵活掌握。

　　描绘远景，设置目标

　　做每件事情之前都要有明确的目标，在聚焦于细节之前要有大的远景(Vision)，这可以在以后的实施过程中指引方向。对于远景的思考，主要围绕以下三点。

　　1. 为什么设这个目标，而不是另外一个?

　　2. 在做一件事情之前，脑子里应该有这件事情完成之后是什么样子这个画面，接下来很多事情都是围绕着这个最终画面来进行的。

　　3. 计划做些什么来实现这个远景?这就需要将最终目标具体化，变成一个可以想象的图片，甚至量化，然后才能使得最终目标容易被别人理解。

　　那又该如何设定目标呢?在Facebook，常用的方法是遵循“SMART”规则。

　　S——非常详细具体的(Specific)。目标必须被清晰定义，无法被混淆或者误解。

　　M——是能够衡量的(Measurable)。只有可以被衡量的目标，才能一直清楚做得如何，离目标有多远，当前是超出还是低于预期的进度。

　　A——要有足够的难度和挑战性(Aggressive)。容易完成的目标，很容易让员工懈怠;一旦失去战斗的激情，更谈不上发挥潜能。

　　R——现实的(Realistic)，这是对上一点的平衡。过于有难度的目标，会令员工疲惫不堪，如果最后还是没能完成任务的话，对他们的信心是非常大的打击。

　　T——要有实现的期限(Time-bound)。没有实现期限的目标是没有意义的，因为不知道什么时候应该到达什么程度。

　　有了目标之后，才可能有很详细的项目计划，所有的项目都应该是跟这些目标相关的。不相干的项目会分散注意力(Distraction)，要坚决抵制。接下来，组里人员的绝大多数时间都要花在跟这几个目标相关的项目上。

　　收集想法并排出优先次序

　　有了目标以后，会产生很多相关的想法(Idea)，但很难判断究竟哪个想法一定能达到这些目标，也不可能把所有的想法都试一遍，往往到最后都需要有理有据地 进行“赌博”，把精力押在某几个核心的想法上。这也是Facebook要招最好的工程师的原因之一。工程师不仅要善于写程序，也要有选择想法的能力，你不仅要对这个问题有很深入的思考，进行大量的分析，还要有胆量，能果断押注，并且有很高的命中率。

　　那么，这些想法从何而来呢?最自然的方式就是之前延续下来的、大家明确知道要做的项目，而那些不明确的想法，才是难点。在发展非常快的公司里，绝对不会缺少这种不明确的想法。在Facebook， 一般是由技术经理、产品经理、工程师贡献大量的想法。负责商业运营(Business Operation)的同事也会贡献一些想法。做下一个月计划时，我会在当月25日左右开始给相关人员发一个一周后的头脑风暴会议邀请，并希望他们在会议之前把自己认为应做的或者想做的事情发邮件告诉我。我事先做分类整理，让会议进行得更加高效。当然，线下的讨论、分享等也是产生想法的好机会。

　　接下来最为关键的就是分析想法——如何挑选出最可能产生效果的想法。理论上，如果有无限的资源，我们应该尝试所有的想法。但在Facebook，任何时候都处于资源短缺的状态，我们必须把有限的资源放到有可能产生最大价值的想法上面。

　　这里，我要特别强调一下“Top X(只做前X项)”规则：只做对目标最有影响的前X项。我们会对所有的想法进行讨论，根据每个想法对目标的影响和其所需要的资源(主要是人力与时间—— “人周”)进行讨论，然后排序(按P0，P1，P2……的方式来)，最后挑选排在最前面的几项。分析完后，对几个明显一定要做的想法很容易决定，对几个要去掉的也很容易决定，关键是剩下的那些想法，没有足够的精力把它们都尝试一遍，这就要考验你的抉择能力了。

　　跨团队沟通

　　决定了要做的项目之后，就需讨论如何跟其他相关组的计划对接。你当然不希望原本以为兄弟组能配合自己做一个项目时，却发现对方并未把与你项目相关的工作放入他们的计划中。这里要进行的沟通，就是让相关组之间做的事情是相辅相成的，而不是互相扯皮，造成不必要的内耗。

　　有两类人是特别需要沟通的。

　　1. 不同职能之间的沟通，包括工程师、产品经理、设计师，还有与项目相关的上下游团队或部门。

　　2. 相关的工程兄弟组之间的沟通。因为大家相互之间经常有技术或者框架上的共享，我们定下要做的事情，就看看相互之间是否有可以匹配的项目，如果我们需要他们的配合，就要看怎样可以列入他们的计划。

　　告知所有可能关心的人

　　我们会召开一次最终的计划定夺会议。主要是由工程师和产品经理及一些非常相关的人参加，这种会议是小规模的，因为不想在决策时让其他非产品技术的人员参与进来，其他人的声音已经在之前的跨团队沟通过程中被充分地考虑了。如果前面的工作准备得比较好，这种会议速度都很快，一般半个小时左右。

　　整个计划定下来之后，会发一封邮件给所有关心该计划的人和相关工作的人。并且会在接收人那里把老板、老板的老板都放进去，以确保他们能清楚、理解并支持我们组的计划。

　　设计产品

　　对于任何一个项目，具体执行中一般都涉及四个维度：功能(Feature Set)，预期完成时间(Time to Market)，预算(Budget，主要是人员，还有服务器、带宽资源、金钱等)，完成质量(Quality，包括可扩展性Scalability、性能Performance等)。不管你做没做计划，所有的决定都围绕着这四个方面进行考量。如果进度拖后了，那么可以去掉或精简一个功能，或者推后完成的时间，或者增加人手、加大投入，或者降低质量等，无非就是在这四个方面进行取舍。

原文转自：http://kb.cnblogs.com/page/173482/