产品经理如何打好“需求评审”这场仗

上篇文章《产品功能调研,需要注意的3个要点》我们讨论了产品功能调研的相关知识,这一次我们来谈谈产品经理如何打好“需qiú评审”这场仗。

在产品经理岗位的能力要qiú中,其中两项是强大的心理抗压能力和良好的沟通能力。

因为产品经理很重要的一个职责就是与X的各个部门协调沟通,保证项目进展的有效性。工作中X的场景和同事涉猎面越广,就越容易被怼,在各部门同事云集的需qiú评审会中更是如此。

需qiú评审是产品经理工作中非常重要的一环,它决定着我们的想fǎ是否能够落地实现,也是产品经理被怼可能性最大的时候。

若准备不够充分,需qiú评审会可能演变成X起而攻之的XX,而被挂在X的对象就是产品经理和原型图。

以下列举了一些本人被怼的xuè和泪:

  • “在XX情况下,你没有做条件X呀,能不能考虑的全面点?”
  • “你这个liú程太麻烦了,用户能被你绕晕,能不能简单点?”
  • “现有的数据库结构不支持,要实现只能重构,太麻烦了!有时候你产品的一句话,开发要做一个月呀,兄嘚!”
  • “这样开发难度很大,最好基于现有的数据库结构考虑X拓展性,”
  • “这个功能cāo作好奇葩,哪有产品像你这么设计的”

需qiú评审的目的是让相关人员(开发、设计、测试、运营、老板等)理解需qiú背景、需qiú目的以及具体的需qiú描述,并认可原型设计和解决方案。

在需qiú评审中多多少少会碰到被怼的情况,那么作为产品经理,怎么才能使需qiú评审会保持高效,并在评审会中降低被怼的可能性呢?

一、需qiú评审前

俗话说“台上一分钟,台下十年功”,想要在需qiú评审会的有限时间内,保持高效且不被怼,必须做好充分的提前准备工作。

1. 充分准备原型和PRD

首先充分理解自己所负责的需qiú,不要一拿到需qiú,头脑一热就开始画原型。

先做需qiú分析和产品调研,梳理出功能架构和X逻辑,最好输出“Xliú程图”和“功能结构图”,图表比X更容易让人理解需qiú。

另外尽可能输出逻辑严密,表达清晰的原型和文档,尽量考虑到所有的边界场景,并提前和开发人员沟通,就需qiú的实现方案达成一致。

如果评审会中被挑出各种疏漏问题,不仅影响X的效率,而且会让同事质疑自己的X能力,也会成为以后工作中同事不积极配合的诱因。

zhēn对同一问题给出多个解决方案,这样在评审中,哪怕开发表示方案A不能实现,还可以补充提出方案B。

需qiú文档的表达要简洁,逻辑要严谨。有的X需qiú文档和原型是分开各一份;而有的X是需qiú文档直接写在Axure里面,直接备注在原型页面旁边(我目前用的后者)。

很多产品新人都会问哪种方式更好,其实不管哪种形式,要学会因地制宜。

说到底需qiú文档是给开发和测试人员看的,他们是需qiú文档的核心用户,产品经理要倾听用户的诉qiú,多询问他们的意见,如何能让他们更有效率的阅读需qiú文档,以及更容易理解需qiú文档中的表述。

2. 产品组内评审

在真正的需qiú评审会之前,一般情况下,要先对原型初版进行组内评审,原型初版一般不需要完整的需qiú文档,只需要标注出重点的交互和功能逻辑。

组内评审的目的是让组内产品X帮自己擦漏补缺,提前X出疏漏和不合理之处。

另外产品组内评审是基于用户体验5层要素(战略、范围、结构、框架、表现层)来审视原型和PRD,X产品设计的合理性

比如有时候在组内评审时,判断需qiú不符合当前产品的战略方向,应该暂缓或不实现。这是开发、设计、测试、运营都不太重视的维度。

3. 提前告知

在X组内评审之后,接下来就应该修改并完善原型和prd。

