产品经理的战场:需求评审会

Ritchie(乞戈) 一直前进 Ritchie(乞戈) 一直前进     2022-09-03     306

关键词:

因项目需要做需求评审,之前没有参与过类似专题工作,特地在网上找了些资料,感觉这篇还不错。

转载自互联网的壹些事

你还记得自己参加过多少场「需求评审会」吗?不管自己是作为主机主导,还是作为僚机配合,「需求评审会」的现场都是让人不明觉厉。而产品经理就是在这一个又一个的「需求评审会」中磨练过来的,是一个真正刷怪升级的过程。据说「需求评审会」又名「撕逼大会」,你可以感受下这其中的画面感。

产品经理组织的「需求评审会」类似多方会谈,与会人员很容易进入角色后产生「自主」情绪,形成正反两派甚至是多派,最后由「讨论」演变为「辩论」,有点类似「奇葩说」的形式。产品经理在这个「辩论」的过程中,不断展示自己的观点,希望获得更多的认可,可不少产品经理都在这个「辩论」的过程中把自己搞的伤痕累累,十分狼狈。

关于「需求评审会」的个人目标

产品经理需要明确自己在这次「需求评审会」的个人目标是什么。这个目标是制定给自己的,而非给团队制定的,说白了就是通过「需求评审会」达到什么效果。

比如:让开发团队、测试团队的同学能认同自己本次迭代的产品方案,这是一个非常务实的目标。

比如:让开发团队、测试团队知道自己和设计师在产品策划阶段尽了多大的努力和尝试,这是一个展示设计团队的目标。

比如:向开发团队、测试团队展示自己严谨的思维逻辑和出色的产品设计能力,这是一个偏个人的目标。

虽然出发点不同,但这些都算是一个前置条件。

关于「需求评审会」的原则

一、「不要试图将自己的想法移植到别人的大脑中」

首先产品经理需要明确一点,我们召开「需求评审会」不是为了「移植想法」到别人的大脑中,而是通过「引导」和「讨论」磨合得出大家都认可的产品方案。

我参加过不少「需求评审会」,产品经理们都是抱着「移植想法」、「说服你」的态度在进行需求宣讲,产品经理绞尽脑汁把自己的想法「移植」到开发、测试同学的大脑中,可想而知这个过程是多么的痛苦;双方又为了「说服」彼此,必然会找出自己经历过的项目中比较极端的案例来支撑自己观点,可想而知这个过程又是多么的火爆。

其实产品经理和开发团队、测试团队应该是一个「配合」的过程,也就是说在产品经理的基础方案上,不断的优化和调整的过程,如果开发同学有更好的想法,产品经理就应该去采纳。可现实情况是,很多产品经理碍于「面子」问题,总觉得必须听我的,别人说的「对」或者「不对」我都不管,一直在单方面的坚持自己。这就很没必要了,对吧?

二、「不要在不同观点上过于纠结,浪费时间」

我们本着「求同存异」的观点来进行问题的「讨论」,也就是说大方向相同,小细节可以有不同观点,并且鼓励大家表达出自己的观点,产品经理的「开放」心态是很重要的。

在整个需求评审的过程中一定有不少大大小小的问题,对于彼此认可的地方我们确认完毕后快速带过,对于彼此不认可的地方我们不再纠结,如果讨论了5分钟以上仍然没有结论,产品经理就记下这个问题,先进行后面的内容,最后再掉回头来讨论之前有争议的问题。

我经历过一场很煎熬的「需求评审会」,从下午1330一直持续到1900左右仍未结束,原因就是由于产品经理没有控制好问题讨论的时间,以及细节讨论的颗粒度,导致需求评审的战线拖的很长,而且效果非常一般,大家苦不堪言。

三、「要给所有人明确本次需求评审会的背景及目标」

很多产品经理在「需求评审会」刚开始的时候就讲交互流程,功能feature,这是大忌。大家都还没有摸清状况呢,怎么会进到你的流程中呢?又怎么能找到里面的细节问题呢?又怎么会认可你的方案呢?

所以产品经理在最开始需要给大家「调频」,让大家都到一个频道上来。其实就是需要产品经理在「需求评审会」开始后先别急着讲交互和功能,而是给大家介绍一下我们这个版本要「做什么」,「为什么做」,「有什么价值」这三个方面(其实也是做产品规划时需要考虑的),这也就是所谓的背景和目标。

这里其实也符合「金字塔原理」中的背景矛盾问题-解决办法的思维模式,我在曾经的文章中有做详细的描述。你可以点击查看:产品经理必备技能:金字塔思维。

四、「不管现场状况多么恶劣,产品经理不可露怯,不可红脸,不可出言不逊」

在「需求评审会」的现场难免会遇到各种意外的状况,不管发生了任何事,产品经理需要时刻谨记两个字「隐忍」,不管任何观点都要冷静客观的表达出来,千万不要没有控制好自己,把某些观点加上了自己的主观色彩,这样就把一件简单的事变的复杂了。

关于「需求评审」的三个阶段

