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

在需求评审会议上，前端、后端、测试、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协议