想起前段时间组织的一次产品需求评审会，那是我第一次完全由我组织的产品需求评审会。从入行时的参与者，然后到协助组织者，最后到整个会议的组织者，中间经过的时间虽然说不长，但是体会颇多。
在亲自组织需求评审会之前，因为之前参与过的需求评审会基本上boss组织的，所以对产品需求评审会的印象并没有太深，也没那么正式，与大神们分享的需求评审会有所不同。而这次有幸被委托重任，让我再次全权负责一个产品的从0到1，所以需求评审会也是有我来负责。需求评审会，整个过程从理论到实践，让我更加懂得其意义和重要性。
需求评审的4个问题
在此之前，我们需要了解一下需求评审会的4个问题：
何为需求评审会？
需求评审会相当于对问题的解决方案的可行性分析，是产品正式进行开发前的重要一环，是产品相关的人员在会议上对产品需求进行分析和审查，论证需求是否可实现、可验证、可测试，并最终确定一个目标，号召大家往一个产品目标进发。-
为什么要进行需求评审会？
进行需求评审会有以下原因：- 为了让与会人员了解产品背景、产品业务、产品需求以及产品目标等。
- 让开发工程师对产品方案有具体的了解，以确保后续开发可以高效的进行。
- 让与会人员明确自己在整个方案所处的位置、职责，然后对自身在项目中所需要的工作有个心理预期。
- 评估产品方案的技术实现难度及实现周期，对产品体验进行权衡与评估。
- 获取项目所需要的资源等。
需求评审会的目标用户是谁？
参加需求评审会的常客有研发人员、测试人员、UI/UE/UX、运营人员、测试人员、市场人员和产品经理等等。什么时候举行需求评审会？
需求评审会一般会在正式开发前的3~5天，因为一般需求评审会是很难一次把需求完全确定好，在需求评审会中发现的问题，需要产品经理需要在会议之后重新进行优化和总结，然后再与相关人员讨论，必要时可能需要二次评审，所以要预留会后优化产品方案的时间。
会议前的准备
为了确保会议能够顺利的进行，所以在开会之前，我对上面的问题已经有了深刻的了解和研究，再加上之前对产品需求做了比较详细的分析以及对行业、竞品的分析，把会议所需要的资料准备充足，剩下的就是对整个会议流程进行规划，以免开会时演讲缺乏逻辑那就尴尬了。把以前在产品经理社区里看过于需求评审相关的文章都复习了一遍，然后又根据实际情况，把会议的流程及模块用脑图先总结一般，如下图
同时为了保证开会的时候大体按流程走，便根据流程制作了一个简单的PPT，PPT的内容不多，只是对模块标题进行展示，保证会议的主线按正确的方向进行下去。同时需要把握一些演讲的技巧，刚好那段时间看了《产品经理那些事儿》，其中讲到一些演讲技巧，在此时就发挥作用了。其中的技巧有：开会前要与与会人员聊聊以增加自己会议中的筹码，然后开会时要站着演讲以增加自己对场面的控制力，还有演讲时最好加点故事案例之类的来进行说明，观众都是喜欢听故事的....
当把这些都印在脑子里之后，会议所需要的准备做好了。
会议前通知
记得在会议的前一天，我会把会议前所需要的资料先发给与会人员，所需要的资料有：
- 产品原型图
- 流程图
- 产品功能列表
- PRD
把这些资料先通过邮箱发给与会人员主要是让大家先对产品有个大概的了解，不会因为在当天的会议上因信息量太多而导致难以发现问题。当我把资料发出去之后，一个开发人员了解后问了我一个问题：“这个产品主要是做什么的，我一点都不了解”，这个问题让我迫切地明白需求评审会的重要性。
会议开始
会议是在周五下午3点中举行的，大家也刚从午休中缓过来，精神状态比较好。在会议临开始前的15分钟，我当面提醒了与会人员15分钟后进行需求评审会，以确保大家都能准时参加。然后我就提前到会议室准备了，再一次把整个流程在脑海里过一遍。
15分钟后，大家都陆续上来了，因为在会议室，大家都略显严肃，气氛有点尴尬，与会人员恰好有两位新同事，我便趁大家都就坐了的时候问大家对新同事都认识了吗，然后大家就顺势的做了自我介绍，我从中插些话开开玩笑，大家的表情没那么严肃了，气氛也缓和了很多。
熄灯，打开投影，会议正式开始...
业务介绍
因为这次与会人员大部分都是开发人员，外加两个设计师，一般情况下对公司的主流业务并不是特别熟悉，所以会议开始的第一部分，我向大家用10分钟左右的时间介绍了一下公司的主流业务。
会议流程
公司的主流任务介绍完毕之后，就向大家陈述一下会议的整个流程安排，让大家对整个会议安排有个心理预期。
- 会议目的
- 产品规划
- 开发时间估算
- 会议总结
会议目的
这是会议的第一部分，会议的目的主要有以下几个：
- 阐述产品开发目的
- 确定最终需求和功能
- 确定功能排期
- 确定项目的开发周期
先通过说明会议的目的，让与会人员心里面对会议有个明确的方向。
产品规划
产品开发背景与目的
对于产品规划的第一模块，就是产品开发背景的描述，主要是讲当前公司的发展状况、为什么需要开发这款产品以及这款产品给公司能带来什么价值，给市场、用户带来什么价值。
产品所属行业行情
这部分内容，前期的工作十分重要。行业行情实际上也就是行业分析报告。首先我们需要确定目标行业、市场，然后通过第三方调研平台的行业报告、竞品分析等手段确定市场规划、市场发展趋势，然后确定市场的竞争格局、市场的痛点来判断我们是否还有机会进入该市场，并且在什么时机进入该市场。这里通过详细的数据说明分析的准确性，增加内容的说服力。
产品规划
在这个模块中，我们需要向与会人员阐明产品以下几点：
- 产品定位
- 目标用户
- 使用场景
- 商业模式
此时观察大家，感觉大家不怎么感兴趣。恩，这里的与会人员的性质很明确，都是开发人员...虽然说这些不是他们工作的重点，但是了解这些可以加深对业务逻辑的理解。
需求说明
到这里，开始进入会议的主要内容了，此时会议室还是挺安静的，但这是需求评审会开始“热闹”起来的地方了。这里会把需求列表和功能列表展示出来，通过业务和需求背景，按照需求列表的顺序，先想大家介绍每个需求的背景和用户痛点，然后在对应起功能列表里的功能项。我小心翼翼地把需求一个个过完，但是台下并没有太多的声音。什么鬼，与我印象中的“撕逼”大战不一样！当我把需求列表都讲完了之后，台下的声音开始多了起来，大家都有一两个问题，基本上都是“为什么做这个需求”比较多，不过因为我在此之前对这种问题已经做好的充分的准备，所以大部分我都能即时回答，只有极少部分没有考虑到的就记录下来，会后再讨论。不过讨论的情况并没有想象中激烈，难道是之前是自己想象力修炼技能满格了？并不是，只是事后才发觉，因为与会人员基本上是开发人员，对需求背后的含义不需要深度的理解，他们只是把不懂的地方弄清楚就够了，所以我的回答都能满足他们的期望，所以这部分并没有带来太多的争论。
主要功能线说明
回想起来，这部分才是这个会议的高潮部分。
在前面介绍完产品的背景目的以及需求之后，接下来就是通过交互原型图来展示功能。我是通过产品的主要功能以及模拟用户使用的流程进行功能的介绍与描述。在展示交互原型的时候，屏幕右侧还有每个页面的备注，对一些重要的功能、字段以及交互方式进行详细说明。我们产品有4个主要业务流程线，我在介绍的每一个流程时，台下的“观众”都异常活跃，“这个模块的字段是否有明确的归类？”、“这个页面怎么进入，使用怎样的交互形式？”、“你这个页面设计的请求方式太多，实际实现效果不太好”....这些问题的蜂拥而上，此时我思绪有点乱了，因为问题一下子上来，也开始有点“战争”的感觉了。我先让大家安静一下，然后让有问题的与会人员一个个发表问题，如果可以当场解答的，便会表述清楚，如果难度较大的或者表述内容较多的，则会后再详细说明。
通过几个回合的“战斗”之后，发现的问题也不少，但是在预料范围之内。
功能优先级
上述流程过完之后，我会把之前就安排好了功能优先级展示给大家看，然后想大家阐述自己这样排列优先级的原因，然后咨询大家的意见再权衡怎么优化优先级列表。
开发时间预估
关于开发时间的预估，对于一些有经验的开发人员来说，他们给出的时间相对较准确，经验尚浅的则需要项目经理参与辅助预估。因为这里展示的功能较多，开发们一时之间也没办法预估，所以我提出了一个方案，就是开发小组会后针对每个功能、自己所属的模块进行功能开发时间的精细化预估，然后在填写到云表格中，然后由我这边再结合实际情况给出一个合理的开发周期。
会议总结
经过两小时的讨论和演讲，大家对产品已经有了明确的认识，需求也十分的明确，然后我便汇总整个会议讨论和明确的需求、结果向大家再次阐述一遍，再次明确产品目标，并号召大家往目标奋斗。
会后把问题的解决方案和会议的最终结果通过邮件的方式发送给大家，大家确定没有问题了，这样整个项目的需求就明确了。
总结
这是第一次完完全全有自己组织并主持的一个需求评审会，虽然有一定工作量，但是不可否认的是有一定的收获，对自身的组织能力、前期需求的分析能力、演讲能力与执行能力都有一定的提升。不过这次举办的需求评审会与大公司的有着明显的差异，就是我们这次会议是已经明确了团队成员，不需要去和上级领导争取资源，如果需要和争取资源的话，估计会议就没那么顺利了。
需求评审会前一定要做好准备工作，所需材料都准备完善，这样才能让会议顺利进行。