第一阶段:「需求评审会」前

产品经理在这个阶段需要注意几点。

①提前3天与开发、测试、设计等团队沟通协调时间,确保关键角色都有时间可以参加,最后确定好「需求评审会」的时间安排,订好会议室,发出会议邀请,并拉好RTX工作讨论组周知大家。简单来讲就是:哪个版本、哪些人、在哪、开会。

②提前2天将「产品交互原型」、「产品需求文档」通过邮件及在RTX讨论组发文件的形式发送给与会成员,并严格要求与会成员必须抽时间查阅相关文档,并提出自己的问题。

③提前1天收集大家对于本次评审内容的问题,汇总好问题后逐一解答,以邮件的形式统一回复给大家。根据问题修改文档,最后再次提醒大家「需求评审会」的时间、地点。

这也就是「需求评审会」的黄金72小时。我们要利用好这72小时,提前做好准备,将会大大提高「需求评审会」的效率,而且可以有效降低产品经理被误伤和蹂躏的概率。

第二阶段:「需求评审会」中

「需求评审会」说白了就是一次面对面的「讨论会」,所以「中」这个环节是重中之重,不可怠慢。因为之前我们已经做了充足的准备,所以要放松一点,当成自己的「脱口秀」演讲就好了。

①告诉大家我们这个迭代要为用户讲一个什么故事(做什么),这个故事是怎么来的(为什么做),用户看完这个故事能得到什么(有什么价值)。这也是一个标准的背景和目标陈述的方式,切忌上来直接讲交互、讲功能,同时还要回想一下自己对于这次「需求评审会」的个人目标是什么。

②好了,我们进入到真正的主题了,开始讲解这个迭代的功能点、产品交互原型、产品需求文档,每个功能点逐一讲解,事无巨细,不要有任何遗漏。讲解的顺序一定是先从功能点开始,然后讲原型,最后才是需求文档,一个由点及面的过程。

这时候我们普遍会遇到这几种状况。

第一种:你认可我的方案,这种是最理想的状况,也是产品经理最期望的状况,撸起袖子开工就好了。

第二种:你认可我的方案,但你有更好的想法,这也是一个非常和谐的状况,整个屏幕满满的充满了爱,优化细节,只会让产品逻辑和策略变的更加完整,这种状况甚至要好过第一种。

第三种:你不认可我的方案,你有更好的想法,OK,我们在这个状况下先讨论下关于背景和目标,这些你是否认可呢?如果认可目标,那我们来听下你的方案,如果确实可行,我来调整,然后撸起袖子开干。如果不认可目标,我需要不断的说服你(这里需要控制时间),让你认可这个目标,然后再撸起袖子开干,只不过这种很少见到。

第四种:你不认可我的方案,但你也没有更好的想法,这个你确定这个人不是无间道吗?这种情况也非常少见。

③经历了暴风雨后,我们已经可以看到了一些曙光了,稍安勿躁,胜利是属于我们的。这时候「需求评审会」其实已经接近尾声了,只是要提一句,关于细节讨论颗粒度的问题,讨论双方必须站在同一个层面讨论,已经下结论的地方不再重复,只讨论同一个纬度的问题,不能我还在跟你讲功能需求,你已经在跟我讨论代码的指针应该放在哪里。

噢,对了,所有讨论的问题记得都写在本子上。

第三阶段:「需求评审会」后

①会后及时输出会议纪要,罗列清楚问题或者争议点,已经形成结论的地方就不再赘述,待确定的问题继续找相关负责人进行讨论,直到得出最后的结论。

②最后的最后,一封华丽丽的邮件周知给全部与会成员,邮件内容包括需求评审的争议点和结论,最最最重要的是要将更新后的需求文档发出来给大家。

③最后的最后的最后,督促开发、测试同学评估开发、测试周期,给出时间节点。

以上,一次费心费力的「需求评审会」终于完成了,从开始组织到最后的确认邮件,无一不饱含产品经理的汗水和泪水,但是一次好的「需求评审会」是会为产品的健康成长增加助力的,所以再多的付出都是值得的。

从目前实践来看,产品经理在「需求评审会」上最好的开场就是自我总结,并且送上酸奶。一般比较复杂的迭代,在开场的时候我都会先总结一下自己在上个版本中作为产品经理,自己的过失有哪些,不要琢磨这么做是不是丢面儿了,其实开发和测试同学也都非常关心产品,所以想知道产品层面决策有哪些是对哪些是错。而这种态度,是非常能够得到他们认可的。我们不是经常说,产品如人品吗?就是这个意思。

