【经验总结】产品经理岗_项目管理_做好一场需求评审

前言

需求评审，对于产品人来说是基本功之一。不管所处项目属于那种类型，需求评审是整个项目环节中不可或缺的一环。

需求评审是项目（功能迭代）进入研发阶段的最后一个环节。在我认为需求评审本质上就是指明目标，抛出问题，安排计划。

如何做好需求评审，我将结合自身经验与总结，从需求评审前、中、后三个维度进行说明。

image

需求评审前

在需求评审前，主要分为以下三个准备：项目准备、会议准备、会前准备。

项目准备

• 项目相关背景资料

• • 项目背景、项目目标（迭代目标）。

• 项目产品资料

• • 原型、核心流程图、核心架构、业务专有名称、功能优先级。
  • 通用模块整理。

• 项目技术相关参考

• • 部分技术调研、关联系统对接、关联系统改动、相关物料列表（接口、三方平台信息）。

• 项目研发相关

• • 项目人员、项目预计研发周期。

• 其它

• • 预估风险点、待定点（准备多种方案）

会议准备

会议的形式：线上会议还是线下会议。内部会议还是有相关合作方参与。

不同的会议所要进行准备的方式不同。比如说线上会议，一般会提前创建会议，等待相关人员加入。线下会议则需要提前进行会议地点，会议时间的提前确定。（部分公司会议室有限，需要提前预约或者提前沟通会议室的使用）。

相关人员：这里分两种，参会人员和非参会人员。

参会人员要提前梳理，包括相关研发人员、业务人员、对接人员（公司内外），人员确定后，需要进行部分核心人员的时间沟通，防止时间冲突。尤其是在一些合作项目中，相关人员构成比较复杂，需要提前进行时间的沟通。

非参会人员，部分人员属于非参会人员，但是在整个项目也是不可缺少的组成人员。此时要判断需求评审会议是否要告知，是否需要邮件抄送。

如果遇到相关人员时间冲突，需提供一些解决方案，例如：提前进行单独沟通，会后沟通等等。但是在沟通相关人员参会准备时，需尽可能的协调时间，确保所有人相关人参与。

会议时间点、预计时长

在相关会议形式、相关人员确定后，结合对应的沟通，调整预期的会议时间。并估算会议时间。

注：一般部分公司会有固定的项目研发周期与阶段，此时会有固定的下版本需求评审时间。具体的时间节点是一个多重因素影响的结果。时间的安排，最重要的尽最大可能性保证相关人员的齐全。这样可以在会议上抛出问题，防止信息差导致不必要的问题。

通知方式：邮件、群公告、@指定人

在所有准备就绪后，需要考虑通知方式，一般常用的是以邮件的方式进行通知。在邮件中简述本次需求评审内容，并附相关资料。

如果只是一个内容的迭代会议，可以在群中进行通知，例如群公告、@全体消息等。

如果只是小的部分改动的，可能涉及到只是部分端，可以在群中@指定人。

注：通知方式，具体要结合对应的公司的流程。做到通知到人，有所记录即可。

会前准备（半个小时左右）

线下会议，需提前进行会议室的准备，机器的调试，相关资料的打印等等，会前10分钟左右相关人员提醒。

线上会议，直播平台的熟悉准备，设备的调试。

注：会前准备，主要是排除会前设备故障的大问题，防止会议被其它“干扰”。不然可能会遇到尴尬的事件如会议开始了，投影有问题无法显示等等。虽然有些时候这些设备管理不属于我们处理，但是一定要提前有所检查。线上会议，一定要提前熟悉平台，不同的平台可能部分操作不一致，尤其是首次使用时。目前主流的线上会议平台都可以免费使用，有时间可以自行下载提前熟悉下，毕竟在用到的时候就能从容应对。

需求评审中

在需求评审中，其实最重要的是讲，讲产品背景、逻辑、需求等等，但是还需要部分进行问、点、记进行辅助。

问：主动进行提问，抛出部分提前准备的风险点问题。

点：事最终要落地到人到岗位，所以在部分重要的事情上，一定要点到相关人员岗位。（注：此处需判断部分问题是否会上必须提醒）。

记：问题速记，要在对应的间隔时间，采用速记的方式（自己能看懂的方式即可）进行部分问题的记录。

回顾需求评审本质：讲，如何讲好，是一场需求评审的核心。

• 思路明确：从什么地方开始讲，在什么地方强调，什么地方可以粗略。如何讲的思路，需要在会议前进行自我讲解流程梳理。如果自己讲的没头没尾，可能下面的人听得就云里雾里了。
• 快慢结合：在讲的过程中，要对语速进行有所控制，在核心流程的部分，讲慢点，保证大家全部能够接收到有效信息，在常用公共组件或非核心功能部分，需要提快速度，减少时间的占用。

以下是笔者进行一场需求评审的核心流程（个人总结流程，仅供参考）。

• 介绍项目背景，涉及端、平台都有哪些、涉及哪些部门、涉及协调岗位有哪些，
• 项目做什么、为什么、怎么做、有什么要求。
• 引出系统名称：系统专有名词，规范名词（已经有规范约束的名词，例如：CRM、HRM、DMD）等进行单独说明，达成大家的共识。为核心流程说明防止名词理解的歧义。
• 展示核心流程、核心数据流动方向（端到端，角色角色）、数据交互。提问环节：对应名词、核心流程进行提问回答。
• 模块化逐一介绍功能、目标、指标，同时每个模块完成后，进行提问，抛出问题进行记录。涉及核心功能，需要提及到具体的人或端。在模块化中引入对应风险点、待定点、抛出问题进行讨论（初步讨论，注意时间把控）。
• 进行功能优先级划分，划分对应的里程碑节点。
• 整体提问，针对问题进行回答。
• 人员协同安排：根据提前准备的人员项目情况，沟通对应项目冲突情况，估计预计时间（针对计划进行微调）。
• 同步相关物料整理进度，给出提供的节点。
• 遗留问题整理，约束解决时间（问题+人（部门）+时间）。
• 会后进行部分问题相关人员讨论。

需求评审后

• 会上问题总结。
• 涉及需求变动调整。
• 待定问题处理节点整理。
• 部分项目物料提供时间节点确定。
• 归纳至会议纪要。
• 项目排期安排、项目人员协调安排、功能优先级微调等。
• 进行相关会议材料归纳汇总，相关邮件发送。

最后

自我复盘，总结经验。什么地方有不足，如何改进。