起点学院课程

如何高效完成需求评审?

1 评论 9756 浏览 54 收藏 12 分钟
15天0基础极速入门数据分析,掌握一套数据分析流程和方法,学完就能写一份数据报告!了解一下>>

需求评审,是每一个产品经理几乎每周都会经历的过程。只要工作在进行,产品在迭代,新需求在不断产生,就会有需求评审。

在需求评审会议上,前端、后端、测试、UI、你的老板可能都会过来,不同的角色聚在一起,听产品经理讲需求内容。这不是一件容易的事情,如何高效完成需求评审,对每一个产品经理来说,都需要去仔细琢磨,也是必须得掌握的基本功。今天我就跟大家聊聊这个话题。

01

先说下背景故事。

春节后因为疫情的影响,我在家办公差不多有三周左右。因为是远程,导致日常很多需要组会沟通的事情,现在都通过文档的离线沟通完成。

因此,对于我来说,也有了非常完整的时间去思考和设计Q1计划完成的一个大项目。在之前的文章里也提高过,是赠品系统。

这个系统最终的产品原型,包括两个后台模块和两个C端页面,非常复杂。PRD完成之后,连我自己都惊呆了,快赶上一篇小论文了。

但就是这么多内容,需要在1个小时左右的时间内,跟相关团队讲清楚,将需求完成地交付到研发阶段。幸运的是,我完成得还算可以,尤其在远程办公的情况下。

今天我就以这个项目为例子,给大家说说,如何高效完成需求评审。

02

关于需求评审要传递的信息,其实包含了非常简单的一套逻辑:价值、功能、实现。

  • 价值:为什么要做这个需求,上线之后的价值是什么。
  • 功能:为了支撑这个价值,需求包含了哪些功能呢。
  • 实现:针对每一个功能,该怎么实现。

比如说我做一个给老板用的数据看板,价值就是使得老板可以随时了解项目进度,功能是需要呈现A、B、C等三个维度的数据,实现就是每个数据的口径是什么,数据在看板上如何分布,以什么样的图表形式呈现。

而关于需求本身,又大致可以分为:功能优化,功能拓展,新项目。不同类别的需求,在评审会上传递的信息重点不太一样。

  1. 功能优化:重点在讲清楚如何做,往往评审时间较短,不会单独组会,跟着其他需求一起评审。
  2. 功能拓展:重点在讲清楚是什么,与原有功能的联系是什么,可能要单独组会。
  3. 新项目:重点在讲清楚为什么要立这个项目,项目包括哪些模块,模块间的联系是什么,每个模块的功能及实现。

所以从信息量上来说,新项目的评审是密度最高的,也是最考验表达逻辑及评审效率的。我理解的高效评审,是向协作团队传达出了统一的项目价值,能够让他们理解彼此的角色,任务及需要落地的行动,最关键的,彼此角色之间的关联是什么。

我们都能理解,人对新事物的信任感是相对低的。产品经理在需求评审会上最重要的任务,是帮助大家建立这种信任感,传递两个信号:这个事儿值得做;这个事儿能做。

下面我重点说说新项目在做需求评审时,如何可以更高效。

03

第一,用最直接的方式说明需求价值

产品经理是了解需求价值的,但这远远不够,你需要让协作团队也了解需求价值。但协作团队往往没有像你一样,对需求背景做过很多调研。

怎么样在最短的时间内传递清楚需求的价值呢?量化指标,数字切入。

比如说赠品系统,这个系统的价值也很多种描述方式:效率提升啦,解决了以前的某个行业问题啦,老板很关注啦等等,但这些不够直接。

想在最短时间内说明这个系统很重要,你得知道这是多大规模的盘子。什么意思,你得调研清楚,一家零售超市一年的赠品营销规模是多少,你的项目,直接关联多大规模的盘子。把这个数字摆出来,需求的价值就一目了然了。

第二,说明为需求设计方案之前的准备工作

这是我以前工作中容易忽略的一步,但最近一段时间以来很重视的一点。前面说过,人对新事物的信任感是相对低的。同理,协作团队对新项目的信任感也是相对低的,他们会经常怀疑产品经理——

  1. 这是不是老板需求,而你只是一个执行者的角色;
  2. 这是一个确定的需求,还是你拍脑门想出来的;
  3. 最关键的,这件事情,你作为产品经理有没有想清楚或者为此做过一些准备。

