起点学院课程

如何让PM完成需求评审而不被打?

1 评论 8402 浏览 19 收藏 15 分钟
15天0基础极速入门数据分析,掌握一套数据分析流程和方法,学完就能写一份数据报告!了解一下>>

编辑导读:需求评审是每个产品经理都躲不过的一项工作,如何做好这项工作可大有学问。本文将从三个方面展开分析,对需求评审感兴趣的童鞋不要错过哦。

如果说产品经理的生涯是一条修炼之路,那么需求评审就是产品汪躲不过的劫。

做不好需求评审的产品经理,很可能会对产品生涯产生阴影,因为每一次需求评审都是对产品经理的多人毒打。

心态好的产品经理能每次爬起来完成蜕变,而心态不好的产品经理,很可能会被实力劝退。

尤其是对于新手产品经理,或者是新加入一个团队的产品经理来说,第一次需求评审将决定你在团队中的印象,也将决定你日后的日子是苦是甜。

如何让产品汪完成需求评审而不群殴,本文从需求评审前,中,后三步来谈一下我工作中得到的经验。

一、需求评审前

正式需求评审前,一定要进行一次需求预审。

大事都是在小会上决定的,而大会只是做一个详细通知和布置具体的任务。

需求预审的参加对象,是产品经理、前端主管、后台主管,一般三个人即可,或者是前后台的开发主力。

预审的目的有两个:

  1. 明确需求能不能实现
  2. 验证需求文档的主要逻辑没有问题

明确需求是否可以实现。有时候一些想偷懒的开发,面对一些复杂的需求,就会以“这个做不了”来推脱。

这个时候,你把预评审的结论说出来,他也就熄火了,就不至于陷入扯皮的尴尬。

验证需求文档的主要逻辑。大会评审的时候,如果主要逻辑出现了问题,那基本上可以确定要再进行一轮评审,这样不仅浪费了大家的时间,还可能让自己被贴上不靠谱的标签。

需求评审前,一定要提前发评审邀请。可以是邮件,也可以直接在工作群邀约。

但是一定要有提前量,这样可以让开发预习一下,提前把问题准备好,提高大会评审效率。

评审邀请,如果是写邮件,发送邮件前,也最好在群里跟大家约一下时间,免得出现时间冲突的情况。

邀请邮件的内容一般包括:

  • 需求的背景,便于理解
  • 需求的功能列表(不需要太细)
  • 需求文档链接,看团队习惯
  • 会议主体、会议时间、地点和参与人员

邮件发完以后,记得在群里和大家同步一声,免得有人漏掉邮件。

二、需求评审中

需求评审的步骤大致如下:

并不是每次需求评审都需要完全按照这个流程,比如是迭代型的需求,就不需要走第二步。

需求评审,本质上就是沟通,用语言配合原型文档的方式,将需求清晰的表述出来。所以,一定要明白我们和其他人之间,肯定存在知识诅咒。

所以,不要一开始就讲细节,不要一开始就讲细节,不要一开始就讲细节。

细节是永远都扣不完的,如果在会议上陷入细节的讨论,不仅浪费时间,而且对于产品经理来说也会非常痛苦。

因为总有一些细节是你没有想到的,而且你会发现,一到这种时候,大家都非常兴奋。

因为谁都会挑毛病,而且大家都非常乐意挑别人的毛病。所以不要找不自在。

而且陷入细节的需求评审,会显得毫无逻辑。大家很容易一脸懵逼,特别是对于没有提前看过文档的同学(不幸的是,大部分同学都不会提前看文档)。

在正式讲解需求之前,一定要先明确本次会议的主题,会议需要完成达成哪些目的。主要事项有哪些,让大家心里有底。这也是串起整个会议的主线。

正式开始需求评审后,首先要做的,就是要和大家达成一项共识:为什么要做本次迭代。也就是这些需求能带来哪些价值。

而不是说那句表面上让大家无法拒绝,但是实际会非常掉底子的一句话:这是老板的需求。

一般的需求价值包括:

  • 需求符合公司的战略目标吗?
  • 需求能带来直接的收益吗?
  • 需求能提升用户体验吗?
  • 需求能提高效率或节省成本吗?

和团队成员达成共识的目的,是为了防止大家出工不出力。和大家就这些需求的价值达成一致,有助于更好的完成需求开发。

毕竟一个人从内心认可一件事的动力,和因为外力强迫不得不做的动力,那是天壤之别。

讲解需求要从整体到局部。不要一开始就扎到细节里,否则大家也会跟着你去抠细节。

而需求评审并不是抠细节的,需求评审的主要目的是:

  • 传递需求的价值,让大家认可这个需求可以做,而不是被强迫
  • 传递功能的场景,让大家理解功能所覆盖的用户和使用的场景
  • 明确需求实现的方式,划分大致的任务和排期

我们要先从整体对需求的流程做一个梳理。一般都是从用户的角度,对用户使用这个功能的流程进行一个整体的梳理。

就像你在看一本书时,当读到一半的时候,就忘记之前是讲什么的了。

我们会发现很难将书中的知识串起来,这个时候往往都会选择打开目录,通过看目录来帮我们回忆起之前的章节内容,从而将这些内容都串联起来。

