蜗牛派在一个产品从设计到上线的过程中，产品经理大致需要经历：「需求设计」-「产品内审」-「工程评审」-「开发过程」- 「产品验收」-「测试过程」-「灰度发布」-「全量上线」这几个流程，我刚开始实习时，对于自己在各个流程中应该扮演的角色认知其实是很模糊的。所以，这篇文章主要讲解各个环节的内容、目的以及产品职责，希望对产品新人能有所帮助。
一、需求设计
简单来说就是写prd，这部分大家都比较熟悉，就不作展开。
二、产品内审
产品内审即产品经理内部的评审，有可能是同级互评或者上级评审。一般是辨别需求的真伪，设计的合理性。有时也会有多个项目PK的情况。
产品内审的目的其实就是让你的产品同事为你的产品方案把关，保证最终输出的PRD的下限。通过产品内审的需求，即认为该需求在产品内部达成共识，这个需求就不再是”xx产品经理的需求“，而是”产品部门的需求“。产品经理的一大禁忌，就是在工程评审时（产品内审已通过），在研发和测试面前，产品经理之间互相质疑需求的合理性和严谨性。
在这个环节中，产品经理主要要做的是将自己”为什么要这么做“”为什么不这么做“表达清楚，合理听取意见，会后改进文档。
三、工程评审
工程评审是产品功能涉及到的研发和测试们评审需求的环节。有以下几个目的：
- 让工程师了解需求，遇到疑惑随时提问
- 前端、后端等不同研发工种间讨论如何配合实现
- 测试同学了解需求，便于写测试用例
我刚开始实习时，对于工程评审是十分恐惧的，很担心在会上被研发或测试同学当面质疑，或者找出PRD里的漏洞。同时，我是属于思考比较慢比较稳的类型，所以临场反应往往很慢，当他们提出问题，以及问我解决方案时，我往往会停顿很久，导致场面十分尴尬。
经过N多次评审后，我慢慢解决了这个问题，我的经验是：
一、转换心态。当开发或者测试提出疑问时，不要觉得他们在”质疑“你的需求或者产品能力。大多数情况下，开发更关心的是如何实现，测试更关心的是如何测试，而不是去推倒你的需求。所以，当他们提出疑问时，不要将它理解成对你个人的一种质疑。这样，有助于你更加轻松地掌控场面。
二、工程评审前先对需求。评审前先找前端/后端负责人对大致对需求，这是很多产品新人容易漏掉的环节。
设想一下，如果你在工程评审前，已经跟所有涉及的开发都沟通过产品的可行性，那这个工程评审不就跟走过场一样轻松了。
当然，为了效率考虑，我们不可能这么做。但是跟主要的负责人简单对下，还是可以做到的。将文档发给负责人，简单约个时间，对一下技术可行性，以及部分细节。这样，你相当于在工程评审前获得了负责人的背书，在评审时，遇到问题，有可能负责人会出面提你回答，何乐而不为。
三、评审过程中遇到问题，可以会下解决。无论你的文档写得多严谨，终究会有一些技术细节或者特殊情况难以考虑周全。在会上被同事提问，又无法及时想出解决方案时，完全可以跟大家说，我会后想一想，再补充在文档里。不是所有问题都必须在会上解决。
在工程评审环节，产品经理的职责是充分表述需求的内容，涉及到的风险点，解答疑问，协调确定实现方式，会后完善文档。
四、开发过程
工程评审完就消失的产品经理是不负责的。在开发过程中，产品经理的职责就是为工程师顺利开发解决一切困难！比如涉及到跨部门沟通、配置问题、资源问题等等，产品经理都应该第一时间站出来，推进解决问题，让工程师集中精力开发，这样你才能成为工程师们值得托付的产品经理。
同时，要定时的查看产品完成情况，如果产品验收时是你第一次见到产品，这个风险是非常高的。最好是能在开发过程中，时不时去开发的电脑前看看半成品，避免产品偏离你想要的方向。
五、验收环节
有些公司验收环节是在测试环节之后，这两个过程各有优劣。
产品经理先确认产品功能、UI符合要求，再让测试同学测一些细节，可以节省测试同学在测试过程来回于产品校对，但是产品经理由于验收的产品只经过研发自测，可能存在较多问题，所以可能会花费较多时间；
测试先介入测试，测试完成后产品发现不符合预期，重新调整，测试，测试资源是有一定浪费的。
产品验收的目的是确保研发出来的产品符合产品经理的预期，避免上线后回炉重做的事故。
在这个阶段，产品经理的职责是检验产品功能是否符合PRD描述，主流程能否跑通，关键功能是否正常。注意避免陷入细节之中，那是测试同学要做的事前。
六、测试过程
测试过程是测试按照测试用例，全面测试产品功能、可用性、可靠性的过程。在这个过程中，会涉及到产品、测试、研发三方的沟通，但是主要是产品来拿主意。哪些缺陷可以忽略，哪些未实现功能可以下版本再做等等，都需要产品经理合理衡量决策。
在完成测试服测试后，一般会进行线上白名单测试，即将功能发布到线上，对测试同学白名单可见，线上去测试功能确保万无一失。线上配置一般只有产品经理或运营才有权限，需要配合配置。
七、灰度发布
产品新人常常搞不清「灰度发布」和「AB测试」两个概念。
「灰度发布」更多的是一种基于安全性、稳定性考虑的发布策略。比如我线上版本是3.49，即将上线3.50版本，那么我们可以先灰度10%的用户，发现各项数据正常（业务数据、服务器），无用户反馈异常，则可以加量至30%，50%，直至全量。如果中途遇到问题，则可以取消灰度。
「AB测试」则是一种测试方式，例如我们在考虑圆形按钮和方形按钮哪个效果更好时，就可以采用AB测试的方式，测试组10%的流量是圆形按钮，对照组10%的流量是方形按钮，观察点击数据。
此外，产品策略、数值设置（特别是游戏）也有经常用到AB测试，观察不同数值设置的效果。
这时候我们就不能说我们在”灰度“这个策略了，因为我们实际上是将两个策略进行比较，是一种试验，并不是在从A策略过渡（灰度，即从黑到白，从低级到高级的过渡）到B策略
灰度过程中，产品经理需要留意上线数据是否有异常，有异常时及时回滚。
八、全量上线
终于到最后一环了。全量上线后产品经理就可以观察数据是否符合预期了，调整策略，持续观察，准备下次迭代内容了。
