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