关于需求评审流程该怎么高效有条理的走下去

在产品落地开疆扩土前进上，需求评审就是产品人开荒的第一步！

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

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

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

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

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

常见人员	挑哪些刺
研发人员	相爱相杀好伙伴，他们更多的在意 实现层面，以及数据关联性；
测试人员	会跟你纠结流程细节，PRD细节，啥刺也挑；
运营人员	在乎新版如何运营，一般等上线后再挑，更加在乎是否有运营工具；
市场人员	在意大的流程，以及产品重大卖点，怎么忽悠怎么卖钱；
UI/UE/UX	一般内心是向着用户体验上，视觉交互上；
产品人员	好战友，陪你前进，给你壮胆，帮你记录会议内容，协助纠纷处理；
……	………………

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

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

一、会议前

会议召开前

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

• 了解会议目的
  1、统一思想，了解需求意义，
  2、明确需求具体涉及范围，
  3、确定事项落实工期与责任，
  4、确定开展工作，
  你要清晰的知道为什么要召开这次会议

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

• 提前通知责任人

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

• 备好问题速救药
  产品内部自行检查好：一般保证这几方面：
  （确定性，完整性，复杂性，熟悉性，稳定性，交互性）
  1、确定要这么做？这么做会***，考虑清楚要这么做？
  2、还有这种情况你没考虑到？
  3、这个搞的话，太复杂了，能简单点不？
  4、你要动这一块，有没有考虑到现有的流程？
  5、确定定稿这些内容了，会不会再出现变化？
  6、这个交互为什么要这样，主要的是这样？

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

二、会议中

会议召开中

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

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

• 讲解前应先说说本次会议的内容范围
  相关涉及责任人到会议室后，应在开会前明确表明确认：
  本次会议目的，会议涉及内容，会议所需结果；
  （不要一上来就直接讲原型！）

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

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

• 终于可以开始好好的讲解需求了
  讲解答疑环节中应讲究条理性与节奏，
  1、需求背景：概述需求从哪来，为何要做这块，
  2、用户与需求概述：描述需求应该要做成什么样，
  3、功能模块：需求涉及相关的重点大的功能点，
  4、简要优先级：描述下当前的最重点内容，
  5、流程讲解：讲解本次需求涉及主要流程，
  6、原型与交互：开始讲解原型内容和交互，
  7、数据指标：讲解本次需要哪些关键性的指标；

• 需要各各环节的配合
  明确落实本次需求需要哪些人，哪些资源进行配合！
  比如：需要运营协助处理文案；需要开发协助技术实现，需要行政协助开设激励奖等

• 总结概括本次会议内容
  1、讲解沟通完成之后，应再次复述总体需求内容，
  2、咨询确认是否了解当前整个需求内容；

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

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

三、会议后

会议召开后

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

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

• 是否需要进行调整
  立马处理在会议上未能讨论解决的内容，
  1、应尽快确认是否应该调整？调整的范围是多少？
  2、并且及时反馈告知处理结果。

• 是否需要再次召开
  会议结束后，是否需要再次召开会议，讨论内容，
  以落地责任人了解程度为判断依据！

• 发送会议记录
  会议结束后，当天内应及时通过正式渠道发布会议纪要，
  1、会议讨论设计内容，
  2、争议点及其处理内容，
  3、初步定稿时间与责任人；

• 落实明确行动计划
  会议定稿后，应推动落实需求前进！
  再次确定定稿内容时间节点！

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

• 定稿内容发送
  定稿确认之后，应正式发布通知相关责任人：
  1、会议最终结果（排期，时间节点等），
  2、本次涉及内容（有哪些内容，做到啥程度等），
  3、需要谁进行配合，感谢哪些支持等等！

温馨提示：至始至终，要明确你开会是为了什么，想要什么结果！

终于可以安心了，任务开始徐徐前进了，可接下来的工作还不少，还要继续开撕！
--来自永远不定期断更的 youketao

==（关于需求评审质疑，如何有效的沟通，再说了！）==

版本 v1.00.0603初稿， v1.01.0603修改错别字， v1.01.0607修改错别字