在需qiú评审会的前一天把原型和prd发送给参会的相关人员,目的是让其提前熟悉需qiú,达成目标上的一致性。

如果有问题及时收集,在需qiú评审之前向提问者解答,能大大提高需qiú评审会的效率。

二、需qiú评审中

需qiú评审会是一个极度频繁的场景,除了早上晨会,应该是初级产品经理开过最多的X。

只要我们提前做好了充分准备,就可以当作是个人的小型“产品分享会”。只有放松了,在讲解原型时也不会因为太紧张出现磕巴的状况。

1. 切记阐明背景和缘由

X首先要向大家阐明需qiú背景、需qiú目的,让他们了解这个需qiú是怎么产生的,需qiú是为了解决什么问题,让参会者了解并达成目标上的一致性,有助于理解X。

切忌一上来就讲功能、讲交互,导致参会者一脸懵bī,知其然不知其所以然,会影响X的效率和后续的项目进展过程。

2. 产生互动

目的是为了让参会者更专注的听评审,减少X室玩X的情况。

分享一个不成熟的小技巧,原型中的名称和内容示例,可以使用周遭同事的名字(他们不介意的前提下),并在讲解中念出名字,这样被Q到的的同事会放下X专心看投影仪,提高互动性和趣味性。

比如评论模块中的评论示例,可以这样在原型中标注:

运营廖小骊:昨晚吴亦凡被bào恋情了,你们看新闻了么?

开发yáng因:谁?

测试朱序:听说了,好大一个瓜,不过很快bào了另一个瓜!

设计雪琳:吴亦凡被套路了,好可怜

开发苏驰:谁……?

另外当讲到某个开发同事负责的功能时,可以与其产生互动,一个眼神示意或提及名字

比如评审时可以这样说:

  • “后端同学yáng因注意一下,CMSX新增了2个字段。需要配合前端超哥调你的接口。”
  • “UI同学瓜瓜注意下,这个X页面要有酷炫吊zhà天的动效,足够xī引用户的眼球”
  • “任务系统新增1个触发cāo作,需要后端同学苏驰在数据库加一下。”

这样互动可以很自然的打断玩X的同事,使其更专注,毕竟我们不能jìn止评审中玩X,万一别人是在XX消息呢~

沟通协调本就是产品经理工作中的常态,如果善用沟通技巧,可以提高我们的工作效率。

3. 泉衡轻重

讲解具体的页面、功能点和交互时,可以按照大纲结构依次讲解,事无巨细,不要有任何遗漏。

但由于评审会的时间有限,遇到不重要的点可以一句话概括,比如某个页面怎么排版,显示哪些字段。遇到重点的功能和X逻辑时就需要详细讲解。

注意!每讲解完一个模块,都要停顿下让大家提问,全部讲完时,也要简单回顾所有页面,让大家提问。

有的话当场提出当场解决,尽量让所有参会者在会上理清大致的Xliú程。可以大概率避免在开发、测试过程中,他们再来问自己讲过的逻辑,导致过多的打扰自己正常的工作。

想象一个场景,某天自己正在梳理思路,画原型时,一会儿开发A来确认某个会上讲过的逻辑,一会儿测试B来确认另一个问题。

如此一来,不仅我们要做很多次打断思路再连接的额外cāo作。结果可能是一天感觉原型没什么进展,时间基本都huā在和开发测试确认问题了。

至于一些排版、交互的细节问题,如该页面内容最多显示几行。可以会后再确认。

4. 把控时间节奏

评审中,有一种不幸,是参会人员对产品经理的解决方案提出质疑,就会进入“需qiú的讨论期”,没参与讨论的人员可能就会玩X。

若讨论期过久(建议最多不超过10分钟)仍没有达成一致,说明自己的解决方案多少是有问题的。这时候要主动提出停止讨论,会后考虑是否有更好的解决方案,同时与对应人员进行沟通。

另外,开发都会在评审会上讨论技术实现方案,我们要允许开发人员展开讨论,因为要确保需qiú是可以实现的。

