最近正忙着找公司，面试几家公司都问到这样的一个问题，你做产品的时间还不长，怎么做好一次需求评审，需求评审的指标是什么？这次小编就根据自己在需求评审方面的经验，来谈谈产品新人如何做好一次“需求评审”。
作为产品经理，大家都或多或少参加过需求评审，也组织过需求评审。回想自己组织第一次需求评审时，由于紧张，竟然忘记自己之前做的准备了，于是直接打开原型图，对着它巴拉巴拉讲了一大通。结果也就可想而知了。
所以说作为产品经理必须要有强大的抗压能力和沟通能力，这也是产品经理岗位的最基本能力之一。就如我领导经常跟我说的一句话：“你是产品，你得大胆的说啊，说错了又什么关系，不就是被怼吗？”。
需求评审是产品设计开发的一个重要环节，贯穿了产品需求和产品实施的全过程，对于产品最终是否能按时落地起到关键的作用。所以需求评审的重要性就不言而喻，小编将结合自己的实际经历，介绍一些产品新人应该怎么做好“需求评审”。
一、需求评审前
充分理解自己负责的需求，不要一上来就编写PRD和制作原型图，很多时候实际情况会跟你所理解的有所偏差的。（小编主要是负责的B端产品，每次从需求方拿到需求时，小编会先拉项目负责人和技术负责人进行小组讨论，再去进行业务调研与，梳理出功能结构和业务逻辑，只有完成这些步骤才会去编写PRD和demo。）
1、明确会议目标
明确这次会议的目的与目标，希望通过这次会议解决什么问题。这样在需求评审会议不会出现偏差，即使偏离主题，产品经理也能即使拉回来。
2、提前约好时间
在组织需求评审会议时，产品经理需要先明确需要哪些人员来参加这次评审，比如项目经理、研发人员、测试人员、业务方、设计师等。提前跟他们约好需求评审会议的时间，不是每个人都是刚好在某一时间有空的。小编曾经约业务方参加需求评审，约了好几次才约到，甲方就是这么牛。即使临时有人有事没能参加会议，也要将会议纪要和评审结果发给缺席人员，再与其单独进行沟通，确保双方的理解时一致的。
3、提前沟通
提前把相关资料发给评审人员，很多时候研发人员不会去看什么产品需求文档的，（小编有一次将PRD发给研发人员，最后发现只有2个工程师看了），然后与评审人员逐一进行沟通，让对方在会议开始之前就对相关内容有所了解，同时也能提前了解相关人员的关注点在哪里。便于产品经理对这些问题做好准备。这样在评审时会更具有针对性、条理性。
二、需求评审会议中
在会议开始是，不要一上来就打开原型图讲具体的功能和设计方案，而是要让评审人员明白项目背景和需求来源，产品是用来解决什么样的问题，让大家对产品有一个初步的认识。
1、牢记会议的目标
在做需求评审时，产品经理被怼是一件很平常的事，产品经理需要对这次的评审会议要有方向性和目标性，需要通过这场会议达成什么样的目标以及要解决的问题都要铭记于心。
“交互设计师：你这样设计是不合理的，步骤太繁琐了。”
“在xxxx情况下，会出现另外一个情况，这个你没有考虑到”
“这样不是更好解决问题吗？”
“这个动能有点多余，添加另外一个功能不是更好吗？”
“......”
产品经理只要讲清楚，接下来我们将要做XXX这几条需求，每个需求大概实现的是一个什么功能即可，避免陷在业务细节中，偏离会议的主旨。小编有一次是讨论业务功能方案，可是讨论到最后，既然成了交互UI具体该怎么实现了。。
在讲解具体产品需求时，不要陷入自己的逻辑不能自拔，而是要把参与会议的人员当成用户，站在对方的角度，尽量讲的详细具体。
2、明确责任范围
在需求评审会议时，产品经理需要划分责任范围。涉及到需求、设计、实现，需要你确定的前提，你必须得让每个人清楚的了解。你得让他人清楚你在这项工作中，扮演什么样的角色。
3、把控时间节奏
在需求评审时很容易会对某个需求、某个方案僵持不下，就会陷入需求讨论期、导致谈论的时间过长。时间一长就会分散评审人员的精力，评审的效果自然就不会很好了。所以产品经理需要严格把控时间进行，主动停止一些长时间没有达成一致的方案的讨论，等有有效的解决方案时再进行讨论，同时也要注意与相关人员进行沟通。
三、需求评审会议后
在需求评审会议，整理会议纪要，对遗留下来的问题，给出有效的解决方案，并抄送给参与评审人员。如有需求可以再进行一次需求评审。
追排期，将修改的文档发给评审人员之后，需要与相关人员进行确认，确认双方的理解一致，并敲定开发周期与时间节点。
总结
需求评审被怼是产品经理多多少少都会遇到的问题，这也是锻炼产品经理抗压的一种方式，不要轻易就失去自己的平常心，被怼证明自己考虑还不够周到，能力还能提升。
