生命不息,奋斗不止/创造价值-传递价值-获得价值
所谓迷茫,就是才华配不上梦想 每一个让你难堪的现在,都有一个不够努力的曾经

产品经理如何做好需求评审?

很多产品经理谈到需求评审都会心理咯噔一下,面色不大好,因为总被虐的不要不要的,阴影面积不知道有多大。而相反有些产品经理却对需求评审情有独钟,享受与各路大侠切磋、舌战群雄的快感,大有三国诸葛亮舌战群儒,排除众议之势。

接下来,先看下需求评审是什么?

需求评审简单来说就是一个评议、审查、明确需求、统一思想并确定实现过程的会议,俗称撕逼大会、挑刺大会、逼死产品经理大会,是产品经理不得不面对的大会。

产品经理在大会中,要对需求及方案进行讲解,并解答市场、运营、设计、技术、测试提出的各种疑问,最终号召大家一起往一个产品目标努力奋斗。

那么为什么要进行需求评审呢?

1.让与会者明确需求是什么,做这次需求对应的业务背景和目的是什么,处于什么样的战略位置,重要性如何

2.让市场、运营、设计、技术、测试等各工种对需求的实现过程和方法达成一致,避免后续的撕逼

3.让市场和运营提前了解项目,提前进行后期市场的推广及运营的准备

4.让技术和测试对产品方案有详细的了解,对有问题的点进行提前提问质疑,以便后续能进行高效的开发

5.让设计、技术及测试评估各自的工作内容及工时以确定方案实现的周期,并和市场及运营确定业务的重要性,看是否要进行模块拆分,分期进行

所谓知己知彼者,百战不殆,所以一定要明白各与会人员的需求,具体整理如下:

明确上面三个问题后,接下来从“评审会前、评审会中、和评审会结束”三阶段如何做好对应的工作。

一、需求评审前

1.和市场及运营再次明确需求,及对应的解决方案是否满足业务的需要

2.将需求、实现方法和核心人员小范围提前沟通,提前消灭掉核心问题,保证整体方案没有出现方向性错误

3.确认需求文档、流程图、原型是否都有完成,是否已经自查没有问题

4.和核心与会人员进行时间的调解及确定

5.至少提前2天发出会议邀请,定好会议室(注:会议邀请要附需求文档、流程图、原型图等相关资料)

6.提前到会议室,过一遍讲述流程,对可能被问到的点进行整理

二、需求评审中

产品新人在进行需求评审时经常犯的错有:

1.一上来就开始讲具体功能

2.什么功能都讲,满面开花

3.对别人提出的质疑,不能给出实际解决方案就开始互怼

针对上面的问题,我们如何进行解决呢?

1.会议开始时一定要先讲需求背景和目的

很多产品经理在会议一开始就直接说功能或方案细节,这个功能实现了什么,那个方案具体怎么实施。试问,如果看一本书,直接看某一页,你知道整本书是要说什么?

所以,开头一定要提纲挈领,说明需求的背景和目的,引导大家进入正题。让大家都知道,为什么产品要进行该方案的设计。

2.要懂得抓大放小,重主干轻枝干

如果你满面开花,首先是时间肯定不允许;其次参会人员会很不耐烦;更重要的是不能针对核心问题深入讨论,确定解决方案。

所以,一定要针对主干流程和核心功能进行详细讲解,对次要的比较常见的功能一笔带过。比如电商类产品,要对用户购买支付流程及订单流程进行详细讲解,对于简单的签到、密码修改等小模块一句带过就好。

3.短时间解决不了的可以记录,会后进行讨论

正常情况,核心功能是要在会前小范围讨论确认过的,会议上不会出现这样情况。但是,不排除会出现之前遗漏的情况。

面对这样的情况,就比较考验产品经理临场发挥能力,能解决的直接会上说出自己的解决方案,一起讨论。如果暂时没有想到合适的方案,而且需要会后进一步和其他部门确定的,可进行记录,会后讨论。

千万不要不懂装懂,和别人互怼。这会直接让自己的信任度直接受到10000点暴击,让其他人觉得这产品经理不专业、不靠谱。

当然,作为会议,肯定是有一套标准的会议流程作为讲解指南,这样才可以从大方向把控产品的节奏,不至于被别人带跑偏。下面的会议流程图,作为参考:

三、需求评审后

是不是审核后,没啥事了呢?

童鞋该醒醒了,还有一大堆内容要你去处理呢,哪有开会后不总结整理的道理。我们在评审会议后需要做的内容有:

1.整理遗留问题,找相关人员沟通解决,给出对应的解决方案

2.发出会议记录,每个问题都要有行动计划

3.发出修改后的需求文档、原型

4.明确责任人及反馈排期

注:如果需求评审涉及到方案的大改,则需要重新针对新的方案进行评审。

说起来容易,做起来难,还是需要童鞋们在理论和实践中不断去磨练和提高。在不断被虐之后,我们的沟通能力、思考能力、统筹协调能力都会不断的提高。

相信哪天你也可以和诸葛先生一样,舌战群雄,想想就觉得自己牛逼的不要不要的。

赞(0)
未经允许不得转载:jack361博客 » 产品经理如何做好需求评审?

如果你爱我或恨我,请↓

联系我