需求评审如何从整体开始?我们以优惠券需求为例。

评审优惠券相关的需求,就可以从优惠券的创建、优惠券发布、优惠券领取、优惠券消费。

这四个大的步骤进行整体的概况说明。以此为需求评审的主线,这样大家在听你讲解具体需求的时候,不至于迷失在细节之中。

接下来,描述该功能的使用场景。我认为产品经理,最强大的软实力,就是讲故事的能力。

如何用一个故事把自己的想法表达清晰,让大家易懂,并且得到大家的一致认可,是产品经理最难能可贵的能力。

在讲解具体功能逻辑之前,可以先描述下具体的功能使用场景。

这样有利于大家理解这个功能:

  • 功能的用户是谁?
  • 用户通常在什么场景下使用这个功能?
  • 用户当前在这个场景下遇到了什么困难?
  • 我们的功能是怎样帮助用户解决问题的?

以场景的角度来描述功能,同时也是进一步让大家理解做这个功能的价值所在。

而且产品经理在思考功能的使用场景时,也是进一步思考是否有必要做这个功能?怎么做这个功能才更好的机会?

而且,让大家明确该功能的场景,有时候会有惊喜。有时候对于一些你认为比较复杂的功能,大家在明确背景的情况下,有可能可以想到更简单的方案。

详略得当,不要毫无重点地长篇大论。哪些该讲?哪些不该讲?

这个要看团队之间的默契。如果是初期合作,大家都不太了解彼此的时候,建议要尽量详细。

不要自以为某些功能很常见,例如输入框的一些交互,就省略不讲,到最后开发没做,就只能自己背锅。

对于配合默契的团队,可以根据团队的习惯,忽略掉一些以前做过的东西,或者一些常见的东西,比如输入框的校验规则等。

回答并记录问题。需求评审大家肯定会提出很多问题,有的是质疑需求的必要性,有的是指出需求的不完整,或逻辑的缺失,有的是讨论需求的实现方式等。

有的问题可以直接回答,例如需求的逻辑问题,实现问题,必要性问题等。

而有的问题则可以不回答,例如自己没有想清楚的问题,一些比较细节的问题,而且这些细节不涉及其他同学,会后单独私聊就可以解决的。

自己没有想清楚的问题,千万不要因为要面子强答,那只会让自己更丢脸。

如果是简单的问题,可以直接想一下然后回答。

如果是稍微复杂的问题,或者被问住了的问题,要及时认怂,承认自己事先没有想好,先记录下来,会后考虑清楚以后再同步给大家。

在评审过程中,作为会议的主讲人,不仅要传达完整清晰的传达需求,还要控制会议的节奏,不要让会议陷入抠细节的状况,更不要让会议跑偏。

发现有的同学喜欢抠细节,要及时制止,并建议在会后和他详细讨论。如果是跑偏,要及时将大家的注意力拉回来。

会议最后要形成会议结论。

会议结果无非两种,成功和失败。若会议成功,那大家就分配下一步工作。

若会议不成功,有一些需求逻辑待进一步梳理,那就约定由谁来梳理,什么时候完成并重新组织评审。

一定要有结论,谁干什么,什么时候交付,交付物是什么,都要定义清楚。

如果只定义了负责人,但是没有定义交付时间,就会造成拖延,大学生综合征就是典型。

如果没有定义负责人,到最后,这件事大家都不会去做,三个和尚没水喝。

如果没有定义交付物,那他到底做还是没做,就没有一个可以衡量的结果,容易变成嘴炮。

三、需求评审后

需求评审后还不是结束,需要做两件事:

1. 将会议上记录的问题,一个一个落实

需求该修改的地方修改,该找人落实细节的找人落实细节,并且修改好以后,要以邮件的形式及时同步给大家,并且在群里进行简要提醒和说明。

必要的话,可以组织小范围的二次需求评审。

2. 需求评审复盘

记录每次需求评审,大家提出来的问题。将这些问题进行分类统计。

哪些是自己经常忽略的问题,哪些是自己经常被问到的问题,哪些自己明明说了,但是大家还是会问的问题等。

对自己的每次需求评审都做一次复盘,总结自己没有讲好的地方,讲的好的地方,下次该如何改进等。

有的同学说,需求评审的时候忙着回答问题,哪有时间进行记录。

办法总比困难多,你可以每次找一位产品同事帮忙记录(他评审的时候,你帮他记录),或者买一只录音笔录音,这都是好方法。

最后,总结一下:

需求评审前,尽量先进行一次预评审,并提前发出会议邀请,将需求文档等资料提前发给大家熟悉。

需求评审中,会议一开始就要明确本次会议的主题和目的,需求讲解,要从整体到局部,具体的功能讲解从背景开始。

最后,会议一定要形成结论。另外,谨记:一定不要陷入细节!

需求评审后,将会议上的问题一个一个解决,将分配给或需要自己配合的任务一项一项推动。

另外,坚持对每一次需求评审进行复盘,明白自己的问题和优势,有针对性的改进和提高。

 

本文由 @Jarvan 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
起点学院课程
评论
评论请登录
  1. 学习了

    回复