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

Zss
25 评论 17648 浏览 175 收藏 16 分钟

上篇文章《产品功能调研,需要注意的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协议。

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

    来自广东 回复
  2. 很棒,的确需求评审是产品经理的必修课,整的不好,大家就会对你失去信心。给作者赞一个

    来自浙江 回复
  3. 刚被怼完,就看到你这篇文章,哭了

    来自广东 回复
    1. 😉 加油,再优秀的产品也会被怼,保持进步就好

      来自四川 回复
  4. 昨天刚过完一场,头都炸了

    回复
  5. 受益匪浅~收藏了

    回复
  6. 写的太好了

    来自柬埔寨 回复
    1. 感谢阅读 😳

      来自四川 回复
  7. 让改变持续发生

    回复
  8. 厉害

    回复
  9. 很全面,很真实,赞👍

    回复
    1. 感谢

      回复
  10. 自己的评论不能删除……容错的体验有待优化

    回复
  11. 正在经历着这些血泪史

    回复
    1. 走难走的路,做自己害怕的事,时间长了你会觉得也不过如此。共勉

      来自四川 回复
  12. 看到了自己的一些血泪经历。谢谢总结~

    来自福建 回复
    1. 共勉

      回复
  13. 跟我们的需求评审流程基本一致,只是我们方案评审时会邀请开发参加,需求评审只需求组人员参加。需求交底时开发、测试才全部参加。需求交底时方案已经确定,基本不会被推翻,开发只能照着做。但我们都是异地研发,需求在B城,开发、测试在X城,互相不熟悉,被怼更是常有的事。只能如作者所说,提前做好充分的准备,尽量想好每一个细节,在需求评审和交底会上避免被怼。

    来自北京 回复
    1. 很有道理。不同公司流程都不一样,因地制宜。方法论只是手段,目的是

      回复
    2. 高效落实需求评审

      回复
  14. 正在写需求文档就要面对的需求评审会了

    来自广东 回复
  15. 很实用呢 😉

    来自江苏 回复
    1. 感谢 🙂

      来自四川 回复
  16. 写的可以,不错啊!是作者自己的亲身体验吗?

    回复
    1. 谢谢夸奖。是本人一次次血泪史换来的经验

      回复