时间: 2021-07-30 11:31:49 人气: 13 评论: 0
在需求评审中被diss几乎是每个产品经理都**遇到的问题,要想在评审的时候被diss得越来越少,产品经理必须做好充分的提前准备工作。
需求评审对于产品经理可以说是家常便饭,这是很多产品经理都非常害怕去做的一个**议。因为很多时候产品经理在需求评审**上,是一个被集体攻击的一个的对象,处在一个非常弱势的位置。
我自己也组织过或参加过不少需求评审**,我觉得出现这种情况的最主要原因就是需求评审做得不好,做得不好就**被质疑,然后连带着你的专业能力也**被质疑。
所以做好需求评审对于一个产品经理的专业程度以及参与评审的人的印象是非常重要的,下面我想分享一下作为产品经理,应该怎么样去组织一场成功的需求评审。
总的来说,需求评审就是一个统一目标,明确需求,确定实现过程的**议。在需求**议上,产品经理需要跟大家明确需要解决的痛点问题,有哪些功能以及对应的计划,然后大家在**议上挑刺,讨论,甚至是撕逼,最终全体成员达成一致意见后开始开干。所以,通常一些项目需求都是要经过几次评审**才能完成的。
在需求评审中,选择合适的参**人其实很重要,我们绝不能为了让所有人都有参与感而把能想到的人都邀请了,但是其实很多人去参加完了整个**议发现自己并没有对应任务。
主要邀请的参**人是根据我们在输出需求方案的过程中是否涉及到相关任务决定的,一般一场需求评审**都**邀请以上的人员参加,再根据项目需要还有可能需要邀请前端,UI,UE等。
需求评审其实就是对PRD的评审,而PRD的文档规格其实就是你在做需求评审时的关键流程,一般我**遵从以下的流程:
(1)需求背景
在需求评审开始的时候,我们首先一定是要介绍需求背景,说明业务现状及存在的问题,明确本次评审的新功能/产品需求解决的问题是什么,让团队成员们都知道我们为什么要做这个产品。
只有让大家对产品需要解决的用户痛点问题保持一致,我们才能开始后续具体功能的评审,也能避免往后更多的争论不休。
(2)用户与需求
根据“用户-场景-需求”的逻辑,阐述此产品主要面对的用户/用户角色,并且描述清楚不同用户对应的职责或者使用场景,通过场景说明列举需求。
因为不同的使用场景功能往往都是大有不同的,描述清楚场景才能让参与评审的人更深入地理解用户的需求。
(3)需求收益
接下来,我们需要跟大家说明一下需求能给公司/用户带来的主要收益,让大家清楚知道这个需求的价值是什么。
(4)产品功能模块
这个部分是需求评审中的重中之重,是我们重点需要评审的内容,涉及到功能、逻辑、原型交互等内容,一般在评审中,我**这样去处理:
(5)衡量需求成功的数据指标
在介绍完我们所有的功能模块后,我们需要告诉大家我们这个需求的成功指标以及相关的计算公式,取值逻辑,数据取值是否需要重新埋点
(6)需要配合部门的哪些支持
如果需求是需要配合部门的支持的,我们应该把需要支持的清单列举一下并说明具体需要什么样的支持,当然这些在产品功能模块评审的时候也是要具体说明的,这里只是我们做的一个总结
(7)预计上线时间
一般参与评审的需求业务/项目都**要求一个预计上线的时间,我们需要组织开发,测试预估一下需求工时。然后,跟据预估的工时判断一下能否在预计上线的时间准时上线。如果工时比我们计划的要长,那这个就是一个风险,我们就需要跟项目经理一起商量风险应对方案了。
(8)注意点
1)一定要做好**议计划,管理好开**时间,不然你的需求评审**效率可能**非常低;
2)不要一上来就讲功能,这**让你在整个评审**的过程中不停地去解答参**人员的基础问题,浪费评审时间;
3)抓大放小,不要在细节上面过多讨论,如果是没有办法统一大家的决定的,可以统一一下大家做决定的思考方式;
4)讲需求的时候要注意节奏跟条理性,不能只是一个走马观花的评审流程,在评审的过程中,产品更不能乱;
5)因为参与评审的人都有不同的关注点,那评审的过程肯定是**存在争论点的,一些重要的争论点一定要记录下来。
1)给所有的参**人员发一份**议纪要,纪要内容包括:
2)发出更新后的需求文档,并且更新到公司内部系统的产品资源中
3)如果需求文档需要修改的地方比较多,建议再约一次需求评审**,重点评审修改后部分
需求评审**只是作为产品的一个日常的工作,我们常说“凡事预则立,不预则废”,在需求评审工作中,当你有一套自己的方法,当你经历了一次又一次的需求评审后,你**发现它锻炼了你的组织能力、表达能力、逻辑能力、说明力以及执行力等等。
所以,别慌,把控好需求评审,让大家跟着你的节奏走!
本文由 @Vita 原创发布于人人都是产品经理,未经作者许可,禁止转载。
题图来自Unsplash,基于CC0协议。