产品经理如何开一次成功的需求评审会?

白白 · 2021-11-26 14:40
1 个回答
产品人陈师爷
产品人陈师爷
公众号[产品人玄青]主理人,十年产品经验
开会已经是所有打工人的日常了,开需求评审会则是产品经理的日常。会怎么开,怎么开好其实是有很多学问在里面的,这需要一些实践才能更好的掌握。 需求评审会做为会议的一种,当然也是需要有一些技巧。毕竟群体活动,人一多就容易出问题,一个不好那就是各讲各的、草草收场。所以想要顺利的开完每一次需求评审会,产品经理们还是需要做大量的工作,避免出现问题。 经过一番摸爬滚打,我们总结出了开好需求评审会的5大步骤,和大家做一些分享,希望各位看完能有一二收获。 首先讲一下什么是需求评审会,算是给行外的朋友做做背景介绍。 需求评审会是产品经理主持召开的,向UI设计师、技术、测试等下游协作的同事,讲解新的需求方案的会议。 简单打个比方,就好比要造一栋房子,产品经理已经把这栋房子的设计方案已经做好了,这个时候就要开个会,把负责具体施工的各个部门拉到一起开个会,讲一下这个造楼的方案具体是怎么样的,哪些地方是要注意的。好让其他部门的同事熟悉这个方案,并针对这个方案把不清楚的地方确认一下、或者觉得不合适的地方提出建议,然后最终把这个方案定下来,会后好回去评估需要投入的人力资源和安排具体工期。 所以需求评审会实际上是一次统一认识、明确方案的会议,还是很重要的。每个产品经理都需要组织这个类型的会议,但是一开始都不容易做好的一个事情。 那么接下去我们就讲一下这个需求评审会应该怎么开的问题,分成5个步骤: 第一步:会前沟通。在正式开会前、在方案有了大概的主体设计的时候先和主要参与的同事做一下方案的沟通。 这里面有几个要点:一是会前先沟通;二是不需要等方案做完,有主体框架就行;三是和主要同事沟通。 会前沟通这个主要是为了两点: 先和主要参与的同事达成共识,让大家了解这个需求的背景、目的和必要性,让大家知道为什么要做,这个很重要。 人只有知道目的才能更好的发挥出主观能动性,才能针对性的对方案进行评估。如果其他同事都不知道为什么要做这个需求,他都不知道这个方案能不能有效解决这个问题,就谈不上评估了。 同时呢如果有分歧的话正好也在会前沟通清楚,避免在会议上出现争论,基本上一争论这个会的效率就很低了,同时会议能不能有结果也就不好说了; 再和这些同事就主体方案进行讨论,确保方案具备可执行性。这个时候不需要讨论细节问题,主要是确保这个方案的主体框架完整和方案具备可行性。 有的时候可能会存在技术无法完成(含实施成本过高)或者和其他功能存在冲突的情况,这个时候就需要对主体方案进行调整,这也是为什么不能等方案完全定下来再讨论的原因,因为如果方案已经连细节都补充好了,调整的成本就比较高,浪费时间。 为什么是和主要参与的同事呢?也是出于效率考虑,每个人都沟通一轮耗时耗力没必要。另外你也未必就知道这个项目会有哪些同事参与。注意这个主要参与的同事首先是需求方的同事,你做的方案需要先让需求方认可,然后再和研发的同事沟通。 什么是主体框架?就是这个方案的主流程和主要的功能点、逻辑点及页面已经有了,在讨论的时候其他同事看到这个东西他们能大概知道要做哪些内容了。或者再简单一点说你已经把主流程、页面和主要的功能逻辑都理好了,缺的是一些交互和一些页面的异常提示什么的。 如果相关的同事对主体方案没有什么问题,那么接下去就是细化方案,把各个细节补全。在细节补全之后通常产品经理还会做内部评审。 第二步:内部评审。这个环节主要在产品部门内部,集合大家的力量把这个方案做扎实。注意它不是个挑问题的过程,而是一个查漏补缺的过程。 在内部评审会上,其他产品同事会给一些建议,有的时候甚至这些建议是很尖锐的,但是不要怕,如果问题不在内部解决就会在外部解决,而外部解决的话那么代价会更大,其他部门的同事容易对你有不靠谱的印象。 而且内部的讨论有助于你学习其他产品经理的思路和一些方法,其实属于切磋,很有帮助的。 在内部评审过程中如果有些问题是两可的,那么就以自己的思路为准,如果明显别人的思路更好的那么就调整方案,最后做出一个相对最优的方案出来。 产品经理光埋头苦干肯定是不行的,能够借力也是一种能力,而产品内部的力量那是必须要借用的。 第三步:提前预约会议时间。和所有相关同事预约开会的时间,在确认后写正式的会议邮件邀请相关同事参会。 预约之前需要先确认一下有哪些同事会需要参会以及具体的会议时间,如果公司不大我估计产品经理心里是比较有谱的,挨个问一下。如果公司相对大一点,那么就问各部门的负责人,如果没有部门负责人有组长就问下组长,一定要注意程序正义,尊重各部门负责人,别拿村长不当干部,由负责人来协调具体的参会人员和开会时间。 在确定了与会人员名单和开会时间之后需要写正式的会议邮件给各部门的同事,把会议的时间、地点、讨论事项,会议文件写在邮件里。尤其是要把会议文件放上去让大家先看下具体的内容,先熟悉一下,这样开会的时候就可以让其他同事针对性的听他们不清晰的地方。 在与会人员名单里面一定要把业务部门的同事也加上,这样可以确保各方的信息是同步的。不会出现还需要会后再传达会议内容的情况。如果有一些需要确认和调整的地方也可以在会议上定下方向来。 有的公司小没有公司邮箱怎么办?那么可以在微信群、钉钉群里面通知,但一定要通知。 第四步:开需求评审会。在会上和各部门达成共识以及确定最终方案。 在开需求评审会的过程中可以遵照以下步骤去做: (1)先介绍本次需求的背景、目的和必要性。如果有具体预设指标的话也需要把预设目标说清楚,类似提高转化率5个百分点这种具体可量化的目标; (2)再介绍本次方案的主要业务流程和逻辑,要确保这些流程和逻辑不出错,说完之后可以向需求部门和技术部门都确认一下是否有疑问; (3)再介绍本次方案的具体页面方案和交互设计逻辑,这个就是把整个方案的细节讲清楚,确保整个方案的边界都是清晰的,说完之后可以向需求部门和技术部门都确认一下是否有疑问; 实际上第2和第3这两个环节就是在会议上最终把方案完整的介绍一次,形成共识、然后把方案确定下来,这个是一个必要的流程,但是准备工作需要在会议前就先做,不然等到会议上各方有各自的看法和意见,这个会就会变成讨论会,就不容易形成最终的结论,这个和会议的目的不一致。 讨论会是开放式的,需求评审会是收敛的,主要还是起到一个信息同步的作用。 另外在向相关同事做确认的过程中,问的是各部门主要负责人的意见,对方要能接你的话,别问那些不容易沟通的同事。 在会上可能会出现临时想到的问题或者一下子不好答复的问题,这个时候产品经理可以说把这个问题记录下来,会后和相关同事讨论后再把解决方案或者信息同步出来。不要急于在会议上做没有把握的决定,急躁容易把事情想简单了,同时也会给其他同事一个不靠谱的印象; (4)在最后把会议上确定方案需要调整的地方以及会后各部门需要跟进的事项都复述一次,确保相关事项没有遗漏; (5)会议结束后把会议纪要写一下,主要是写一下第4点中提到的内容,并明确写出各方需要的时间节点,以便于后续跟进; (6)跟进评审会的决议跟进后续事项。如何产品方案有调整的,可以向技术部门确认一下是否需要做二次评审,如果需要则再开一次会。当然二次会议主要是把新的方案确认一下。 第五步:会后把这个需求的排期表确认下来并同步给各方同事。 这也是一个同步信息的过程,项目的排期实际上是各部门分开评估的,产品经理需要做的就是尽快把项目排期表定下来然后同步出去,方便各部门按照时间表推进项目,也方便领导和需求部门跟踪进度。 如果项目管理是产品经理负责的话,那么产品经理还需要跟进研发进度,确保项目不会延期。至于怎么跟项目进度那是另一个学问,在这里就不赘言了。 以上就是产品经理开需求评审会可以参考的5个步骤,做起来也不复杂,但是做的时候每一步需要都做到位,不要忽略或者轻视敷衍,这样这个会才能开的顺利。而每次会开的顺利,渐渐的大家就会觉得你这个人靠谱、效率高,这对你本身得到更多肯定也是极有帮助的。 希望我们的分享能够对大家有一些启发,帮助大家顺利开完需求评审会,也能顺利开完各种每天开不完的会。
3
反对
评论
收藏
2021-11-26 14:50
前往发表回答