需求评审完成了，测试用例、UI方案、技术方案也都评审完成了，产品经理终于可以松一口气了。
研发热火朝天写代码的时候，产品经理都在干啥?
1、如果是迭代产品，又要苦逼的处理下一个迭代需求了，不过这是最安静最自由最可控的时间，可以安心干活。
2、如果是一个项目，研发期间可能就要介入下一个项目了，身兼多个项目，思维和逻辑要来回切换，强度也很大，身当牛马。
3、如果你的团队没有专门的项目经理，那么你还要同时负责产品迭代管理工作或者项目管理工作，团队成员性格各异，沟通和管理让人心累。
一、研发偶尔会找你确认需求细节
有几种情况：
1、需求文档写的很清楚，研发看文档不细心，这种情况最好的方式就是把需求文档对应的地方截图圈给研发，一句话都不用说，如果你忍不住diss几句也可以的。
2、需求逻辑很复杂，研发需要多次沟通再确认，单纯看文档可能不能完全理解，虽然评审过但是很容易忘记和遗漏。
3、也有可能是研发过程中发现一些细节需求没有考虑到，经过沟通后还需要产品经理补充需求。
需求开发完成后，研发需要根据测试用例自测，自测完成后提测给到测试同学，测试阶段就开始了。
二、问题不断，麻烦不断
测试阶段就是测试给研发找问题的阶段，测试以找bug 为目标，研发也有bug率考核，期间有很多争吵。
产品经理经常被测试研发拉上来评估某个问题是不是bug，自此产品经理变成了判官。
简单的直接就判了，复杂点的问题可能是需求没有考虑到的，要么就需求变更，要么就把问题当作下一次迭代的需求，也就是问题转优化。
产品经理身上挂的bug 竟然比研发还多
每个迭代都会有很多问题，这些问题都是变成单据转来转去，很多问题确实不太好处理要转优化的或者需要产品来判断补充的，都挂到产品经理名下了，等着产品处理，要是处理不及时，产品经理名下的bug可能比研发还多。
三、所有需求最终都要转给产品经理做验收
需求单测试完成后状态就变成待验收状态并转到产品经理这了。
验收是一件很重要的事情，要检查是不是和自己提出的需求一致，体验好不好，因为最终面向客户的是产品经理，如果有问题还要被客户投诉或者抱怨，所以验收要细致，有问题有缺陷要及时提出来让研发修改好。
最怕在验收的时候，在实际操作功能体验时发现需求还要优化，时间又来不及了，内心还是很着急的，要想办法沟通研发看能否帮忙快速处理，如果研发短时间搞不好还要安排最快看什么时候可以上线。
四、最后还有一个发布评审会
产品需求全部验收通过，测试的必解bug全部处理完成后，还要开一个发布评审会，这个会也可能是提前就计划好了，在某一天开。
项目经理组织团队研发、测试、产品在一起过一下即将发布的需求明细情况：主要是Bug统计情况，有多少bug，解决了多少，还有多少没解决，没有解决的问题要一个一个过，确定这些问题是否影响上线，如果不影响就带bug发布，影响就要推迟或者某个需求不发。
决定权一般由大家一起达成共识，测试要负责质量是最重视的，产品经理要负责用户体验，面对用户压力也要衡量清楚，而技术对市场和用户敏感度低，最容易放行。
最后的话
研发、测试、验收三个阶段，产品经理更多都是在沟通和推进自己的需求快速上线，过程中难免要处理一些棘手的问题，最怕的是最后才发现需求有问题，上线在即，焦急万分。
做项目会有风险管理，问题发现越晚风险越大，甚至导致项目延期，所以我们必须在需求阶段就要把所有情境都考虑到，特别是业务主线需求，一点问题都不能有，产品经理要去多理解用户和感受所有用户群体的痛点。
团队在做产品项目时，环节越多说明管理的越细，对稳定性具有较高的保障，而环节少效率会高一点，但是对团队质量要求高。
