文章大纲
一、 什么是产品评审会
二、 产品评审会类型
三、产品评审会注意点
四、相关模板下载
五、参考文章
一、 什么是产品评审会
需求评审通常是由产品经理主持，通过讲解产品需求文档，让相关人员了解具体需求，并提出疑问，进行沟通的过程。统一大家对产品需求的理解，为后续“如何做”打好基础。从整个产品的分析、设计和开发的流程来看，需求评审是一个非常重要的环节，它串起了前期的需求收集、需求分析和后期的需求实施和产品落地。
二、 产品评审会类型
1. 产品内部评审
时间点
立项后（基本确定业务流程、功能点、核心功能的原型线框图等）
目的
明确功能优先级，评审业务流程设计的合理性
参会方
产品、需求方、相关运营、项目经理、老板
评审内容
包括功能表、流程图、原型初稿（线框图）
2. 技术评审
时间点
产品内部确定方案，输出全量功能的原型后
目的
开发同学了解需求，评估技术可行性、提前设计架构；
参会方
产品、测试组长、开发组长、项目经理
评审内容
功能列表、相关流程图、原型&需求文档
3. UI评审
时间点
开发确认需求可落地，UI同事同步就可以进行需求评审
目的
了解需求和业务流程，理清前端页面，确定工期；
参会方
产品、UI、项目经理
评审内容
UI表（前端页面list）、原型
4. 开发终审
时间点
需求详细文档输出后
目的
开发测试详细了解需求、UI稿评审、评估开发量和排期
参会方
产品、参与开发的全部人员、参与测试的全部人员、UI、项目经理
评审内容
功能列表、相关流程图、原型&需求文档详版、UI稿
三、产品评审会注意点
1. 了解各方关注点
在召开会议前，内心要清楚的知道本次会议参与的人员类型，他们各自关注的重点在哪里
2. 需求评审时常发生的情况
（1）与会人员对需求的目标不明确，易发散思维，最终偏离方向
（2）对某个需求点相持不下，认为该需求不合理/开发周期长不划算，从而导致场面混乱，长时间僵持下去
（3）对技术方案探讨不定，对问题点无限引申
（4）遗漏评审时的待改动的需求点
2. 会议前的准备
在会议评审前1-2天，把确定好的会议时间、地点、所需要的资料通过邮箱发给会议相关人员，让大家先对产品评审有个大概的了解，具体资料可能包括产品原型图、流程图、产品功能列表、PRD、UI图等。
3. 会议中注意事项
（1）面对不同的角色，我们讲解的重点是不一样的，高层关注需求的目标性（目标、意义、价值），中层关注需求的功能范围（这个版本必须完成的任务）、实操人员关注需求的实现落地（更扣细节）；
（2）评审过程不可避免乏味，越往后越马虎，所以先讲重点模块，评审时间长时，建议隔时间段休息或分批次进行；
（3）评审过程中会遇到挑战，这就需要我们设计时，保证文档流程完整、逻辑完善、原型规则详尽，设计有理有据，能拿出数据支撑或竞品样例或合理的思路；
（4）会上遇到无法拍板的点，记录下来会后处理，不用过多纠缠；
（5）会议开始时，需要提前说明本次会议的内容范围、会议目的、会议所需结果；
4. 评审后的跟踪
（1）整理会议纪要内容，会议结束后，应当天总结处理会议上所有讨论的争议点，以及讨论的结果内容！
（2）是否需要进行调整。立马处理在会议上未能讨论解决的内容，应尽快确认 是否应该调整？调整的范围是多少？并且及时反馈告知处理结果。
（3）会议结束后， 是否需要再次召开会议，讨论内容，
（4）发送会议记录。会议结束后，当天内应及时通过正式渠道发布会议纪要。
四、相关模板下载
链接：https://pan.baidu.com/s/192CxA3jSVbmqbSyD1DE6zA
提取码：goez
