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

前言

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

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

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

image

需求评审前

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

项目准备

  • 项目相关背景资料

    • 项目背景、项目目标(迭代目标)。
  • 项目产品资料

    • 原型、核心流程图、核心架构、业务专有名称、功能优先级。
    • 通用模块整理。
  • 项目技术相关参考

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

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

    • 预估风险点、待定点(准备多种方案)

会议准备

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

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

相关人员:这里分两种,参会人员和非参会人员。

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

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

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

会议时间点、预计时长

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

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

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

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

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

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

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

会前准备(半个小时左右)

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

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

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

需求评审中

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

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

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

记:问题速记,要在对应的间隔时间,采用速记的方式(自己能看懂的方式即可)进行部分问题的记录。

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

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

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

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

需求评审后

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

最后

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

你可能感兴趣的:(【经验总结】产品经理岗_项目管理_做好一场需求评审)