我所理解的产品开发流程（下）

书接上回

第五条  确定项目负责人

对于每一个项目都应该有一个明确的复杂人，一般都是工程师。这样做最大的好处责任清楚了，项目成功了，你是功臣，项目失败了，你也别往后躲，拉出来抽一顿。

这样做还有一个好处，就是能帮助你的团队不断的提升能力，明确的负责人，可以积极主动的去领导一项任务，推进项目的进展。这种说法落地到实际情况中去，比如我负责的通用SDK项目，android开发有一个负责人，IOS有一个负责人，后台开发有一个负责人。当开发遇到紧急的情况，需要投入资源的时候，android会有三四个人同时开发，明确的负责人，他会帮助你去协调开发中的一些资源、进度，保证项目顺利进行。

但是话虽如此，也有遇到问题的时候，实际上在项目开发中，因为架构的关系作为一个PM并没有指定某个工程师去负责某块业务的权力，这些通常是技术经理决定的。如果没有理想中的开发梦之队，作为PM我觉得还得有用人之长的技能，比如不善沟通但是代码写的稳啊；demo注释写的比较糙但是和第三方渠道能一起蛋逼啊，这些都是可以善用的。

第六条  进度的把控

定期的碰头会，定期把完成的任务情况要汇报清楚，如果遇到的问题，需要集中讨论下“找到解决方法了么”、“需要帮忙么”、“还有什么其他的可预见的困难么”。

碰头会可以让一线的战斗团队对项目的进展有一致性的了解，项目的那些模块是绿灯，那些处于红灯，需要增加投入。需要注意的是，会议开一次一定要有意义，我参加过一些无聊的会议，因为负责人对项目把控的无力，导致讨论到最后没有结论和进展，我觉得这是对参会人员的不尊重。在项目的进展中，我更喜欢看到一些动词“做了”、“正在进行”、“准备进行”。

第七条  发布产品 监控数据

产品开发完成后肯定是要发布的，在推出去之前，有些产品是需要进行风险控制的，这就需要发布前评估。要尽量的思考，如果这次发布出现大问题会是什么，有什么样的防护措施。发布评估也是分等级的，如果是修复BUG，甚至可以几个工程师+PM口头聊下（但是不等于不重视），如果是较大的更新或是新产品发布，这就需要成本比较高的会议形式了，需要参会人员的多样，需要老大的意见等等。

不能藐视产品发布的任何风险，要真的对它重视起来，但是无论我们怎么做，都不可能保证100%的发布安全，坦然面对并且做好应对措施来降低风险我觉得是个靠谱的方案。

一种发布工程的做法是阀门控制式的灰度发布，控制发布所影响的人群和数量。我了解的灰度发布做的比较好的，一个是facebook，一个是新浪。

比如facebook的策略是，如果有新功能上线，先影响美国的1%的用户，如果没什么大问题再扩大到5%、10%最后到100%。facebook有比较完善的灰度发布工具，只需要在产品的源代码中，加入一行灰度控制代码，就可以很容易的控制该产品的发布对象。在新浪的时候了解到的，灰度发布可以根据条件进行过滤，比如过滤掉所有加V用户，过滤掉企业微博，只对粉丝数量在200~500之间的用户发布。

灰度发布是控制发布的速度和范围，如何得知产品目前的发布质量，并得到结论去控制灰度的范围呢？监控是必不可少的。

监控主要有两类数据，一类是系统的状态，比如总访问量，访问成功率，访问速度等，这些数据都应该是实时的，如果发生问题可以在最短的时间内采取措施，比如马上关掉或者降低灰度，使得影响范围得以控制。如果影响范围波及到了核心业务，那危害性就大了。我不止一次的想过，我负责SDK是作为公司手游的一个单点，一旦新功能上线把服务器搞挂了，公司手游就都费了，那时候我就真得立刻卷铺盖走人了。

还有一类数据是反应用户行为的，比如是否提高了用户的某些行为，提高了多少，这些数据能反映出一开始做这个产品的目的。只有这部分数据反馈是正向的，并且达到了让人满意的接受程度，才能考虑进一步扩大范围。

当然了，这一套监控的后台，是需要有一个较大的团队进行维护的，我觉得是属于公司内部最重要的工具之一了，这套后台并不仅仅是看看数据而已，还要包括监控的分等级预警和通知，比如今天游戏的登录数量和昨天项目突然下降了30%，这时候就需要预警了，相关的人员收到短信、邮件。如果是等级最高的，就不应该叫预警了，而是报警。理论上这时候你在床上躺着，也会被拉起来。

并不是所有的发布都是成功的，所以最后来说说，如果出事儿了怎么办？

其实出事儿不要紧，汲取教训，让你每次都能从失误中汲取最大的学习价值。还记得以前在新浪的时候，有个哥们搞出了事故，结果请整个team的同学吃可爱多并且写事故报告，忆昔记得，那次好像是把私信的转发弄错了，这可是会让人家破人亡的BUG啊，多少私信调情的用户，瞬间就菊花一紧了。。。

重点是要记录下：发生了什么、影响有多大、问题的原因、具体发生时间表、如何避免类似错误的行动方案。

以上就是我所理解的产品开发流程。这套流程比较繁琐，并不适合所有的产品。具体的执行中，还是需要根据产品涉及的四个维度（上篇）进行调整。

写了这么多，主要是梳理下自己的思路，并且供大家做个参考，和大家一起开拓思路，共同进步嘛。

话说前天发了第一个帖子后，看到秘密上有人吐槽，现在的PM就知道整天装逼，说大家都知道的理论，菜鸟们觉得他好牛啊，其实都TM正确的废话，实际上自己啥也没做出来。当时我看完就想，哎~刚写完就被喷。结果看下面十几个回复都是，这不是我们公司那谁谁么？那一瞬间心里的感受是微妙和复杂的。。。