解密Facebook产品的开发流程(2)

　　很重要的一点是，设计产品时，要大概知道第一版本(V1)是什么样子。可以在设计时构思产品的最终状态，但公司不会允许花大量的资源去打造一个所谓的终极版本。一定要思考第一版本包含哪些功能、什么时间发布、要多少人员配置、要花多少钱做市场宣传、达到什么效果等。

　　这可以避免一开始投入过大，但做出的产品并不是市场所需要的，再进行很大修改甚至放弃该产品的情况出现，这无疑是很大的浪费。

　　而对于技术性的系统或框架，通常会召集相关专家开会，介绍新系统，并讨论为什么做这个系统，以及其优缺点、跟已有系统的关联。这种讨论会，相对技术性比较强，一般不会有产品经理参与(他们不大懂后台的技术)，更多的是邀请有相关经验的后台工程师参加。

　　这里要特别强调的是，Facebook非常注意不重复开发新的技术系统。一个原则是：有好的开源系统，就用开源的;有好的商用产品，就购买商用的;必须自己开发的或者跟Facebook核心竞争力息息相关的，则集中力量开发一套，而不是重复劳动，开发多套类似系统。而对于一些跟核心数据息息相关的系统，即使市场上有商用系统，Facebook还是会自己开发。

　　另外，Facebook从不期望由一个人完成某个项目所有的事情。我会要求某个组员来承担某个项目的责任，但要的是让他驱动整个项目，并不代表所有的事情都完全靠他个人去做。我会要求他善于使用整个公司的力量，学会积极主动地获得别人的帮助，事半功倍地完成一个项目，同时在这个过程中获得成长。如果让其他组帮助做一些事情更加适合的话，我也会鼓励朝这个方向努力。

　　但如果一个项目最终不成功，那么项目负责人是不能以别人无法提供帮助作为借口的。因此，即使别人答应帮忙，项目负责人还是需要学会去激励别人、监督别人，通过“抒情讲理”甚至“威逼利诱”等各种手段获得及时的帮助。

　　但Facebook的文化鼓励只有适合寻求帮助时才这么做，属于一个项目核心的工作必须由该团队自身去完成。别人一般只能在他们的系统上给予配合或者技术上给予建议，最主要的挑战还是靠自己。也只有这样，一个团队才能真正获得成长。

　　指定项目责任人

　　要为每一个项目都指定一个明确的责任人，一般都是工程师。这样做最大的好处是责任非常清楚，每一个项目都有非常清晰的拥有者(Owner)，这让推脱责任变得很难。

　　第二个好处是锻炼员工的才能。Facebook不希望初级工程师永远做螺丝钉的角色，希望每个工程师都能积极领导一项任务，推动项目进展。责任明确的项目可以“逼迫”工程师担当起责任。

　　第三个好处是方便交流。公司里任何一位对某个项目感兴趣的同事都可以了解该项目的进展情况，项目责任人就是他交流的对象，而不需要一定要去找技术经理或者产品经理。

　　定期碰头会

　　对于每一个开发中的项目，我们都要清楚地知道具体进展，因为今天做好的东西是明天的基础。根据项目的紧急性和重要程度定期讨论，可以每天都进行，也可以每周进行一两次。一般每次会议在10～30分钟，而越频繁的碰头用的时间应该越短。

　　召开碰头会时，所有跟这个项目相关的人都要参与，围绕着这个项目把所有相关的任务及其进展迅速过一遍，每个人把自己前一天(或者前一周)完成的任务情况汇报 一下。如果遇到了困难，大家会集中讨论，帮忙解决。最好不要找一些愚蠢的借口来搪塞，这将导致原先答应的事情没有按时按质按量地完成。

　　了解进度　汇总报告

　　对负责一个团队的研发经理而言，要对自己组里正在进行的每个项目都有深入和及时的了解，知道最新进展。处于绿灯状态的，当然很好，要给予鼓励;处于黄灯状态 的，要给予适当的帮助，挪掉绊脚石，加速项目进展;处于红灯状态的，要了解为什么会这样，还能否采取相应措施补救。在行动之外，非常重要的就是反省，弄清楚为什么没有在黄灯时及时发现并给予帮助，然后吸取教训，避免将来出现同样的失误。

　　对战斗在第一线的团队，定期的项目碰头会可以让某个项目的所有战斗人员都能保持对信息获取的一致性，有共同的交流基础。然而，后方人员，比如关心某个项目的同事或者老板的老板等，要了解一个项目的进展不是非常轻松的事情。作为研发经理，我会在每周五把组里当前正在进行的所有项目的进展情况汇总到一起，形成简报，给所有关注支付产品的人发邮件，让他们都能有机会了解到相关情况。

　　发布产品　监测数据

　　产品完成开发之后，当然就要推出去。推出去之前，有些产品需要进行风险控制。比如，支付类的产品经常会做发布前评估(Pre-launch Review)。

　　所谓发布前评估，就是在发布之前，根据具体的产品或者该次发布的特点，做一些诸如发布策略、需监测的核心数据、产品演示、核心算法改变等方面的讨论。在做产品讨论时，我会要求参会的人员思考这个问题——“如果这次发布出现大问题的话，可能会是什么?”主要目的是在发布之前思考可能会出现失误的节点，如果是大风险，做一些必要的防护措施;如果是小风险，心里要清楚自己在冒这个险，准备好一旦出问题该如何补救。另外，由于Facebook发布的产品比较多，经常出现互相影响的情况，做发布前评估可以让大家知道什么产品即将在什么时候推出去。

　　一种发布工程的做法是阀门控制式的灰度发布，就是有所控制地选择发布的人群及其比例。灰度发布是控制发布的范围和速度，但如何才能得知某一阶段产品发布的质量，何种状况下才提高灰度发布的范围呢?只有通过数据监测来判断发布状态。需要监测两类数据。

　　一类数据反映当前的系统状态，比如访问总量、访问成功量及其占总量的比例、致命范围错误的量和比例、访问速度、出现最多的错误类型统计等。这些数据的统计和展示都应该是实时的，才能确保一旦发生问题，能够在最短的时间内发现并采取措施。

　　另一类数据反映新功能的用户影响(User Impact或者Business Insight)。这部分数据能直接反映出一开始做这个产品或者功能的目的。只有这部分的数据反馈是正向的，而且其变化达到了让人接受的程度，才可以考虑扩大发布范围。

　　并不是所有的发布都是成功的。从我的经验来看，追求完美的发布是不现实的，不管之前的Pre-launch Review多么全面，每次发布都有这样或者那样的问题产生，最好的情况就是每次的问题都是新的，而不是上次已经出现的失误。但在问题发生之后，通常通过 Post-Mortem尝试尽可能从失误中吸取教训，让每次的发布带来的学习价值最大化。

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