产品经理如何组织一场高效有价值的产品需求评审会

一、传统的内部分享是怎样的?

我们先来还原一个工作场景:

公司某个部门团队齐聚会议室,参与同事的分享讨论会。按照常规操作,分享人照着准备的材料一气呵成陈述完毕,然后询问大家针对分享的内容有没有啥想法?大家互相对视之后缄默不语。好,本次分享会到此结束……

会后询问参与分享会的同事:“你认为平时的内部分享内容怎么样?自己有收获吗?”。

  • A同学:分享的内容不怎么感兴趣,感觉像是刷了一个新闻,简单了解了这个“知识点”。
  • B同学:分享的主题倒是挺不错的,就是时间太短,内容比较浅有种意犹未尽的感觉。
  • C同学:分享内容干货少,对自己的工作或生活没有实际的启发或帮助。
  • D同学:内部分享是轮流执行的,每次分享材料的准备对自己来说是一种煎熬,很多时候不知道要分享什么……

根据以上小伙伴的描述,我们可以总结出传统分享会的常规流程:

  • 通常由一个人准备材料和阐述。
  • 自由选择分享的主题,不限定具体方向。
  • 由于分享时间有所限制,分享的内容比较少,并且输出的观点容易“重结果轻过程”。
  • 每个人对于通过分享会是否有所收获的理解存在差异,很难做到让绝大部分参与人满意。

二、传统分享机制存在的问题

从上面分享会的流程中暴露出以下问题:

  • 团队成员是否对分享的目的和定位,有明确一致的看法?
  • 如果不圈定分享主题的具体范围,太多的选择意味着很难选择。
  • 众人拾柴火焰高,几个人做前期准备总好于一个人,并且能促进成员协作。
  • 不能让“课题材料准备时间和分享时间”成为影响产出质量的因素。
  • 如何最大可能保证每位成员积极参与、并且从中受益匪浅?

三、分享的目的是什么?

其实目的很简单,无非就是两个:

  1. 内部分享是促进团队成员沟通交流的一种方式。
  2. 通过分享,参与人能够有收获。

任何时候都需要围绕目的和定位展开,不能让内部分享流于形式,若听完没有多大的收获,再或者这种收获不能得到实际应用,等同于整个过程都是在浪费大家时间!

四、如何改变?

“存在的问题和做这件事的初心”是我们找到的“病因”,接下来需要解决的是围绕病因“对症下药”。

下面以近期部门对分享机制所做的调整举例,从以下几个方面着手思考:

1. 明确分享目的,达成一致意见

有的同事希望分享内容有助于日常工作项目;有的同事认为不一定要那么“功利”,只要是正向有趣的东西都可以分享,比如聊社会学人文学、近期火热的节目等。有不同的想法很正常,这时候需要部门管理者确定内部分享的主旨。

前段时间部门意识到之前分享会存在上面提到的问题,专门组织了成员讨论,最终敲定了一个方案:将分享拆分为两种类型:

  • 一种是紧密结合工作项目和专业能力提升的研究型课题分享。
  • 另一种是不限定范围,任何美的、有趣好玩的、突发灵感的轻松型话题分享。

研究型课题需要投入相对较大的精力去准备,确定为部门分享的主线。而轻松型话题分享不做任何具体要求,属于次要辅助地位。

2. 圈定分享内容范围,激活成员想法

互联网产品设计领域经常提到一句话“不要给用户过多的选择,因为会增加用户的理解成本拉长决策时间,甚至有可能增加出错概率”。所以这里需要把握一个“度”,既要框定分享的主体方向和大概范围,又要让团队成员基于这个范围能够灵活的确定分享主题和内容

针对这个问题,部门提出了两种解决方案:

  • 由部门根据成员需要提升的专业能力、近期项目中暴露出的问题、以及未来规划的项目,提出固定的分享课题。目的也很明确:通过深度融入具体业务,解决问题的同时提升专业能力。
  • 部门成员根据自己实际参与项目过程中遇到的问题或想法,主动提出想要学习和了解的课题,纳入到“分享储备库”中,确保课题分享不间断。

3. 单兵作战改为多人协作

课题既然结合了业务,不同成员参与的项目不同、思考维度也不同,由多人共同完成一个课题研究与分享,便于多维度更加全面的内容呈现。

所以我们部门决定采用小组机制,一个小组至少由两个人组成,内部协商分工。这样的做法既有利于完善分享的课题,也为成员之间沟通协作提供了磨合机会。

4. 分享前期准备和分享时间,依据分享主题灵活调整

传统的分享往往以单周或者双周为间隔,交替轮流分享,但实际工作中大概率会比较忙碌,导致没有足够的时间准备分享材料,但是到了时间节点又必须有产出,当然直接会影响分享质量。

