答案是：肯定必要，而且很重要
前言
写这篇文章事因是因为最近在公司对接一个产品需求，我发现这个需求没有prd文档，wiki需求链接里只放了一个原型压缩包，仅此而已；而且产品的做法是不开需求评审会，分别单独跟每个人讲具体功能点。
我对这点很不理解，于是就跟产品进行了一番交谈；
产品说的问题大致有3点：
1、之前也开需求评审会，但意义不大，因为大家都不重视，开完会还得再单独讲一遍。
2、大家在需求评审会上一讨论技术问题就没完没了，要开好几个小时都开不完。
3、很难拉到业务负责人和产品线老大，我有些事儿也定不了。
听到他说到这些问题；我的理解：
1、需求评审的意义和目的他没有明确。
2、作为会议的发起者会议的内容和时间没有把控好。
3、正常的需求评审的参会人员没有搞清楚。
下面就几点展开说明我所理解的需求评审会：
需求评审的意义、PRD文档、需求评审前、需求评审中、需求评审后
一、需求评审的意义
传达产品理念
需求评审是产品向项目成员传达我们这个项目要做什么？为什么而做？要达到什么样的目标？的一个会议，目的是让项目成员对于要做的项目基于对现在业务的理解，对与要做的事情达成一致的目标，对项目更有认同感，对于项目成员来说对于这个项目也就更具有参与感，是需求达成共识和价值认同的一个必要环节。
完善需求
另外一点需求评审也是一个完善需求，让需求更靠谱的一个过程，产品经理的目的是解决业务和用户的问题，但提出的方法站在技术和交互甚至页面展示上来说有可能不是最优方案。在大家的讨论和建议中，有可能会让需求更正确、也更完善。大大减少了做无用功的概率。
建立成员的责任感
有的产品经理说我单独找项目里的成员单独说具体功能怎么做就行了，不一定要开需求评审会，这里有一个点是说直接找单个人去沟通具体的功能，那么这是直接去让项目成员去执行，也就是越过评审环节，产品的潜台词也就是说“我的需求都是对的，你去执行就行了”，我想每个人不想只是一个事情的执行者而不是参与者吧。这样会导致有可能每个人对这件事情的意义及结果都不会在意，因为“我只是执行，需求是产品决定的“这样的想法。
当产品经理对要做的事情足够重视、对每个项目成员足够重视、对每个人的建议和反馈都会认真对待的时候。相应每个项目成员也就会认真对待项目，也就有了要担负起责任的认知。
二、PRD文档
PRD文档是产品经理与项目成员沟通前一个书面形式的文件载体。
它至少包括三个部分：变更日志、需求描述、功能设计
三、需求评审前
明确需求
这个阶段也就是确定做什么，要解决什么问题的阶段。
如果是toC的产品，需求评审前可能需要做大量的用户调研、竞品分析看后台用户的反馈、数据分析等等。如果是toB的需求除了做这些之外，更重要的可能是业务主导。就像开头前言里产品说的他需要业务方参与需求评审，但跟业务方讨论需求的会议是在需求评审前，如果还需要业务方参与，那说明需求还没确定，也就是还没确定做什么、怎么做的问题；跟业务方开的会应该叫需求讨论会，是在前期要单独跟业务方讨论确认的。
技术沟通
当涉及到数据来源或技术逻辑模块的时候，需要提问跟相关技术人员沟通确认，避免想做的功能或数据技术底层逻辑目前根本不支持，那就需要更大的实现成本，这时候就需要考虑是否有相应的替代。
PRD的撰写
就像上面说的PRD文档是产品经理与项目成员沟通前一个书面形式的文件载体。是把项目背景、需求目标、业务流程、任务流程、页面功能以一种文字+图形的形式完整的呈现出来。在需求评审前把PRD文档先发出来让大家对需有有个大概了解。项目成员根据PRD基于对项目背景和业务流程的了解对要做的需求从各个方面做一个心理评估，可能包括很多疑问及不确定定，那么就带着这些疑问进入到接下来的需求评审时待产品的解答。
四、需求评审中
前面也说了需求评审其实是已经确定了要做什么的阶段，并且方案已经以书面的形式呈现出来，这时候就召集相关项目成员进入需求评审阶段（有些大公司是有一个立项的环节，在需求评审之前，主要是协调好项目成员及跟大家简要说明要做的事情）
参会人员
主要为项目成员，主要包括项目经理、产品经理、设计（UI/UE）、前端、后端、测试等；业务线Boss选择性参加，但不是必须，因为Boss的时间一般都不太好协调，产品经理应该提前找时间和其确认。因为Boss一般也只关心产品目标和方向上面。
会议内容
会议尽量控制在1个小时之内，因为人集中精力的时间有限，时间长了容易走神，低效又浪费时间；前言里产品说到需求评审一开可能就要好几个小时或者半天，那只能说是需求评审会的主旨和内容没有明确。
评审会内容大致包括：1、PRD的宣讲（项目背景、需求目标、业务流程、任务流程、页面功能）；2、大家针对需求合理性相关的疑问及建议；3、未确定的问题明确责任人和具体反馈时间
避免的问题：1、避免陷入细节的讨论，例如按钮能不能那样布局？这个字会不会有点小？页面的具体交互和布局是需要交互设计师和UI/视觉设计师去考虑的问题，还是那句话专业的事儿就交给专业的人去做吧。2、避免在会议上讨论技术的实现方式及数据接口问题，这些技术问题应该技术人员单独找时间开一个技术方案的会议来沟通，不应在需求评审会上深入讨论。
五、需求评审后
会后沟通
评审会议结束后，针对大家会议上的问题或建议，涉及需要确认或需要详细讨论的应找相关负责人单独沟通。
另外涉及到需求细节的部分，项目成员在会后消化中有不理解或疑惑的地方也应随时和产品沟通确认，确保自己是在理解需求和业务的基础上参与项目。
更新文档
涉及需求需要调整或完善的部分，在答案明确后产品经理应及时整理完善PRD文档填写更新日志信息，并知会项目成员，确保项目成员信息的一致性。
总结
需求评审对于一个项目来说无需置疑是很重要的，是一个项目成员建立使命感和责任感的开始，也是建立共同产品认知的一个重要环节，一个团队就应该朝着同一个方向努力前进。方向一致、目标一致，可能才会得到更好的结果。
