需求评审怎样才能高效易懂？

背景：

需求评审是产品经理日常工作中不可缺少的一环，收集到部门内外的各种需求后进行相关需求分析、需求优先级排序等环节。

终于要和相关人员商议需求到底怎么实现了，却往往会在需求评审时出现各种扯皮、弯路和争吵，严重影响产品迭代和研发。因此如何高效易懂地讲需求是产品经理在需求评审时必备的技能之一

1、问题拆解和分析

在回答问题前，先对问题进行拆解，找到关键词，挖掘问题背后的本质。

• 问题：需求评审怎么讲需求更高效易懂

• 拆解：需求评审，怎么讲， 需求， 更， 高效易懂

• 提取关键词：需求评审，怎么讲，需求，高效易懂

• 关键词对应：

需求评审——场景

怎么讲——方法

需求——内容

高效易懂——目标

通过问题拆解、提取关键词以及关键词对应，该问题就会转化为：在需求评审这个特殊的场景下，产品经理应该通过什么样的方法将需求内容高效易懂地传达给相关人员。

在回答这个问题前，产品经理需要根据关键词对应的文字进行思考几个点；

（1）为什么会有这样的场景出现，其目的是什么，其必要性占多少；

（2）通过这样一个场景希望达到什么样的目标，该目标是否是所有人的共同目标；

（3）场景中的人物角色有哪些，哪些是利害关系中的关键者，哪些是边缘人员，这些人员特点是什么；

（4）场景下的流程进展是什么样的，前后顺序及后续安排；

（5）场景中讨论的需求内容是什么，选择这些内容的原因是什么，其必要性占多少；

（6）通过何种方式表达需求内容以实现高效易懂；

通过思考以上几点，产品经理可对需求评审高效易懂地讲需求有较为清晰的认识，需要注意的是并非每次需求评审都需要经过深思熟虑，由于时间、资源等方面的限制，需求评审留给产品经理的时间和空间很少，具体怎么思考和行动要灵活应变。

但最不可忽视的是内容，因为我们要把需要做的东西准确地传达给相关人员，而高效易懂这个目标和怎么讲这个行动息息相关。简单讲：抓重点、捋清楚、讲准确、辨利害以及及时跟踪。

注意：隐藏问题背后的现实问题不可忽视：现有的需求评审往往存在拉锯战、口水纷争或利益争执，无法在有限的时间里快速推进需求，难以将其实现。

在回答问题时，人们的第一反应是怎么解决问题，而忘记问他背后存在的现实问题及其根本原因，先主动从自我反思，在边界内做出改进，之后思考外部原因，分析其他关联之间的利害关系，利用同理心思考。

2、回答问题

围绕着更高效易懂地传递需求这一目标，我们将需求评审讲需求分为三个阶段，并在不同阶段采用不同的方法。

2.1 第一阶段：需求评审前——准备

对内：即产品经理自己需要的准备

a 准备一：对需要评审的需求背后原因进行深入思考和分析，尽可能选用对方的术语或业界常见表达进行阐述

b 准备二：整理输出相关文档

• 文档包含以下几方面——主要指PRD文档

• 需求评审背景及预期实现目标
  

• 需求来源、类型、涉及用户及使用场景

• 各种图：原型图、用户操作流程图、业务流程图、权限边界、特殊情况说明图等

c 准备三：确认参与评审部门人员及人数，并梳理人员之间、以及人员与需求之间的利害关系

d 准备四：敲定评审时间、地点及流程，并通知相关人员，同时通过邮箱或协同APP发送相关文档

e 准备五：针对可能出现的突发事件准备planB，将风险控制在合理范围内

对外：即参评人员需要的准备

a 准备一：浏览相关文档，掌握本次评审主要内容和预期目标

b 准备二：对于文档中存疑之处进行标记，如果有时间机会直接找产品经理进行初步沟通

c 准备三：按时参加评审

注意：在需求评审准备阶段，大部分人认为这是产品经理的活，但如果每一个参与人员都在向着高效易懂、需求及时落地的目标前进，则要求每个人都需要在自己的主动边界内做出准备工作。

2.2 第二阶段：需求评审时——行动

a 动作一：简洁直接的开场白

• 表明会议目的、背景、预期目标（多次重复讲，让参与人员脑子里形成共识处于同一愿景下）

• 介绍会议流程及有关规则（给予对方清晰界限）

b 动作二：切入主题——讲需求

• 按照流程顺序，用对方听得懂的表达讲解需求（简洁、清晰，逻辑衔接，不拖泥带水）
  

• 需求背景、场景、涉及用户

• 相应图标展示

• 数据埋点及流动

• 异常情况，边界限制

• 预期实现目标

注意：把控时间，主次分明;表达清晰简洁，逻辑衔接

动作三：提出质疑——讨论

针对需求不合理或有疑惑之处，在场人员提出质疑，进行讨论

• 产品经理需要静心倾听，过滤有用信息，并思考解决方案

• 提问人员针对问题思考漏洞并提出解决方案

注意：把控时间，对于争议较大的需求暂时停止讨论，私下双方思考之后对接

质疑不是故意找茬，也不是推卸责任相互扯皮甚至人身攻击。质疑的目的是为了弥补产品经理在需求规划时未思考之处或现有能力无法完成，是为了让团队顺利地讲需求落地，实现迭代或者盈利；质疑的同时双方需要思考如何解决问题，并非提出问题就到此结束。具体的方案也可私下碰面也可直接提出。这个过程中，切忌将私人恩怨掺入其中。

动作四：总结回顾——加深印象

剩余一定时间将本次评审进行总结，再次阐明会议目的、预期目标以及后续主要工作:表明部门之间的利害关系及责任风险、如有疑问会后私下对接

动作五：向与会人员表达谢意

注意：需求评审时作为主要发言人产品经理既要准确清晰传达会议内容（需求），也要照顾参会人员。这里需要日常积累演讲的技能、与其他部门交流的沟通技巧，并时刻提醒自己需求评审的目的是推进需求落地，不是为了争强好胜。

2.3 第三阶段：需求评审后——跟进

• 跟进一：总结记录已明确、未明确内容，简要输出会议纪要

• 跟进二：将会议纪要和谢意再次发送至每位与会人员，并再次确认需求

• 跟进三：针对会议中未解决的需求和有关人员对接，并及时更新进度，告知与会关键人

总结：

需求评审不是一场唇枪舌战，更像是一种共识检查，不仅仅需要产品经理做出努力，而且参与其中每个人都要明白我们的共同愿景、预期目标以及所需工作是什么，通过这次检查，发现其中问题并改进，大家该如何互相友好配合，从而实现需求落地。