将“对时间的把控权”下放到具体的小组,这样做解决了因为时间紧张而影响到内容质量的问题。调整为根据选定课题的难易程度,以及课题小组成员分工情况,分阶段输出。

5. 成员自主选择感兴趣的分享课题,确保有所收获

每位同事至少选择一个自己作为小组成员参与的“感兴趣的课题”,其他小组的课题依据自身的时间安排,自愿决定是否参加。这样确保了小组的每位成员都能够认真积极的准备课题,并且多个课题可以同步推进。

其实想要有收获特别简单,满足两个条件即可:感兴趣、投入时间思考。以上提到的每一点改变都是围绕这两个条件展开的。

一、需求评审是什么?

要想开一场完美的需求评审会,必须明白需求评审的目的,只有明确目的后,做好相关的准备工作才能够事半功倍!

1. 需求评审的目的

  • 检视需求的合理性与完整性,降低需求风险。
  • 与项目干系人对项目目标、需求达成一致,方便其他工作人员能够了解工作任务,从而增强团队协作能力。
  • 能够对产品进行全方位的论证,验证或更改自己的想法、获取更多的想法,进行头脑风暴,完善产品需求。头脑风暴的作用有以及几点,不仅仅试用与需求评审也适用于其他方面。

头脑风暴

  1. 让参与者敞开思想集体讨论,相互启发激励,以弥补知识缺陷
  2. 引起创造性设想的连锁反应,产生尽可能多的设想,并使各种想法在相互碰撞中激起脑海中创造性风暴
  3. 再对设想进行客观,连续的分析
  4. 从而找出解决难题的黄金方案

如果没有需求评审将会产生什么后果呢?

1)需求严重的失真性!

2)增加项目成本,项目成员对需求的意见没有保持一致,不清楚自己要做什么,也不知道做成什么样子,什么时候交付,严重影响项目的进度。

3)思维角度分歧,产品经理和工程师各自的视角不一样,工程师代表的是技术思维,而产品经理代表的是产品和用户思维,这两种思维天然就存在一些冲突和矛盾。

2. 成功的需求评审

一场成功的需求评审会。是能够完整,清晰传递产品目标,产品功能,能获得团队认同,并且会后团队能够配合实施的,从而能有效推动产品进度的会议。

  • 产品目标:能够讲明白,我们要做什么产品,为什么要做,做这个产品的意义,能解决什么问题。
  • 产品功能:能够说出产品功能实现的意义和规则,涉及到哪些方面,前端、后台、UI、UE、运营、测试,并且向团队指出为了完成该需求应该怎么做,合理的分配任务。
  • 产品实施:解决会上提出的问题,输出会议纪要及项目计划表。

二、如何做好需求评审?

1. 评审会前准备

(1)邮件通知

任何形式的沟通,都必须以邮件(公司联系方式)来确认,邮件的内容包括一下几个方面。

项目背景介绍,如果是新项目,要输出 BRD 和市场调研分析, 用户画像,老项目要输出数据分析、用户反馈,竞品状况,也就是需求来源等,让团队成员对需求评审会的项目有个大致准备,每个人都可以在会前有思考的过程,方便各成员能做好相关的会议准备。

输出项目目标,本次项目,你要达到什么目的,评估标准,作为产品经理可以提前通过该种方式让团队成员知道自己的观点和想法,提前输出,方便会议时能够更好的理解。

输出项目文档,BRD/MRD、PRD、流程图、结构图、原型图、以及与之相关的所有文档。不做无准备的仗,只有文档的输出才能让团队成员能够全方位的了解项目。

邀请人员:测试、开发(前端、后端、客户端、运维)、UI、UE、运营、以及Boss和确定开会的时间和地点。因为不是所有人的时间都是一致的,只有提前确定时间,才能确保会议的正常进行,必要时,需要会前多次通知及确认。

(2)提前预演

预演不需要太多人,项目相关的核心人员(产品经理、前端主管、后台主管)即可。

从他们的角度看有没有漏洞,证需求文档的主要逻辑没有问题,从而明确需求能不能实现

为了获取认同,获得会议的支持者,提前通个气,这样可以能减少很多不必要的矛盾,甚至是领导的肯定,那么接下来的项目推进,就会非常轻松,在遇到争议性较大的议题时,这一点会非常有效。

(3)自我的会前准备

产品经理作为需求评审会的核心成员,必须对该项目有深层次的了解,

例如需求背景,需求的来源,目标用户,市场现状,遇到的问题,调研结果,要解决问题的深入分析和思考。

通过自我的思考和准备进行改进和完善,通过准备工作发现要评审的产品方案的不足并加以修正,在需求评审会上提高需求评审通过的概率。

只有在会前有过准备和思考并且能够在会议时了然于胸,才能立于不败之地,不然会被其他人员怼的哑口无言。

2. 会议中

你穿上了一身破烂T恤,打开会议室的门,连接好投影仪,睁开一夜未眠的双眼,这场战斗才刚刚开始。

