新媒易动态
NEWS CENTER
NEWS CENTER
2020-01-01
需求评审对于产品经理可以说是家常便饭，这是很多产品经理都非常害怕去做的一个会议。因为很多时候产品经理在需求评审会上，是一个被集体攻击的一个的对象，处在一个非常弱势的位置。
我自己也组织过或参加过不少需求评审会，我觉得出现这种情况的最主要原因就是需求评审做得不好，做得不好就会被质疑，然后连带着你的专业能力也会被质疑。
所以做好需求评审对于一个产品经理的专业程度以及参与评审的人的印象是非常重要的，下面我想分享一下作为产品经理，应该怎么样去组织一场成功的需求评审。
总的来说，需求评审就是一个统一目标，明确需求，确定实现过程的会议。在需求会议上，产品经理需要跟大家明确需要解决的痛点问题，有哪些功能以及对应的计划，然后大家在会议上挑刺，讨论，甚至是撕逼，最终全体成员达成一致意见后开始开干。所以，通常一些项目需求都是要经过几次评审会才能完成的。
在需求评审中，选择合适的参会人其实很重要，我们绝不能为了让所有人都有参与感而把能想到的人都邀请了，但是其实很多人去参加完了整个会议发现自己并没有对应任务。
主要邀请的参会人是根据我们在输出需求方案的过程中是否涉及到相关任务决定的，一般一场需求评审会都会邀请以上的人员参加，再根据项目需要还有可能需要邀请前端，UI，UE等。
需求评审其实就是对PRD的评审，而PRD的文档规格其实就是你在做需求评审时的关键流程，一般我会遵从以下的流程：
（1）需求背景
在需求评审开始的时候，我们首先一定是要介绍需求背景，说明业务现状及存在的问题，明确本次评审的新功能/产品需求解决的问题是什么，让团队成员们都知道我们为什么要做这个产品。
只有让大家对产品需要解决的用户痛点问题保持一致，我们才能开始后续具体功能的评审，也能避免往后更多的争论不休。
（2）用户与需求
根据“用户-场景-需求”的逻辑，阐述此产品主要面对的用户/用户角色，并且描述清楚不同用户对应的职责或者使用场景，通过场景说明列举需求。
因为不同的使用场景功能往往都是大有不同的，描述清楚场景才能让参与评审的人更深入地理解用户的需求。
（3）需求收益
接下来，我们需要跟大家说明一下需求能给公司/用户带来的主要收益，让大家清楚知道这个需求的价值是什么。
（4）产品功能模块
这个部分是需求评审中的重中之重，是我们重点需要评审的内容，涉及到功能、逻辑、原型交互等内容，一般在评审中，我会这样去处理：
（5）衡量需求成功的数据指标
在介绍完我们所有的功能模块后，我们需要告诉大家我们这个需求的成功指标以及相关的计算公式，取值逻辑，数据取值是否需要重新埋点
（6）需要配合部门的哪些支持
如果需求是需要配合部门的支持的，我们应该把需要支持的清单列举一下并说明具体需要什么样的支持，当然这些在产品功能模块评审的时候也是要具体说明的，这里只是我们做的一个总结
（7）预计上线时间
一般参与评审的需求业务/项目都会要求一个预计上线的时间，我们需要组织开发，测试预估一下需求工时。然后，跟据预估的工时判断一下能否在预计上线的时间准时上线。如果工时比我们计划的要长，那这个就是一个风险，我们就需要跟项目经理一起商量风险应对方案了。
（8）注意点