谈谈我对需求评审的理解

2 评论 3689 浏览 23 收藏 11 分钟

在产品设计流程中,需求评审是必备环节之一,那么,产品经理要怎么确保需求评审的顺利进行呢?这篇文章里,作者就结合自己的经验,谈了谈自己关于需求评审的理解,或许会对你有所帮助。

需求评审是产品设计流程中的必备环节。评审时,产品经理可能会遇到各种刁钻又犀利的问题,一不小心就变成了“撕逼现场”、“批判大会”。评审会似乎成了产品经理面临的一项挑战。

不过我认为只要认真准备,评审会没有那么可怕,只是产品经理成长过程中的一道槛儿而已,跨过去之后会很多事情就水到渠成了

今天跟大家聊聊我对需求评审的理解。

一、什么是需求评审?

我理解的产品需求评审实际包含两个环节——“需求评审”和“需求设计评审”。

1. 需求评审

实际工作中,产品绝不缺少“需求来源”。除了产品经理主动挖掘需求外,业务、市场、运营、客户、领导都会提各种需求。这些需求并不一定是真正符合产品定位的“需求”,甚至是“伪需求”。所以需要通过评审的方式把控产品需求,避免造成资源浪费

需求评审属于产品规划层面,侧重于确认需求是否有价值,是否要实现,以及实现的优先级和版本计划等。需求汇聚到产品经理手中之后,大部分需求在产品团队内部评审后就可以确定,一些重大需求则需要向上汇报后确定。

当然不同的公司有不同的工作方式,有些公司的产品需求主要是产品 leader 和上级确定的,产品经理很少参与需求定义过程,只是接收需求,所以需求评审的工作并不多。

2. 需求设计评审

需求评审只是定义了需求是什么,但是实现方式有多种。B 端产品经理对需求理解更深入,为了方便沟通,减少需求传递过程的认知偏差,会直接产出产品原型。完成设计方案后,需要通过评审会确定设计是否满足产品需求,以及设计的合理性,这就是“需求设计评审”。

设计评审侧重于需求设计方案和实现逻辑的评审,一般包含团队内部评审和产品线评审。

内部评审主要是通过团队的力量查缺补漏,减少正式评审时可能遇到的阻力。对于 B 端产品,系统之间的关联性比较强,通过内部评审还可以拉通、对齐关联系统,实现系统间的有效联动。

产品线评审主要是面向业务方、技术团队,目标是确认设计方案,推动设计落地,评审中包含了大量设计细节的澄清。

需求设计评审是从设计转到开发非常重要的环节,如果方案问题较多,修改后需要进行二次评审。如果评审不充分、不到位,后续的开发测试容易出现各种意外,产品经理则要不断地填坑。

二、我的一些经验

评审是很重要的一种信息拉通方式,不同公司对需求评审的重视程度不同,带来的工作结果也是千差万别。

1. 不要过度简化需求评审

有些公司产品需求主要是自上而下逐级传达而来,也就是大家常说“一句话需求”。产品经理接到来自上级的需求后,为了保证对需求理解的准确性,需要了解需求的背景、用户场景,拆解需求,挖掘需求的本质。转化成产品需求后,再去跟上级汇报确认产品需求是否正确。

沟通过程中,需求评审会就简化成了“需求确认”。这种方式的好处就是参与的人数少,比较容易达成一致。但是由于评审范围只是局限在产品经理和直属领导之间,很难收到更广泛的、大众的意见。尤其是有些需求并非来自直属领导,这种方式就无法保证需求的准确性。

我就曾经经历过这种情况,本以为需求已经确认过了,不会再有大的分歧了。但是沟通范围扩大后,仍然有不同的意见,甚至从根本上推翻了产品需求。

所以对于一些小需求可以简化需求评审的形式。但是对一些重大需求,还是要拉上相关的评审人员,尤其是需求提出人,这样才能达到评审效果,避免后期出现不必要的扯皮。

2. 注意向上汇报与向下落地的差异

正常流程下,需求设计评审是面向技术人员的。不过对于一些重要的产品需求,领导比较关心实现效果,产品经理还要将设计方案向上汇报。评审通过后,才能推进需求开发。

面向领导汇报和面向技术实现还是存在较大区别的。

1)向上汇报

为了方便领导做决策或者指出修改方向,产品经理最好准备 2-3 个方案。同时需要准备大量的材料作为设计方案的铺垫,比如流程图、数据分析、竞品报告等。

这些材料的目的是让领导了解设计依据,让后续的设计表述有理有据,增加领导对设计方案的信心。汇报时,这些材料重点讲解结论即可,不需要做细节阐述、达成一致,领导感兴趣时会主动发问。

如果评审过程中领导对设计点有疑问时,这些材料还可以成为重要的佐证。

2)向下落地

评审会是对完整设计方案的评审,不是技术讨论会。上会的设计方案必须是明确的,能够有效地指导开发工作。如果设计方案时存在技术上的疑问,产品经理要及时与技术人员确认解决,不要带到评审会上讨论。否则设计评审会就容易变成需求、技术讨论会。

面向技术的设计评审会,核心目标是对齐需求、传达设计方案。评审会前要消除 80% 的分歧和问题,评审会上对 20% 的问题查缺补漏,完成方案优化迭代。

3. 要自信、冷静

评审时面对各个团队的同事甚至领导,产品经理要保持自信、冷静,这样才能让自己从容地应对别人的质疑。人在着急、紧张的情况下,思路容易混乱,反而让自己的思路不完整,缺乏条理性。当然自信是建立在充分准备的基础上,盲目自信也不可取,该认怂时就要认怂。

如果确实无法做到自信冷静,可以在正式评审前自我预演一遍,逐步建立自己的自信心。

4. 实事求是、经得起质疑

无论评审前如何充分准备,过程中总会遇到意想不到的场景。这很正常,也是评审会的意义所在。如果会上可以解决的,那就当场弥补。如果无法解决就记录下来,作为遗留问题会后解决。不要欲盖弥彰,大家的眼睛都是雪亮的。后期开发阶段暴露出来,问题会更严重。

5. 学会倾听

评审会是交流沟通的机会,产品经理既要把自己的思路、方案输出给参会人员,也要能够接收、倾听别人的意见,这样才能了解别人的想法。千万不要别人一提问题就着急,要通过摆事实、讲道理去化解别人的疑问

6. 做好评审会议控制

设计评审会人数通常比较多,大家各抒己见,思维会比较活跃,可能会激发出很多奇思妙想,造成会议跑题。产品经理要及时控制会议讨论的范围,保证会议的效率。

评审会后还有后续的跟进,这些细节就不一一赘述了。

三、总结

需求评审会可以看作是产品设计的总结和记录,甚至是产品的提前预演,也是个人能力的重要组成部分,值得不断总结和提升。

不过相对于评审过程中的各种技巧,我觉得设计阶段的充分准备和日常工作中的有效沟通更加重要。好比是人已经上了战场,才想起来要磨枪,其实一切都晚了。

祝愿大家评审会顺利、丝滑~

专栏作家

子牧先生,公众号:子牧UXD(HelloDesign),人人都是产品经理专栏作家。产品体验设计师。8年互联网行业经验,擅长体验设计思维、设计方法论、交互设计研究。

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

题图来自 Unsplash,基于 CC0 协议。

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 公司直接给评审砍了,领导同意了直接开发…

    来自浙江 回复
    1. 我们反正是领导做最终决策

      来自新加坡 回复