产品经理如何打好“需求评审”这场仗
上篇文章《产品功能调研,需要注意的3个要点》我们讨论了产品功能调研的相关知识,这一次我们来谈谈产品经理如何打好“需求评审”这场仗。
在产品经理岗位的能力要求中,其中两项是强大的心理抗压能力和良好的沟通能力。
因为产品经理很重要的一个职责就是与公司的各个部门协调沟通,保证项目进展的有效性。工作中接触的场景和同事涉猎面越广,就越容易被怼,在各部门同事云集的需求评审会中更是如此。
需求评审是产品经理工作中非常重要的一环,它决定着我们的想法是否能够落地实现,也是产品经理被怼可能性最大的时候。
若准备不够充分,需求评审会可能演变成群起而攻之的批斗大会,而被挂在十字架的对象就是产品经理和原型图。
以下列举了一些本人被怼的血和泪:
- “在XX情况下,你没有做条件限制呀,能不能考虑的全面点?”
- “你这个流程太麻烦了,用户能被你绕晕,能不能简单点?”
- “现有的数据库结构不支持,要实现只能重构,太麻烦了!有时候你产品的一句话,开发要做一个月呀,兄嘚!”
- “这样开发难度很大,最好基于现有的数据库结构考虑业务拓展性,”
- “这个功能操作好奇葩,哪有产品像你这么设计的”
需求评审的目的是让相关人员(开发、设计、测试、运营、老板等)理解需求背景、需求目的以及具体的需求描述,并认可原型设计和解决方案。
在需求评审中多多少少会碰到被怼的情况,那么作为产品经理,怎么才能使需求评审会保持高效,并在评审会中降低被怼的可能性呢?
一、需求评审前
俗话说“台上一分钟,台下十年功”,想要在需求评审会的有限时间内,保持高效且不被怼,必须做好充分的提前准备工作。
1. 充分准备原型和PRD
首先充分理解自己所负责的需求,不要一拿到需求,头脑一热就开始画原型。
先做需求分析和产品调研,梳理出功能架构和业务逻辑,最好输出“业务流程图”和“功能结构图”,图表比文字更容易让人理解需求。
另外尽可能输出逻辑严密,表达清晰的原型和文档,尽量考虑到所有的边界场景,并提前和开发人员沟通,就需求的实现方案达成一致。
如果评审会中被挑出各种疏漏问题,不仅影响会议的效率,而且会让同事质疑自己的专业能力,也会成为以后工作中同事不积极配合的诱因。
针对同一问题给出多个解决方案,这样在评审中,哪怕开发表示方案A不能实现,还可以补充提出方案B。
需求文档的表达要简洁,逻辑要严谨。有的公司需求文档和原型是分开各一份;而有的公司是需求文档直接写在Axure里面,直接备注在原型页面旁边(我目前用的后者)。
很多产品新人都会问哪种方式更好,其实不管哪种形式,要学会因地制宜。
说到底需求文档是给开发和测试人员看的,他们是需求文档的核心用户,产品经理要倾听用户的诉求,多询问他们的意见,如何能让他们更有效率的阅读需求文档,以及更容易理解需求文档中的表述。
2. 产品组内评审
在真正的需求评审会之前,一般情况下,要先对原型初版进行组内评审,原型初版一般不需要完整的需求文档,只需要标注出重点的交互和功能逻辑。
组内评审的目的是让组内产品同僚帮自己擦漏补缺,提前检查出疏漏和不合理之处。
另外产品组内评审是基于用户体验5层要素(战略、范围、结构、框架、表现层)来审视原型和PRD,检视产品设计的合理性。
比如有时候在组内评审时,判断需求不符合当前产品的战略方向,应该暂缓或不实现。这是开发、设计、测试、运营都不太重视的维度。
3. 提前告知
在通过组内评审之后,接下来就应该修改并完善原型和prd。
在需求评审会的前一天把原型和prd发送给参会的相关人员,目的是让其提前熟悉需求,达成目标上的一致性。
如果有问题及时收集,在需求评审之前向提问者解答,能大大提高需求评审会的效率。
二、需求评审中
需求评审会是一个极度频繁的场景,除了早上晨会,应该是初级产品经理开过最多的会议。
只要我们提前做好了充分准备,就可以当作是个人的小型“产品分享会”。只有放松了,在讲解原型时也不会因为太紧张出现磕巴的状况。
1. 切记阐明背景和缘由
会议首先要向大家阐明需求背景、需求目的,让他们了解这个需求是怎么产生的,需求是为了解决什么问题,让参会者了解并达成目标上的一致性,有助于理解业务。
切忌一上来就讲功能、讲交互,导致参会者一脸懵逼,知其然不知其所以然,会影响会议的效率和后续的项目进展过程。
2. 产生互动
目的是为了让参会者更专注的听评审,减少会议室玩手机的情况。
分享一个不成熟的小技巧,原型中的名称和内容示例,可以使用周遭同事的名字(他们不介意的前提下),并在讲解中念出名字,这样被Q到的的同事会放下手机专心看投影仪,提高互动性和趣味性。
比如评论模块中的评论示例,可以这样在原型中标注:
运营廖小骊:昨晚吴亦凡被爆恋情了,你们看新闻了么?
开发杨因:谁?
测试朱序:听说了,好大一个瓜,不过很快爆了另一个瓜!
设计雪琳:吴亦凡被套路了,好可怜
开发苏驰:谁……?
另外当讲到某个开发同事负责的功能时,可以与其产生互动,一个眼神示意或提及名字。
比如评审时可以这样说:
- “后端同学杨因注意一下,CMS后台新增了2个字段。需要配合前端超哥调你的接口。”
- “UI同学瓜瓜注意下,这个抽奖页面要有酷炫吊炸天的动效,足够吸引用户的眼球”
- “任务系统新增1个触发操作,需要后端同学苏驰在数据库加一下。”
这样互动可以很自然的打断玩手机的同事,使其更专注,毕竟我们不能禁止评审中玩手机,万一别人是在回复领导消息呢~
沟通协调本就是产品经理工作中的常态,如果善用沟通技巧,可以提高我们的工作效率。
3. 权衡轻重
讲解具体的页面、功能点和交互时,可以按照大纲结构依次讲解,事无巨细,不要有任何遗漏。
但由于评审会的时间有限,遇到不重要的点可以一句话概括,比如某个页面怎么排版,显示哪些字段。遇到重点的功能和业务逻辑时就需要详细讲解。
注意!每讲解完一个模块,都要停顿下让大家提问,全部讲完时,也要简单回顾所有页面,让大家提问。
有的话当场提出当场解决,尽量让所有参会者在会上理清大致的业务流程。可以大概率避免在开发、测试过程中,他们再来问自己讲过的逻辑,导致过多的打扰自己正常的工作。
想象一个场景,某天自己正在梳理思路,画原型时,一会儿开发A来确认某个会上讲过的逻辑,一会儿测试B来确认另一个问题。
如此一来,不仅我们要做很多次打断思路再连接的额外操作。结果可能是一天感觉原型没什么进展,时间基本都花在和开发测试确认问题了。
至于一些排版、交互的细节问题,如该页面内容最多显示几行。可以会后再确认。
4. 把控时间节奏
评审中,有一种不幸,是参会人员对产品经理的解决方案提出质疑,就会进入“需求的讨论期”,没参与讨论的人员可能就会玩手机。
若讨论期过久(建议最多不超过10分钟)仍没有达成一致,说明自己的解决方案多少是有问题的。这时候要主动提出停止讨论,会后考虑是否有更好的解决方案,同时与对应人员进行沟通。
另外,开发都会在评审会上讨论技术实现方案,我们要允许开发人员展开讨论,因为要确保需求是可以实现的。
有时候开发会下意识的将讨论延伸到具体开发细节,比如用H5,还是原生开发。从而导致讨论时间过长,我们要审时度势,及时制止,提醒开发可以会后再讨论。不要让需求评审会变成了技术研讨会!
最后,需求评审涉及的人比较多,讨论经常会“跑题”,有时候话匣子一打开关不上,又扯到其他业务上去,导致评审的效率很低。产品经理应该适当制止,把大家的思维拉回来。
5. 需求是领导提的
在评审中,产品经理的内心活动几乎都是“希望一切顺利,没有人唱反调就完美了”。但往往事与愿违,产品经理时常会遇到有人唱反调的情况(对事不对人)。
比如,技术人员发出“这个实现起来太麻烦了”、“开发难度很大”的声音,这种情况一般都代表着巨大的开发量。
因为需求评审前都会先通过领导或老板的审核,但也不建议直接丢出一句“这个需求是老板提的”,用老板这个靠山来反驳。这是不充分理解需求的表现,不做需求分析,拿到需求就埋头画原型。虽然这句话如尚方宝剑般,效果可能很好,但是不能让开发信服。
首先我们要权衡会否值得这么大的开发量。如果确实值得,可以给开发人员“洗脑”,强调需求的重要程度,实现这个需求可以创造什么用户价值,给产品带来什么收益。
以理服人,让开发人员没有理由拒绝。或者可以做适当的让步,表明需求必须实现,但可以接受较长的开发周期。
最好的结果就是需求没被砍,开发人员无奈的丢出一句:“可以实现,只是要排期……”。
6. 做好会议记录
敲黑板啦,这里是重点,在会议中一定一定一定要记录下争论的遗留问题。
或者让同事帮自己记录也可以。不然过后靠自己回忆或者找别人问,会很麻烦。有可能别人也想不起来就尴尬了。
三、需求评审后
1. 整理遗留问题,给出解决方案
评审结束后,整理并解决会议中的遗留问题,若遗留问题太多,有必要进行二次评审。
检视并修改原型和PRD,然后把最终版发送给相关人员。
2. 督促排期,跟踪进度
督促项目经理进行排期,确认预估的开发周期和测试周期。
接下来不要以为就没事了,都说产品是产品经理的孩子,我们这些当爹妈的,难道我们怀了ta,给ta做了体检,就不负责把ta健康的生下来吗?
后续要持续跟进开发测试进度,直到上线。在跟进过程中,大概率上还有未考虑到的问题逐一浮现出来,产品要和开发测试紧密合作,讨论新的解决方案,并同步修改原型和PRD。
四、反思
人类在很多时候分不清自己是“坚持真理”还是“固执己见”,产品经理亦是如此。
在需求评审中遇到反对观点,我们常常会不自觉产生自我保护意识,一味的进行反驳,却忘了需求评审的目的,决不妥协和轻易妥协似乎都不是好办法。
产品经理应当具备同理心,用我爸常教育我的话就是“换个板凳坐”,学会在他人立场思考同一个问题,或许会有额外的收获。
需求评审对产品经理树立威信很有帮助,想要打好这场仗,就踏踏实实做好每一步。希望自己能在每一次需求评审后,都有一点点的进步。
感谢你的阅读!如果有不同想法,欢迎交流讨论。
作者:Zss;微信公众号:Zss的写字屋
本文由 @Zss 原创发布于人人都是产品经理,未经作者许可,禁止转载。
题图来自Unsplash,基于CC0协议。
学习了
很棒,的确需求评审是产品经理的必修课,整的不好,大家就会对你失去信心。给作者赞一个
刚被怼完,就看到你这篇文章,哭了
😉 加油,再优秀的产品也会被怼,保持进步就好
昨天刚过完一场,头都炸了
受益匪浅~收藏了
写的太好了
感谢阅读 😳
让改变持续发生
厉害
很全面,很真实,赞👍
感谢
自己的评论不能删除……容错的体验有待优化
正在经历着这些血泪史
走难走的路,做自己害怕的事,时间长了你会觉得也不过如此。共勉
看到了自己的一些血泪经历。谢谢总结~
共勉
跟我们的需求评审流程基本一致,只是我们方案评审时会邀请开发参加,需求评审只需求组人员参加。需求交底时开发、测试才全部参加。需求交底时方案已经确定,基本不会被推翻,开发只能照着做。但我们都是异地研发,需求在B城,开发、测试在X城,互相不熟悉,被怼更是常有的事。只能如作者所说,提前做好充分的准备,尽量想好每一个细节,在需求评审和交底会上避免被怼。
很有道理。不同公司流程都不一样,因地制宜。方法论只是手段,目的是
高效落实需求评审
正在写需求文档就要面对的需求评审会了
很实用呢 😉
感谢 🙂
写的可以,不错啊!是作者自己的亲身体验吗?
谢谢夸奖。是本人一次次血泪史换来的经验