时间: 2021-07-30 11:28:29 人气: 5 评论: 0
需求评审，是每一个产品经理几乎每周都**经历的过程。只要工作在进行，产品在迭代，新需求在不断产生，就**有需求评审。
在需求评审**议上，前端、后端、测试、UI、你的老板可能都**过来，不同的角色聚在一起，听产品经理讲需求内容。这不是一件容易的事情，如何高效完成需求评审，对每一个产品经理来说，都需要去仔细琢磨，也是必须得掌握的基本功。今天我就跟大家聊聊这个话题。
先说下背景故事。
春节后因为疫情的影响，我在家办公差不多有三周左右。因为是远程，导致日常很多需要组**沟通的事情，现在都通过文档的离线沟通完成。
因此，对于我来说，也有了非常完整的时间去思考和设计Q1计划完成的一个大项目。在之前的文章里也提高过，是赠品系统。
这个系统最终的产品原型，包括两个后台模块和两个C端页面，非常复杂。PRD完成之后，连我自己都惊呆了，快赶上一篇小论文了。
但就是这么多内容，需要在1个小时左右的时间内，跟相关团队讲清楚，将需求完成地交付到研发阶段。幸运的是，我完成得还算可以，尤其在远程办公的情况下。
今天我就以这个项目为例子，给大家说说，如何高效完成需求评审。
关于需求评审要传递的信息，其实包含了非常简单的一套逻辑：价值、功能、实现。
比如说我做一个给老板用的数据看板，价值就是使得老板可以随时了解项目进度，功能是需要呈现A、B、C等三个维度的数据，实现就是每个数据的口径是什么，数据在看板上如何分布，以什么样的图表形式呈现。
而关于需求本身，又大致可以分为：功能优化，功能拓展，新项目。不同类别的需求，在评审**上传递的信息重点不太一样。
所以从信息量上来说，新项目的评审是密度最高的，也是最考验表达逻辑及评审效率的。我理解的高效评审，是向协作团队传达出了统一的项目价值，能够让他们理解彼此的角色，任务及需要落地的行动，最关键的，彼此角色之间的关联是什么。
我们都能理解，人对新事物的信任感是相对低的。产品经理在需求评审**上最重要的任务，是帮助大家建立这种信任感，传递两个信号：这个事儿值得做；这个事儿能做。
下面我重点说说新项目在做需求评审时，如何可以更高效。
第一，用最直接的方式说明需求价值
产品经理是了解需求价值的，但这远远不够，你需要让协作团队也了解需求价值。但协作团队往往没有像你一样，对需求背景做过很多调研。
怎么样在最短的时间内传递清楚需求的价值呢？量化指标，数字切入。
比如说赠品系统，这个系统的价值也很多种描述方式：效率提升啦，解决了以前的某个行业问题啦，老板很关注啦等等，但这些不够直接。
想在最短时间内说明这个系统很重要，你得知道这是多大规模的**子。什么意思，你得调研清楚，一家零售**市一年的赠品营销规模是多少，你的项目，直接关联多大规模的**子。把这个数字摆出来，需求的价值就一目了然了。
第二，说明为需求设计方案之前的准备工作
这是我以前工作中容易忽略的一步，但最近一段时间以来很重视的一点。前面说过，人对新事物的信任感是相对低的。同理，协作团队对新项目的信任感也是相对低的，他们**经常怀疑产品经理——
所以，准备工作及相关的核心结论，有必要在评审**上同步。例如做过哪些竞品调研；公司战略层有一些什么指示；跑过的一些测试case，有没有什么核心结论。
这一步的重点不在于让需求变得更清晰，而在于提升协作团队对新需求的信任感——我，产品经理，在组织今天的评审**之前，已经做了不少相关准备工作，这件事情，我是想清楚了的。
第三，逻辑+模块的表达方式
我听过一些产品讲需求评审，或是对着PRD讲，或者对着原型一张图一张图地讲。但老实说，这种方式不适合新项目的评审。
新项目因其内容密度大，往往**产生“听不懂+不知道现在讲到哪一步了”这样的负面效果。本质上都是因为，没有在听众脑中建立起逻辑主线。
我自己在设计赠品系统的时候，**有一个逻辑链，链上每个关键节点便是一个产品模块，所以先讲清楚逻辑链，再讲每个链上的产品模块，是比较好的表达方式。
就好比我自己看论文的时候，先看目录，再看每个章节，看到难懂的地方，时不时回到目录来，看看现在到哪一步，渐渐地就搞懂了。
同样的，新项目的需求评审就是你带着协作团队一起看论文的过程。先介绍目录，再介绍每一章的具体内容，遇到卡点，回顾一下目录，告诉大家我们现在在讲的内容处于什么位置。这样反复强调，逻辑链立住了，需求评审就成功了一大半。
第四，上帝视角与用户视角的结合
我们知道，关于产品有两个常用的视角，上帝视角和用户视角。前者是产品经理在设计方案时常用到的，后者是用户从进入产品的一刹那，到最终退出，所经历的完整过程。
就拿开车举例，上帝视角是我出发之前，在地图上看到的线路，我大概知道整段路程多远，大概要多久，在哪些路段可能**堵。用户视角，就是我出发后所看到的每一个路口，斑马线，红绿灯等，直到最终我到达了目的地。
开车的时候，司机**听导航，但也**看路。所以介绍需求的时候，我建议产品经理也结合上帝视角和用户视角穿插来讲。
比如我在介绍赠品系统的时候，既要说明逻辑、模块、功能等上帝视角的概念，也**从一个具体配置人员的角度，或者门店执行人员的角度，讲一讲他们该如何使用这个系统。
只说上帝视角，不容易理解，别人理解起来困难；只说用户视角，太零碎，不容易记住主线。结合起来，就能最快帮助协作团队理解，这个事儿是什么，该怎么做。
最后一点，学**区分听众的提问
我们要明白，在一个小时的时间里，完全讲清楚一个新项目，几乎是不可能的，即使你讲得完，听众也一定消化不了。这必然**导致，当你讲完之后，一堆问题接踵而至。
这时候产品经理需要学**判断，什么样的问题该当场解答，什么样的问题下来私聊。
我个人的建议是，如果一个问题满足以下若干条件之一，你得当场解决了：
比如一个问题，如果跟前端、后端、UI都有关系，那你得当场确认了，因为把大家凑在一起不容易。而那些各个团队自己的问题，比如前端细节，交互细节，后端逻辑细节，或者是你还不确定的点，可以下来了慢慢私聊。
我们要记住，高效的需求评审不是解决100%的问题，而是在1个小时的时间里解决最重要的问题。
为什么要在一个小时内，因为时间长了，我们的精力和注意力都**打折扣，相信大家都有这样的体**，一切方法论都不管用了。
最后的最后，有朋友可能**问，你不是要讲需求评审么，为什么重点都在讲新项目的评审。因为当你可以搞定一个新项目的需求评审时，我相信其他类型的需求，你也都可以应对自如了。
大力哥呀；微信公众号：大力哥求职，人人都是产品经理专栏作家。正年轻的产品经理，关注新零售、用户体系，擅长问题抽象及拆解。
本文原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议
