大概看到这个标题很多PM小伙伴情绪有些小波动，是的需求评审会听上去挺高大上，但对许多小伙伴来说简直就是噩梦，在行业内他还有个“优雅”的叫法“撕逼大会”，每个从会议室坚强走出来的小伙伴都有一部血泪史，废话不多说，今天我们来聊下如何能让自己昂首挺胸的从会议室走出来。
为什么要开需求评审会？
一、 让团队中所有人知道我们这个需求的背景和目的
无论什么职位都需要一个归属感，而不是一个接收任务和完成任务的工具，让团队中每个人都了解一件事情的来龙去脉更有利于这件事上的落实和达成共识。
二、评估设计、开发、测试的周期，便于做决策
我们做需求评审会时要带上前文说过的业务流程图、页面流程图、交互原型图，和团队的每个负责成员评估周期，如果评估结果时间超出预算时间，例如我们要配合运营在520当天上线一个活动，但以目前的人力无法按时上线，那么通过评估我们做出决策在当前情况下要和领导申请更多的资源。
三、让参与者明确工作内容和交付时间
这个就是在我们几次需求评审修订后最终定方案，团队中的每个人员都清楚接下来每个人的工作内容和需要阶段性的产出交付物。
怎么做需求评审会？
主要分三个阶段要做好对应的工作：评审会前、评审会中、和评审会结束后。
一、评审会前的准备工作
- 四份文档准备
四份文档包括：“需求文档”“业务流程图”“页面流程图”“交互原型图”，先检查自己这四份文档是否还存在问题，并与相关的人员提前确认文档，这里主要指研发人员，当然技术出身的产品经理就不用了，我曾和一些朋友聊过这件事情，有些公司跟技术经理确认的，这个看具体情况，确认的目的是为了提前扫清障碍，避免自己的文档中有大的逻辑问题和开发无法实现的功能导致会议无法进行下去，确认之后修改就可以把文档打包发给相关人员了。 - 提前预约时间
参与需求评审会的人一般有以下一些人：领导、设计、研发、测试、运营。一般评审会前2-3天发邀请，这里特别说下为什么一定要拉着领导，有时候做项目资源是不足的，比如缺人你自己和领导说领导可能不一定给批，拉着领导让领导有个数，后面争取资源比较容易些。
二、评审会时注意事项
- 逻辑清晰
这点还是需要锻炼的，首先要准备充足，有个大概的提纲第一点讲什么、第二点讲什么......之后没什么诀窍干多了就好了，哈哈 - 讲故事
这个就是功能用故事的方法去讲，让讲功能变的有趣点，比如某个用户在什么场景下有什么痛点我们这个功能可以解决这个问题，这样来叙述功能，不然你讲着讲着很起劲下面不是玩手机就是玩手机。 - 不要太抓细节
这个主要交互原型图出现的比较多，比如像某个按钮放在哪里不合适的问题，这个可以会后去完善不要花过多时间去讨论这样的问题，主要考虑大的问题。 - 做记录
敲黑板这里是重点，一定要找个同事帮你记录下来争论的点，因为自己要进行讲解所以要找个同事帮忙记录，这个一定要做，不然后面再去想或者找别人去讨论很麻烦。
三、评审会结束
- 发会议记录
评审会后要发会议记录和团队成员确认有争议的问题。 - 整理问题，出解决方案
评审会很少有一次过的，对于第一评审后的问题要整理并出新的解决方案，小的问题发出确认即可，大的问题还要约第二次评审，一般第二次评审就可以不用约领导了，毕竟领导也忙，哈哈。 - 重新整理需求文档，存档
对于要解决的问题需要在对应的文档上进行更新，如果方案确定要对所有的文档进行存档备案。 - 排期
最后一次评审会确定就要排期，这个可以跟相关部门的负责人沟通，比如技术经理，需要多久时间什么时候可以上线。
对于要不要写这篇文章我也想了很久，大家应该都经历过需求评审会议，这里面没什么技术含量，但是如果需求评审会做的好对于产品经理树立威信很有帮助，需求评审会各种被挑问题，大家就会对你的能力质疑，做的好的话后面的沟通都会很顺利，大家也会很信任你，提升的窍门吗？注意细节多练习，哈哈我还是比较信奉那句话的通往成功最大的捷径就是踏实走好每一步。