测试流程

 1.产品经理去客户现场进行需求调研,将调研后点需求整理成文档2.产品经理根据需求画原型3.产品经理叫上开发负责人、测试负责人进行一次小范围的需求评审,评审通过后将需求发给项目组成员(一般需求评审前一天发给... 查看详情

第六章:需求评审如何进行

...和需求评审。需求过滤1.需求分析不是所有需求都要做进产品,我们要根据公司和产品的定位,进行合适地分析和过滤。我们需要分析出用户需求所对应的本质,将其转化为产品能够提供的解决方案,即“将用户需求转化为“产... 查看详情

负责的产品经理是如何跟进需求落地的?

一个产品经理可以随时随地的知晓自己需求的进度,并且能够及时检验,是对产品负责的一个态度。 产品经理中打酱油的节点 最近负责的产品模块进入开发周期,需求评审、产品设计过一段落,是时候歇一口气的周期。往往很... 查看详情

一线大厂软件测试流程(思维导图)详解

...行一个需求的评审会议,评审什么?参考依据是产品说明书,由产品经理给出。负责这个项目的产品经理、测试、开发等相关人员参与需求评审会议,针对产品的需求进行一系列的评审。评审产品说明书上面的需... 查看详情

软件测试流程大厂的流程详解

...需求的评审会议,评审什么呢?一般参考依据是产品说明书,由产品经理给出。负责这个项目的产品经理、测试、开发等相关人员参与需求评审会议,针对产品的需求进行一系列的评审。主要两点如下: 查看详情

软件测试怎样做好需求评审?(代码片段)

...受需求时来评审需求是否合理。原则屁股决定脑袋,产品经理和软件开发者之间的立场不同,则关注点不同,这是需求产品经理和开发之间的矛盾的主要原因。好的产品经理思考的是软件的市场和背后的生意而不是用... 查看详情

互联网项目流程

 干系人步骤备注产品、项目经理项目立项 开发、测试、产品需求评审测试负责人安排相关测试人员参加;后续任何需求的变更都需要通知相关测试人员开发、测试制定开发、测试计划测试计划含:进行任务分工;评估测... 查看详情

研发经理职责总结

 研发经理做为开发团队与项目经理或产品经理之间的桥梁,对于项目的管理有着非常重要的作用。一个好的研发经理,能够让开发任务有序进行,为开发团队屏蔽外界干扰,同时也能有效提高团队的战斗力。  ... 查看详情

软件研发流程

...可运维、可测试…需求评审开发人员和产品经理进行需求评审会,对需求的合理性、可实现性、开发时间等进行评估需求追踪在需求的各个环节上建立需求关联和跟踪机制,确保需求的可追溯性需求变更内容包括:变... 查看详情

产品研发流程规范-参考

...求各方的意见,让需求挖掘的更加充分、更加彻底。 •产品排期:   1.产品经理在面对多个业务方提来的多个需求时,排优先级时,要站在公司大局的角度,按照各业务线的实际发展需要,合理安排优先级   2.如果在确定... 查看详情

软件项目研发流程该怎么规范

...程该怎么规范,让团队成员都能目标明确,步调一致,让产品迭代充满节奏感。本文基于笔者项目研发管理经验整理,希望起到抛砖引玉的作用,探讨高效团队的协作流程模式。1.协作流程图基本原则:所有问题可跟踪(需求、B... 查看详情

5.5.产品设计之项目管理

...需求阶段01.需求准备  02.需求内审  03.需求评审会  参与对象  求同存异(听老子的)评审什么  可能出现的问题:  解决思路:  小技巧-提 查看详情

互联网公司的完整开发流程是怎样的?

...f09;开发流程对于有自研系统的企业,程序员往往是和产品经理在battle。整体的开发流程涉及到的人员角色有:项目经理、产品、设计、后端开发、前端开发、运维、测试。2.1需求调研首先是需求调研阶段,这阶段由... 查看详情

需求分析与测试计划方案

需求分析参与人员:软件项目组所有成员,包括产品经理,开发经理,测试经理,系统工程师/架构师,开发工程师/程序员,美术工程师,测试工程师,项目经理,QA(质量监督人员),配置管理员。测试需求的特征:1、测试需求... 查看详情

产品经理的七宗罪(代码片段)

一直以来,产品经理与程序员之间就像是水与火般难以相融。许多初入社会的年轻开发,估计都曾动过要跟产品经理打一架的念想。但这种坏念头一定只能压抑在心底,不然会被产品经理们通过一系列抓手对需求的底... 查看详情

产品经理的七宗罪(代码片段)

一直以来,产品经理与程序员之间就像是水与火般难以相融。许多初入社会的年轻开发,估计都曾动过要跟产品经理打一架的念想。但这种坏念头一定只能压抑在心底,不然会被产品经理们通过一系列抓手对需求的底... 查看详情

软件测试流程详解

...。保证团队对需求理解的一致性。怎么做需求评审?需求评审会参会人员项目经理、产品经理开发人员,架构师测试工程师UI运维工程师DBA程师在需求评审中的主要职责是什么?确认自己对需求要有清晰的理解,没有疑惑。确认... 查看详情

如何培养合格的产品经理?

什么是产品经理?产品经理(ProductManager)为产品的市场成功负责,从创意到产品的上市并取得市场成功,所有相关的需求分析、调研、验证、产品的研发、制造、售后服务、营销方案和销售渠道等,都由产品经理掌握。产品经理... 查看详情