开需求评审会后，需求评审达成一致，进入研发阶段。没有需求设计的产品应该充当什么角色、干些什么呢？
目录：
一、需求评审后所处阶段
首先一个小产品功能落地到使用共四个阶段：采集需求——分析需求、设计需求——研发期——运营使用期（然后从采集需求开始循环）；而需求评审所处分析分析需求、设计需求阶段。
需求评审会后，我们处于分析需求、设计需求阶段，阶段向研发期过渡，那么在研发期作为产品应该做些什么呢？
二、需求评审需要做些什么呢？
1. 总述
具体共四个大步骤：完成需求评审会待解决问题、跟进项目、准备项目上线、项目上线步骤，详见下面。
2. 详细
2.1 完成需求评审会待解决问题
需求评审会，对于产品经理，是讲述自己的需求原因和实现的主要步骤、逻辑；对于技术、测试，是评定、审核需求是否有必要做、以及实现方案是否有漏洞的会议。
在这个阶段有可能产品的需求，因为想法不合理、开发等资源达不到被毙掉（当然这个问题，可以通过事前私下沟通避免）。
如果需求没形成闭环，遗留问题过多；需要产品重新完善逻辑，然后进行二次需求评审。
如果资源到位，产品基本逻辑能走通，会对产品逻辑、实现的方法、各种正常异常各种情况下的逻辑和实现可能性、实现成本进行讨论。
ps：私下沟通很重要，私下沟通可以解决很多问题：
对于产品，可通过私下讨论知道自己的想法是否合理、缺失的问题、以及各种实现成本，从而做到心中有数；对于技术、测试等同学，增强他们的项目参与感，并且让他们有所了解，及时提出问题进行沟通。
最终，有一个大圆满结局，不至于把产品需求评审会开成产品需求批斗会。不过私下讨论沟通也是大体上，仅限于各端，各端一起实现这个功能，还是有些需要统一开会解决。
需求评审完，把遗留问题要进一步确认、解决，而后同步给各方。要注意及时同步，以及参与人员的周知；可用发集体邮件的方式和在公共群里@所有人的方法通知，并且要得到大家的回复确认。
2.2 跟进项目
2.2.1 制定项目计划和排期
制定项目计划和排期，是为了功能需求按时按需的完成，主要考验项目管理能力。在项目不能完成时，要及时预警并采取有效解决方案。
2.2.1.1 排期关键点
明确项目总计划、制定关键节点（时间和人）
2.2.1.2 排期注意点
确定总目标，进行子目标拆分，注意拆分到足够细，以便把任务量化到人。
注意多端和上下游的问题。特别是一些需要调取外部配合的数据，需要及时的准备协调好资源。
2.2.1.3 排期通用模版
个人模版：以下是平常工作中用到的简单模版，主要给产品自己看，供参考。现在也有很多专业的排期管理平台可用。
注意：其实，明确排期关键点、注意排期要点最重要，把控进度，让需求功能准时上线最重要。不要陷入排期管理的呈现细节，注重了形式，而忽视了结果。排期的呈现形式表格，只是辅助。
2.2.2 其他需要推进的需求
需求评审会后，还有些流程，需要产品经理参与和推进，项目参与角色有：设计、测试、开发、产品。主要任务有：设计评审、测试评审、开发联调、验收（测试验收、产品验收）。
2.2.2.1 设计
前期：原型交付，进行设计——（设计比稿，进行细化）——验收设计——进行设计、切图
后期：在最后验收阶段，需设计走查是否符合规范。
补充：如果是大型迭代，会有多个设计参与，出具多种方案。
2.2.2.2 测试
根据需求文档，测试会出具测试用例，并开测试用例评审会。
参与人员：包括开发、测试、产品，然后进行细节的补充、修改。
开完测试需求评审会可做的：并将测试用例给开发，让他们知道测试要点，并可进行一些简单自测。
2.2.2.3 开发
A 开发遇到问题类型
主要分为开发中遇到问题、快开发完成时遇到问题。
B 开发中遇到问题和解决方法
开发中遇到问题，可能是开发过程中发现不能按计划完成；主要是排期过短、人员过少。最直接的是向老板提出，增加时间和人员；若时间、人员不可解决，那么就是砍需求功能了。
C 快开发完成时遇到问题和解决方法
对于快开发功能，测试会进行验收。测试汇总所有bug，bug类型为：开发自己编码出的bug、未实现的排期功能。需要产品、开发、测试一起协商，并对本次所有细节需求功能进行确认。
如没问题，产品注意及时了解进度即可。如有问题，产品能自己把控，排出必解的bug；如不能解决（重大延期等，注意及时向老板预警，寻求资源帮助）。
2.2.2.4 产品
A 怎么跟进项目，有哪些标准？
及时跟进进度，大迭代、多个功能进行开发时，及时安装开发包，及时体验，如有错误及时更改。
当领导问起时，能清楚说清节点，。
B 需求更改，各方扯皮怎么办？
进行功能项目中途，难免会遇到需求上错误缺失的小问题、开发对于一些实现上有扯皮。
产品私下调研，给出解决方法——拉涉及所有端的开发集体讨论可行性，如不可再集体讨论出结果——做出取舍后，同步给所有人（开发、测试）结果；以邮件或者群同步的方式——并更新需求文档
C 有哪些需要沟通注意的？
及时给出解决回馈，如不能立即解决，也要给出解决的时间节点并告知相关人员。
2.3 准备项目上线
产品除了设计产品功能，还需从0到1推动产品需求实现，开发完成后，产品需参与到产品上线的全流程中，并推动全流程的进行。那么产品上线全流程是怎样呢？
2.3.1 产品上线发版的全流程？
一个产品正式上线，流程上，需开发提交正式包 → 供测试同学测试封板、供安全审核团队审核（若是新品流程，还需申请新app申请等，此处不再展开）→ 测试对于封板包，发测试测试结果邮件；安审对于封板包，发通过邮件 → 产品对于测试封板包，发产品确认上线邮件
完成这个流程，才算能对外正式上线发布此版本。（具体公司可能上线流程不同，但基本遵循此步骤）
测试验收完成，还需产品验收，产品验收主要包括：主流程、分支流程、逆向流程、重大关键节点。
to c 产品可参考xiaopiu网站的产品自查手册，网址为https://www.xiaopiu.com/h5/byId?type=project&id=5ce262e596541012dae2aec4&isprd=true
2.4 项目上线
2.4.1 对自己，需进行复盘
一个有经验的产品，肯定踩过非常多的坑；但是踩过很多坑的产品，不一定会成为有经验的产品，重点在于总结复盘。那么总结复盘的意义是什么？怎么总结复盘呢？
2.4.1.1 总结复盘的意义？
复盘对于自己最直接的好处，对于失败的项目，找到原因改正错误，避免犯同样的错误，下次更好的完成项目；对于成功的项目，找到可复制方法即找到规律，固化流程和做法、从“蒙着打”到“瞄准打”；并且要从失败和成功项目中，努力发现新的知识和思路。
2.4.1.2 复盘的方法？
复盘共四个步骤：回顾目标，评估结果，分析原因，总结规律。
具体方法：尽量量化结果；精简语言
呈现形式：看汇报对象，如果给自己，建议电子版脑图、word等，自己习惯，方便、快捷、便于日后查询既可；如果给领导，可用ppt展示。
如果想更多了解，推荐参考书籍：《复盘：对过去的事情做思维演练》
复盘才可以更好的让人成长，变成有经验的产品。
2.4.2 对他人，收集意见
2.4.2.1 收集意见对象？
公司内部人员；外部行业人员
2.4.2.2 向公司内部人员收集什么？
to c 主要看此版本发布情况后，用户对此的反馈。代表用户的公司内部人员的反馈，主要是运营、市场、销售等最接近一线用户的同事——他们最能了解用户的想法。但要注意数据样本选取，对照组的正确；并看大多数用户的想法。
此处收集意见的目的，根本是为了用户增长，推荐参考书籍：《我不是产品经理：移动互联网商业模式下的用户增长》。
2.4.2.3 向外部行业人员收集什么？
一个功能，有的时候具有重要的意义，比如代表app调性、具有某个战略意义，所以可以看外部行业人员对于此功能的反馈。反馈包括公开的意见建议和他们负责的竞品功能是否因此有改进。
完成对自己进行复盘、对他人收集意见，才能算是一个项目功能完整做完。当做完后，又进入了第一步采集需求。
三、附录
1. 通用模版表格参考
2. 推荐书籍
①to c产品自查：xiaopiu网站的产品自查手册，网址为https://www.xiaopiu.com/h5/byId?type=project&id=5ce262e596541012dae2aec4&isprd=true
②复盘：《复盘：对过去的事情做思维演练》
③数据分析、用户增长：《我不是产品经理：移动互联网商业模式下的用户增长》。