所以,准备工作及相关的核心结论,有必要在评审会上同步。例如做过哪些竞品调研;公司战略层有一些什么指示;跑过的一些测试case,有没有什么核心结论。

这一步的重点不在于让需求变得更清晰,而在于提升协作团队对新需求的信任感——我,产品经理,在组织今天的评审会之前,已经做了不少相关准备工作,这件事情,我是想清楚了的。

第三,逻辑+模块的表达方式

我听过一些产品讲需求评审,或是对着PRD讲,或者对着原型一张图一张图地讲。但老实说,这种方式不适合新项目的评审。

新项目因其内容密度大,往往会产生“听不懂+不知道现在讲到哪一步了”这样的负面效果。本质上都是因为,没有在听众脑中建立起逻辑主线。

我自己在设计赠品系统的时候,会有一个逻辑链,链上每个关键节点便是一个产品模块,所以先讲清楚逻辑链,再讲每个链上的产品模块,是比较好的表达方式。

就好比我自己看论文的时候,先看目录,再看每个章节,看到难懂的地方,时不时回到目录来,看看现在到哪一步,渐渐地就搞懂了。

同样的,新项目的需求评审就是你带着协作团队一起看论文的过程。先介绍目录,再介绍每一章的具体内容,遇到卡点,回顾一下目录,告诉大家我们现在在讲的内容处于什么位置。这样反复强调,逻辑链立住了,需求评审就成功了一大半。

第四,上帝视角与用户视角的结合

我们知道,关于产品有两个常用的视角,上帝视角和用户视角。前者是产品经理在设计方案时常用到的,后者是用户从进入产品的一刹那,到最终退出,所经历的完整过程。

就拿开车举例,上帝视角是我出发之前,在地图上看到的线路,我大概知道整段路程多远,大概要多久,在哪些路段可能会堵。用户视角,就是我出发后所看到的每一个路口,斑马线,红绿灯等,直到最终我到达了目的地。

开车的时候,司机会听导航,但也会看路。所以介绍需求的时候,我建议产品经理也结合上帝视角和用户视角穿插来讲。

比如我在介绍赠品系统的时候,既要说明逻辑、模块、功能等上帝视角的概念,也会从一个具体配置人员的角度,或者门店执行人员的角度,讲一讲他们该如何使用这个系统。

只说上帝视角,不容易理解,别人理解起来困难;只说用户视角,太零碎,不容易记住主线。结合起来,就能最快帮助协作团队理解,这个事儿是什么,该怎么做。

最后一点,学会区分听众的提问

我们要明白,在一个小时的时间里,完全讲清楚一个新项目,几乎是不可能的,即使你讲得完,听众也一定消化不了。这必然会导致,当你讲完之后,一堆问题接踵而至。

这时候产品经理需要学会判断,什么样的问题该当场解答,什么样的问题下来私聊。

我个人的建议是,如果一个问题满足以下若干条件之一,你得当场解决了:

  1. 关乎价值,关乎为什么做;
  2. 关乎完整性,这个问题不解决,整个产品逻辑跑不通;
  3. 会带来联动效应。

比如一个问题,如果跟前端、后端、UI都有关系,那你得当场确认了,因为把大家凑在一起不容易。而那些各个团队自己的问题,比如前端细节,交互细节,后端逻辑细节,或者是你还不确定的点,可以下来了慢慢私聊。

我们要记住,高效的需求评审不是解决100%的问题,而是在1个小时的时间里解决最重要的问题。

为什么要在一个小时内,因为时间长了,我们的精力和注意力都会打折扣,相信大家都有这样的体会,一切方法论都不管用了。

最后的最后,有朋友可能会问,你不是要讲需求评审么,为什么重点都在讲新项目的评审。因为当你可以搞定一个新项目的需求评审时,我相信其他类型的需求,你也都可以应对自如了。

#专栏作家#

大力哥呀;微信公众号:大力哥求职,人人都是产品经理专栏作家。正年轻的产品经理,关注新零售、用户体系,擅长问题抽象及拆解。

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

题图来自Unsplash,基于CC0协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
起点学院课程
评论
评论请登录
  1. 嗯,将自己的功课展现出来是个很不错的思路;以及逻辑 模块的表述方式确认更有结构叙述性,感谢分享;产品新人还请多多观照;

    回复