有时候开发会下意识的将讨论延伸到具体开发细节,比如用H5,还是原生开发。从而导致讨论时间过长,我们要审时度势,及时制止,提醒开发可以会后再讨论。不要让需qiú评审会变成了技术X!

最后,需qiú评审涉及的人比较多,讨论经常会“跑题”,有时候话匣子一打开关不上,又扯到其他X上去,导致评审的效率很低。产品经理应该适当制止,把大家的思维拉回来。

5. 需qiú是X提的

在评审中,产品经理的内心活动几乎都是“希望一切顺利,没有人唱反调就完美了”。但往往事与愿违,产品经理时常会遇到有人唱反调的情况(对事不对人)。

比如,技术人员发出“这个实现起来太麻烦了”、“开发难度很大”的声音,这种情况一般都X着巨大的开发量。

因为需qiú评审前都会先XX或老板的审核,但也不建议直接丢出一句“这个需qiú是老板提的”,用老板这个X来反驳。这是不充分理解需qiú的表现,不做需qiú分析,拿到需qiú就埋头画原型。虽然这句话如尚方宝剑般,效果可能很好,但是不能让开发信服。

首先我们要泉衡会否值得这么大的开发量。如果确实值得,可以给开发人员“X”,强调需qiú的重要程度,实现这个需qiú可以创造什么用户价值,给产品带来什么收益。

以理服人,让开发人员没有理由拒绝。或者可以做适当的让步,表明需qiú必须实现,但可以接受较长的开发周期。

最好的结果就是需qiú没被砍,开发人员无奈的丢出一句:“可以实现,只是要排期……”。

6. 做好X记录

敲黑板啦,这里是重点,在X中一定一定一定要记录下争论的遗留问题。

或者让同事帮自己记录也可以。不然过后靠自己回忆或者找别人问,会很麻烦。有可能别人也想不起来就尴尬了。

三、需qiú评审后

1. 整理遗留问题,给出解决方案

评审结束后,整理并解决X中的遗留问题,若遗留问题太多,有必要进行二次评审。

X并修改原型和PRD,然后把最终版发送给相关人员。

2. 督促排期,X进度

督促项目经理进行排期,确认预估的开发周期和测试周期。

接下来不要以为就没事了,都说产品是产品经理的孩子,我们这些当爹X,难道我们怀了ta,给ta做了体检,就不负责把ta健康的生下来吗?

后续要持续跟进开发测试进度,直到上线。在跟进过程中,大概率上还有未考虑到的问题逐一浮现出来,产品要和开发测试紧X作,讨论新的解决方案,并同步修改原型和PRD。

四、反思

人类在很多时候分不清自己是“坚持X”还是“固执己见”,产品经理亦是如此。

在需qiú评审中遇到X观点,我们常常会不自觉产生自我保护意识,一味的进行反驳,却忘了需qiú评审的目的,决不妥协和轻易妥协似乎都不是好办fǎ。

产品经理应当具备同理心,用我bà常教育我的话就是“换个板凳坐”,学会在他人立场思考同一个问题,或许会有额外的收获。

需qiú评审对产品经理树立威信很有帮助,想要打好这场仗,就踏踏实实做好每一步。希望自己能在每一次需qiú评审后,都有一点点的进步。

感谢你的阅读!如果有不同想fǎ,欢迎交liú讨论。

收藏 (0) 打赏

以上内容不错,打赏支持一下!

打开微信/支付宝扫一扫,即可进行扫码打赏哦,分享从这里开始,精彩与您同在
点赞 (0)

声明:本站所有教程资源,如无特殊说明或标注,均为本站原创发布。任何个人或组织,在未征得本站同意时,禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益,可联系我们进行处理。

雄发创业网 自媒体是如何赚钱的 产品经理如何打好“需求评审”这场仗 https://www.xiongfawang.com/4417.html

常见问题

相关文章

产品经理如何打好“需求评审”这场仗-海报

分享本文封面