写在系列前面的话
最近一直在整理自己的一些笔记，自从上周彻底对整个博客进行大的归类与划分，制定了一些输出的目标。发现自己有好多的东西都零零散散，需要重头开始汇总。
一直想对自己工作以来的部分经验进行整理。在工作期间拜读了很多产品系列图书与博文，同时结合自己的部分实践，随手记录了很多小手稿，但是整个笔稿都是东一笔，西一笔。完全没有形成一个系列化的总结。于是在本周，开始将这个新的系列加入我的文章迭代内容中。
本系列所有的经验总结，均为自我总结，不能应对所有场景，如果大家在遇到相似的处境或场景，经验只供参考。
前言
需求评审，对于产品人来说是基本功之一。不管所处项目属于那种类型，需求评审是整个项目环节中不可或缺的一环。
需求评审是项目（功能迭代）进入研发阶段的最后一个环节。在我认为需求评审本质上就是指明目标，抛出问题，安排计划。
如何做好需求评审，我将结合自身经验与总结，从需求评审前、中、后三个维度进行说明。
需求评审前
在需求评审前，主要分为以下三个准备：项目准备、会议准备、会前准备。
项目准备
项目相关背景资料
- 项目背景、项目目标（迭代目标）。
项目产品资料
- 原型、核心流程图、核心架构、业务专有名称、功能优先级。
- 通用模块整理。
项目技术相关参考
- 部分技术调研、关联系统对接、关联系统改动、相关物料列表（接口、三方平台信息）。
项目研发相关
- 项目人员、项目预计研发周期。
其它
- 预估风险点、待定点（准备多种方案）
会议准备
会议的形式：线上会议还是线下会议。内部会议还是有相关合作方参与。
不同的会议所要进行准备的方式不同。比如说线上会议，一般会提前创建会议，等待相关人员加入。线下会议则需要提前进行会议地点，会议时间的提前确定。（部分公司会议室有限，需要提前预约或者提前沟通会议室的使用）。
相关人员：这里分两种，参会人员和非参会人员。
参会人员要提前梳理，包括相关研发人员、业务人员、对接人员（公司内外），人员确定后，需要进行部分核心人员的时间沟通，防止时间冲突。尤其是在一些合作项目中，相关人员构成比较复杂，需要提前进行时间的沟通。
非参会人员，部分人员属于非参会人员，但是在整个项目也是不可缺少的组成人员。此时要判断需求评审会议是否要告知，是否需要邮件抄送。
如果遇到相关人员时间冲突，需提供一些解决方案，例如：提前进行单独沟通，会后沟通等等。但是在沟通相关人员参会准备时，需尽可能的协调时间，确保所有人相关人参与。
会议时间点、预计时长
在相关会议形式、相关人员确定后，结合对应的沟通，调整预期的会议时间。并估算会议时间。
注：一般部分公司会有固定的项目研发周期与阶段，此时会有固定的下版本需求评审时间。具体的时间节点是一个多重因素影响的结果。时间的安排，最重要的尽最大可能性保证相关人员的齐全。这样可以在会议上抛出问题，防止信息差导致不必要的问题。
通知方式：邮件、群公告、@指定人
在所有准备就绪后，需要考虑通知方式，一般常用的是以邮件的方式进行通知。在邮件中简述本次需求评审内容，并附相关资料。
如果只是一个内容的迭代会议，可以在群中进行通知，例如群公告、@全体消息等。
如果只是小的部分改动的，可能涉及到只是部分端，可以在群中@指定人。
注：通知方式，具体要结合对应的公司的流程。做到通知到人，有所记录即可。
会前准备（半个小时左右）
线下会议，需提前进行会议室的准备，机器的调试，相关资料的打印等等，会前10分钟左右相关人员提醒。
线上会议，直播平台的熟悉准备，设备的调试。
注：会前准备，主要是排除会前设备故障的大问题，防止会议被其它“干扰”。不然可能会遇到尴尬的事件如会议开始了，投影有问题无法显示等等。虽然有些时候这些设备管理不属于我们处理，但是一定要提前有所检查。线上会议，一定要提前熟悉平台，不同的平台可能部分操作不一致，尤其是首次使用时。目前主流的线上会议平台都可以免费使用，有时间可以自行下载提前熟悉下，毕竟在用到的时候就能从容应对。
需求评审中
在需求评审中，其实最重要的是讲，讲产品背景、逻辑、需求等等，但是还需要部分进行问、点、记进行辅助。
问：主动进行提问，抛出部分提前准备的风险点问题。
点：事最终要落地到人到岗位，所以在部分重要的事情上，一定要点到相关人员岗位。（注：此处需判断部分问题是否会上必须提醒）。
记：问题速记，要在对应的间隔时间，采用速记的方式（自己能看懂的方式即可）进行部分问题的记录。
回顾需求评审本质：讲，如何讲好，是一场需求评审的核心。
- 思路明确：从什么地方开始讲，在什么地方强调，什么地方可以粗略。如何讲的思路，需要在会议前进行自我讲解流程梳理。如果自己讲的没头没尾，可能下面的人听得就云里雾里了。
- 快慢结合：在讲的过程中，要对语速进行有所控制，在核心流程的部分，讲慢点，保证大家全部能够接收到有效信息，在常用公共组件或非核心功能部分，需要提快速度，减少时间的占用。
以下是笔者进行一场需求评审的核心流程（个人总结流程，仅供参考）。
- 介绍项目背景，涉及端、平台都有哪些、涉及哪些部门、涉及协调岗位有哪些，
- 项目做什么、为什么、怎么做、有什么要求。
- 引出系统名称：系统专有名词，规范名词（已经有规范约束的名词，例如：CRM、HRM、DMD）等进行单独说明，达成大家的共识。为核心流程说明防止名词理解的歧义。
- 展示核心流程、核心数据流动方向（端到端，角色角色）、数据交互。提问环节：对应名词、核心流程进行提问回答。
- 模块化逐一介绍功能、目标、指标，同时每个模块完成后，进行提问，抛出问题进行记录。涉及核心功能，需要提及到具体的人或端。在模块化中引入对应风险点、待定点、抛出问题进行讨论（初步讨论，注意时间把控）。
- 进行功能优先级划分，划分对应的里程碑节点。
- 整体提问，针对问题进行回答。
- 人员协同安排：根据提前准备的人员项目情况，沟通对应项目冲突情况，估计预计时间（针对计划进行微调）。
- 同步相关物料整理进度，给出提供的节点。
- 遗留问题整理，约束解决时间（问题+人（部门）+时间）。
- 会后进行部分问题相关人员讨论。
需求评审后
- 会上问题总结。
- 涉及需求变动调整。
- 待定问题处理节点整理。
- 部分项目物料提供时间节点确定。
- 归纳至会议纪要。
- 项目排期安排、项目人员协调安排、功能优先级微调等。
- 进行相关会议材料归纳汇总，相关邮件发送。
最后
自我复盘，总结经验。什么地方有不足，如何改进。
