文章大纲

一、 什么是产品评审会
二、 产品评审会类型
三、产品评审会注意点
四、相关模板下载
五、参考文章

 

一、 什么是产品评审会

  需求评审通常是由产品经理主持,通过讲解产品需求文档,让相关人员了解具体需求,并提出疑问,进行沟通的过程。统一大家对产品需求的理解,为后续“如何做”打好基础。从整个产品的分析、设计和开发的流程来看,需求评审是一个非常重要的环节,它串起了前期的需求收集、需求分析和后期的需求实施和产品落地。

二、 产品评审会类型

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

五、参考文章

    1. https://baijiahao.baidu.com/s?id=1594280211504440585&wfr=spider&for=pc
    2. https://www.sohu.com/a/146679168_114819
03-22 05:35