那么,这个会要怎么开?

开会有时候就是靠着你这一张三寸不烂之舌,征服大家。

作为产品经理,要有良好的表达能力,描述项目时需要有逻辑,有条理的叙述,明确的说出自己的想法及项目的相关内容,但是我们需要以事实为依据,以数据做基础,不能凭空想象,无中生有。

首先不要想当然的认为别人和自己具有一样的背景,比如设计人员不知道如何开发,开发人员不熟悉具体的业务知识,在阐述一个需求的时候要考虑到大家都是来自不同背景的,用大家都能理解的方式进行需求。

在进行需求评审时前不要忙着讲解用户操作流程,演示原型图,

我们应该对需求的价值进行说明,然后说明需求的背景以及需求想要实现什么目标、解决什么问题,这样的话大家对需求的理解才能更深刻,才不会在后期质疑是否需求的必要性。

尽量用举例子、讲故事的方式来说明需求。在讲解用户操作时可以结合具体的业务场景,与每一块的负责人确认排期时间是否有疑义。

产品经理不仅要会说而且还要会听,善于倾听他人意见和想法。

作为一个团队,每个所对应的岗位不同,思考的维度就会不同,工程师考虑的是技术,UI考虑的是交互,老板考虑的是商业价值等等。

例如产品经理和工程师,产品经理在陈述完产品设计思路后,工程师就会对产品设计提出意见,然后产品经理会回应工程师的意见,这个过程中的讨论经常转变成一场无关主题的争论。

比如对于登录功能的设计,是否需要在密码中支持特殊符号,产品经理的意见是需要支持。

因为不同人对于密码的要求不一样,有很多用户会使用特殊字符设置密码,不能通过特殊字符设置密码会给用户一种不安全感。

工程师认为特殊字符过于复杂,产品可以定义一个统一的规则例如只支持数字和字母,这样产品规则就简单了。

注意,在这个过程中,大家讨论的焦点并不是产品的技术实现解决方案,而是对产品的设计和对用户的理解,如果产品经理能够把握住这个差别,应该耐心地询问工程师这两种设计方式在实现上有没有区别,如果没有区别,则建议选择让用户更具安全感的支持特殊字符的方式;

如果在技术实现上有区别,那么再来衡量具体实施工作量,看投入产出是否合适。通过对问题的区分可以化解争论。

产品经理要在这个过程中要善于倾听,倾听别人的意见和想法,站在别人的角度思考问题,理解当事人的观点,从而沟通出最合理的方案。

产品经理不仅要会说会听还要会记

需求评审会时,一定一定要安排产品助理进行会议记录,如果没有助理自己准备录音笔,需求评审会,会遇到很多问题和想法,不可能当时就解决,优先解决重点内容,记录会议内容可以防止问题的遗漏,对于细节问题,可以私下单独联系解决。一份会议记录可以帮助你回忆整个会议内容,事后可以针对性的进行内容整合分析。

3. 会议后

会议开完了就完了吗?那可不是的,一天的战斗才刚刚开始,会议后依旧十分的重要。

会议后需要对会议记录进行整理,对于没有解决的问题及时的处理,需求需进行修改,并且修改好以后,把会议修改的内容全部发出来,达成一致的、修改的、疑问的一一列举出来,并输出反馈时间表,要及时同步给大家,并且在群里进行简要提醒和说明。如果遇到自己解决不了的问题,可以找相关人员进行私聊解决,或者小团队讨论。

做好会议总结:通过总结分析今天会议自己的不足,以及整个会议遇到的问题,和会议得到的结论和观点,及时的反思优化,避免下一次发生同样的错误,为项目的进一步推进做好准备。

跟进各个角色:配合测试输出用例,配合运营输出运营需求,配合UI输出UI需求,配合UE输出UE需求,配合开发输出功能列表。进行项目管理,输出时间节点完成日期落实到责任人,以及后续评审日期,上线全环节跟进,并整理需求。

总结

产品需求不会是百分百正确,我们要客观面对需求,及时止损,及时改变。

需求评审会也不是一次就能解决问题的,我们需要与时俱进,随时更新,面对新需求不畏惧,面对需求评审会,评审会议不要纠结交互细节和设计细节,而是判断产品方面、研发流程、时间成本、完善产品功能,对大方向进行决策。

做好会前准备,合理通知,体验预演,自我思考,掌握会议的整体局势

会中实施,通过沟通,倾听,记录,把握会议的脉搏

会后总结,及时整理认真反思,解决会议问题,开始项目跟进,推进项目实施。

 

文章由PM28网编辑,作者:海阁,如若转载,请注明出处:http://www.pm28.com/4002.html欢迎投稿

联系我们

在线咨询:点击这里给我发消息

邮件:403567334@qq.com

工作时间:周一至周五,9:30-18:30,节假日休息