需求评审会议时你还在被怼吗？？？

需求评审会议在产品经理的工作中可谓是密不可分，时时刻刻都在我们的工作中，而需求评审会议呢，有需要其他同事来一起进行探讨，如果产品需求文档做的不够好，那需求评审会议是会很难受的。

一、什么是需求评审会议

对于产品经理而言：需求评审产品经理的噩梦，大概率会被怼的很惨，而且时间很长。

对于程序员而言：对产品进行全方位的论证和推敲的过程。，程序员以及团队各成员需要了解产品的具体实现方法，有问题的地方需要进行更改。

完整，清晰传递产品目标，产品功能，并获得团队认同，会后实施。

二、内容

产品目标：讲明白，我们要做什么，为什么要做，能解决什么问题。

产品功能：具体做什么事，涉及到哪些方面，前端、后台、UI、UE、运营、测试，一个环节不可用少

会后实施：解决会上提出的问题，输出会议纪要，如果有项目经理则要配合输出计划，否则自己输出。

三、需求评审的方法

1、会议前：记住发邮件！！！任何形式的沟通，都必须以邮件来确认。（互联网公司必须要有理有据）

邮件的内容

①项目背景介绍，如果是新项目，要输出BRD、和市场调研分析、用户画像，老项目要输出数据分析、用户反馈，竞品状况，也就是需求来源。新项目大家需要知道是否有发展潜力、是否有做的必要。老的产品需要知道竞品的状况与用户体验反馈，从而对产品进行优化。

②输出项目目标，本次项目，你要达到什么目的，评估标准。

③输出项目文档，BRD/MRD、PRD、流程图、结构图、原型图、以及与之相关的所有文档。

④邀请人员：测试、开发（前端、后端、客户端、运维）、UI、UE、运营、以及Boss。所有的团队成员。

2、会议中：

①寒暄两句，调动大家的情绪，例如：这将是一个又臭又长的会，请大家自备方便面呢。

②进入正题：项目背景→本次迭代目标→产品结构图讲解→流程图讲解→需求清单讲解→原型图讲解→PRD文档讲解。以上是一个大概的讲解时候的流程。

③提问环节：答疑，记录，修改。在这个过程中要注意记录，而且记录的内容的意思需要与表述者的表达的意思相同，记录过程中很容易会把意思改变，这是比较重要的一点。

3、会议后：

①写邮件，首先把会议上的内容全部发出来，达成一致的有哪些，修改的有哪些，疑问的有哪些。一一列举出来，并输出反馈时间表。

②跟进各个角色：也就是进行项目管理，如果没有则自己处理。把任务拆分。输出时间节点完成日期落实到责任人，以及后续评审日期。以便工作的顺利进行，不要事情遗漏、拖拉进度。

③配合测试输出用例，配合运营输出运营需求，配合UI输出UI需求，配合UE输出UE需求，配合开发输出功能列表。总之就是配合团队成员输出大家的需求，进行整合。

④之后就是从UE、UI、开发、测试、上线全环节跟进，并整理需求。

总之一句话，需求评审会议首先要把产品需求文档做好、做清楚，所有的情况都要考虑全面，不要有遗漏，不然会被怼，整个贵哦城中，需要逻辑清楚，把整个产品梳理清楚。