需求评审是产品设计流程中的必备环节。评审时,产品经理可能会遇到各种刁钻又犀利的问题,一不小心就变成了“撕逼现场”、“批判大会”。评审会似乎成了产品经理面临的一项挑战。
不过我认为只要认真准备,评审会没有那么可怕,只是产品经理成长过程中的一道槛儿而已,跨过去之后会很多事情就水到渠成了。
今天跟大家聊聊我对需求评审的理解。
更多需求相关干货:
我理解的产品需求评审实际包含两个环节——“需求评审”和“需求设计评审”。
1. 需求评审
实际工作中,产品绝不缺少“需求来源”。除了产品经理主动挖掘需求外,业务、市场、运营、客户、领导都会提各种需求。这些需求并不一定是真正符合产品定位的“需求”,甚至是“伪需求”。所以需要通过评审的方式把控产品需求,避免造成资源浪费。
需求评审属于产品规划层面,侧重于确认需求是否有价值,是否要实现,以及实现的优先级和版本计划等。需求汇聚到产品经理手中之后,大部分需求在产品团队内部评审后就可以确定,一些重大需求则需要向上汇报后确定。
当然不同的公司有不同的工作方式,有些公司的产品需求主要是产品 leader 和上级确定的,产品经理很少参与需求定义过程,只是接收需求,所以需求评审的工作并不多。
2. 需求设计评审
需求评审只是定义了需求是什么,但是实现方式有多种。B 端产品经理对需求理解更深入,为了方便沟通,减少需求传递过程的认知偏差,会直接产出产品原型。完成设计方案后,需要通过评审会确定设计是否满足产品需求,以及设计的合理性,这就是“需求设计评审”。
设计评审侧重于需求设计方案和实现逻辑的评审,一般包含团队内部评审和产品线评审。
内部评审主要是通过团队的力量查缺补漏,减少正式评审时可能遇到的阻力。对于 B 端产品,系统之间的关联性比较强,通过内部评审还可以拉通、对齐关联系统,实现系统间的有效联动。
产品线评审主要是面向业务方、技术团队,目标是确认设计方案,推动设计落地,评审中包含了大量设计细节的澄清。
需求设计评审是从设计转到开发非常重要的环节,如果方案问题较多,修改后需要进行二次评审。如果评审不充分、不到位,后续的开发测试容易出现各种意外,产品经理则要不断地填坑。
评审是很重要的一种信息拉通方式,不同公司对需求评审的重视程度不同,带来的工作结果也是千差万别。
1. 不要过度简化需求评审
有些公司产品需求主要是自上而下逐级传达而来,也就是大家常说“一句话需求”。产品经理接到来自上级的需求后,为了保证对需求理解的准确性,需要了解需求的背景、用户场景,拆解需求,挖掘需求的本质。转化成产品需求后,再去跟上级汇报确认产品需求是否正确。
沟通过程中,需求评审会就简化成了“需求确认”。这种方式的好处就是参与的人数少,比较容易达成一致。但是由于评审范围只是局限在产品经理和直属领导之间,很难收到更广泛的、大众的意见。尤其是有些需求并非来自直属领导,这种方式就无法保证需求的准确性。
我就曾经经历过这种情况,本以为需求已经确认过了,不会再有大的分歧了。但是沟通范围扩大后,仍然有不同的意见,甚至从根本上推翻了产品需求。
所以对于一些小需求可以简化需求评审的形式。但是对一些重大需求,还是要拉上相关的评审人员,尤其是需求提出人,这样才能达到评审效果,避免后期出现不必要的扯皮。
2. 注意向上汇报与向下落地的差异
正常流程下,需求设计评审是面向技术人员的。不过对于一些重要的产品需求,领导比较关心实现效果,产品经理还要将设计方案向上汇报。评审通过后,才能推进需求开发。
面向领导汇报和面向技术实现还是存在较大区别的。
1)向上汇报
为了方便领导做决策或者指出修改方向,产品经理最好准备 2-3 个方案。同时需要准备大量的材料作为设计方案的铺垫,比如流程图、数据分析、竞品报告等。
这些材料的目的是让领导了解设计依据,让后续的设计表述有理有据,增加领导对设计方案的信心。汇报时,这些材料重点讲解结论即可,不需要做细节阐述、达成一致,领导感兴趣时会主动发问。
如果评审过程中领导对设计点有疑问时,这些材料还可以成为重要的佐证。
2)向下落地
评审会是对完整设计方案的评审,不是技术讨论会。上会的设计方案必须是明确的,能够有效地指导开发工作。如果设计方案时存在技术上的疑问,产品经理要及时与技术人员确认解决,不要带到评审会上讨论。否则设计评审会就容易变成需求、技术讨论会。
面向技术的设计评审会,核心目标是对齐需求、传达设计方案。评审会前要消除 80% 的分歧和问题,评审会上对 20% 的问题查缺补漏,完成方案优化迭代。
3. 要自信、冷静
评审时面对各个团队的同事甚至领导,产品经理要保持自信、冷静,这样才能让自己从容地应对别人的质疑。人在着急、紧张的情况下,思路容易混乱,反而让自己的思路不完整,缺乏条理性。当然自信是建立在充分准备的基础上,盲目自信也不可取,该认怂时就要认怂。
如果确实无法做到自信冷静,可以在正式评审前自我预演一遍,逐步建立自己的自信心。
4. 实事求是、经得起质疑
无论评审前如何充分准备,过程中总会遇到意想不到的场景。这很正常,也是评审会的意义所在。如果会上可以解决的,那就当场弥补。如果无法解决就记录下来,作为遗留问题会后解决。不要欲盖弥彰,大家的眼睛都是雪亮的。后期开发阶段暴露出来,问题会更严重。
5. 学会倾听
评审会是交流沟通的机会,产品经理既要把自己的思路、方案输出给参会人员,也要能够接收、倾听别人的意见,这样才能了解别人的想法。千万不要别人一提问题就着急,要通过摆事实、讲道理去化解别人的疑问。
6. 做好评审会议控制
设计评审会人数通常比较多,大家各抒己见,思维会比较活跃,可能会激发出很多奇思妙想,造成会议跑题。产品经理要及时控制会议讨论的范围,保证会议的效率。
评审会后还有后续的跟进,这些细节就不一一赘述了。
需求评审会可以看作是产品设计的总结和记录,甚至是产品的提前预演,也是个人能力的重要组成部分,值得不断总结和提升。
不过相对于评审过程中的各种技巧,我觉得设计阶段的充分准备和日常工作中的有效沟通更加重要。好比是人已经上了战场,才想起来要磨枪,其实一切都晚了。
祝愿大家评审会顺利、丝滑~
欢迎关注作者微信公众号:「子牧UXD」
复制本文链接 文章为作者独立观点不代表优设网立场,未经允许不得转载。
发评论!每天赢奖品
点击 登录 后,在评论区留言,系统会随机派送奖品
2012年成立至今,是国内备受欢迎的设计师平台,提供奖品赞助 联系我们
AI时代的设计师生存手册
已累计诞生 642 位幸运星
发表评论 已发布2条
↓ 下方为您推荐了一些精彩有趣的文章热评 ↓