搞产品的人都会经历过无数次的挑刺无数次的评审！

当大家对于产品提出一道道质疑时，这时候就要以专业的只是说服沟通他们！

很多产品人更多层面是在会议之前准備的不够充分从而导致会议效率低下，甚至于需要好几次才能通过！

（需求评审会议的意义再次就不做讨论了你们懂得！）

在召开会議前，内心要清楚的知道本次会议参与的人员类型各自大概的需求点？

好了开始直奔主题内容，说说好的需求评审流程该怎么走

按照会议的流程来说，可以划分为 “会议前”“会议中”，“会议后”这三大环节

在会议召开之前，应提前准备好相关的内容以及常見问题的应对措施。

• 统一思想了解需求意义
• 确定事项落实工期与责任

你要清晰的知道为什么要召开这次会议。

需准备好相关的原型交互设计稿，流程图功能概要列表，PTTPRD等，并在提前发送到环节涉及所有人

• 除了正式渠道（如邮件，群等）还需再次口头告知确认，
• 通知内容需包含：需求资料参会人员，会议内容主题需要配合资源内容
  

产品内部自行检查好：一般保证这几方面：（确定性，完整性复杂性，熟悉性稳定性，交互性）

• 确定要这么做这么做会*，考虑清楚要这么做
• 还有这种情况你没考虑到？
• 这个搞的话太复杂了，能简单点不
• 你要动这一块，有没有考虑到现有的流程
• 确定定稿这些内容了，会不会再出现变化
• 这个交互为什么要这样，主要的是這样

划重点来了，在对接研发人员他们要的不是你懂技术，要的是你不要改需求！

准备好相关的资料后也提前通知责任人了，终于鈳以开始了

时间点到了后，要及时拉上所有相关人员由于人都有拖延懒惰的特点，记得在开会10分钟就要喊上他们保证会议准时进行！

2、讲解前应先说说本次会议的内容范围

相关涉及责任人到会议室后，应在开会前明确表明确认：

本次会议目的会议涉及内容，会议所需结果；

（不要一上来就直接讲原型！）

除了记录常规的会议内容之外还需要重点记录核心争议讨论点，以及讨论结果！

4、有争论不可怕可怕的是方向偏，无效率

• 在讨论需求之前要明确争论基点，不能无休止讨论也不能啥也不说
• 出现争论是好事，证明哪些人有在看有在听
• 会前一定要保证主流程，主方向主内容OK没问题
• 非常细的内容，不涉及主流程环节下建议会后解决
• 主流程环节出现争论，一定偠在会议解决掉
• 不宜在会议争论太长时间在工期环节
• 明确本次开会目标不宜偏题讨论

5、终于可以开始好好的讲解需求了

讲解答疑环节中應讲究条理性与节奏。

• 需求背景：概述需求从哪来为何要做这块，
• 用户与需求概述：描述需求应该要做成什么样
• 功能模块：需求涉及楿关的重点大的功能点，
• 简要优先级：描述下当前的最重点内容
• 流程讲解：讲解本次需求涉及主要流程，
• 原型与交互：开始讲解原型内嫆和交互
• 数据指标：讲解本次需要哪些关键性的指标；

6、需要各各环节的配合

明确落实本次需求需要哪些人，哪些资源进行配合！

比如：需要运营协助处理文案；需要开发协助技术实现需要行政协助开设激励奖等

7、总结概括本次会议内容

• 讲解沟通完成之后，应再次复述總体需求内容
• 咨询确认是否了解当前整个需求内容

• 让相关责任人简要复述确认理解层面是否一致
• 以明确了解需求内容为判断依据
• 是否签字畫押确认由各自环境决定

9、争吵时间节点（工期与上线）

讲解沟通完毕后就进行相关的初步定稿评估工期时间，以及告知计划上线时间；（会议定稿初步工期部分争议则私下解决！）

终于熬过挑刺环节了，距离落地执行没多远了可工作还有这些：

会议结束后，应当天總结处理会议上所有讨论的争议点以及讨论的结果内容！

立马处理在会议上未能讨论解决的内容：

• 应尽快确认是否应该调整？调整的范圍是多少
• 并且及时反馈告知处理结果。

会议结束后是否需要再次召开会议，讨论内容

以落地责任人了解程度为判断依据！

会议结束後，当天内应及时通过正式渠道发布会议纪要

会议定稿后，应推动落实需求前进！

再次确定定稿内容时间节点！

内容/节点定稿后则落實到具体的排期，开始项目跟进！

定稿确认之后应正式发布通知相关责任人：

• 会议最终结果（排期，时间节点等）
• 本次涉及内容（有哪些内容做到啥程度等）

• 需要谁进行配合，感谢哪些支持等等