[repost ]解密Facebook产品开发流程的九大步骤

original:http://www.managershare.com/2013/03/28/nine-steps-to-decrypt-facebook-product-development-process/ 王淮是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等）。不管你做没做计划，所有的决定都围绕着这四个方面进行考量。如果进度拖后了，那么可以去掉或精简一个功能，或者推后完成的 时间，或者增加人手、加大投入，或者降低质量等，无非就是在这四个方面进行取舍。 很重要的一点是，设计产品时，要大概知道第一版本（V1）是什么样子。可以在设计时构思产品的最终状态，但公司不会允许花大量的资源去打造一个所谓的终极版本。一定要思考第一版本包含哪些功能、什么时间发布、要多少人员配置、要花多少钱做市场宣传、达到什么效果等。 这可以避免一开始投入过大，但做出的产品并不是市场所需要的，再进行很大修改甚至放弃该产品的情况出现，这无疑是很大的浪费。 [...]



via WordPress http://blog.newitfarmer.com/software-design/design-product/13036/repost-%e8%a7%a3%e5%af%86facebook%e4%ba%a7%e5%93%81%e5%bc%80%e5%8f%91%e6%b5%81%e7%a8%8b%e7%9a%84%e4%b9%9d%e5%a4%a7%e6%ad%a5%e9%aa%a4#utm_source=rss&utm_medium=rss&utm_campaign=repost-%25e8%25a7%25a3%25e5%25af%2586facebook%25e4%25ba%25a7%25e5%2593%2581%25e5%25bc%2580%25e5%258f%2591%25e6%25b5%2581%25e7%25a8%258b%25e7%259a%2584%25e4%25b9%259d%25e5%25a4%25a7%25e6%25ad%25a5%25e9%25aa%25a4