如何高效完成需求评审？

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

在需求评审会议中，前端、后端、测试、用户界面和你的老板可能都会过来，聚集不同的角色来听取产品经理关于需求的意见。这不是一项容易的任务。对于每个产品经理来说，如何有效地完成需求评审需要仔细考虑，也是必须掌握的一项基本技能。今天我将和你谈论这个话题

01

首先讲述背景故事

春节过后，由于疫情，我在家工作了大约三个星期。因为它是远程的，所以许多需要群体交流的日常事务现在都是通过文档的离线交流来完成的。

因此，对我来说，我也有非常完整的时间去思考和设计一个由Q1计划完成的大型项目。它在以前的文章中也有所改进。这是一个礼物系统。

是本系统的最终产品原型，包括两个后台模块和两个C端页面，非常复杂。珠江三角洲建成后，连我都惊呆了，差点被一篇小论文追上。

但是有太多的内容需要在大约一个小时内向相关团队说明，以便将需求交付到研发阶段。幸运的是，我做得很好，尤其是在远程办公方面。

今天，我将以这个项目为例，告诉您如何高效地完成需求评审。

02

实际上包含了一套非常简单的逻辑:关于需求评审要传递的信息的值、函数和实现

价值:为什么你需要这样做，上网后有什么价值功能:为了支持这个值，需求包括哪些功能实现:如何实现每个功能

例如，我为老板制作了一个数据板。它的价值是让老板随时了解项目的进展。它的功能是以三个维度呈现数据:A、B和c。它的实现是每个数据的口径是什么，数据如何在板上分布，以及它以什么样的图表格式呈现。

和需求本身大致可以分为:功能优化、功能扩展和新项目对于不同类型的需求，在审查会议上提供的信息的重点是不同的。

功能优化:重点在于阐明如何做到这一点。通常，评审时间很短，不会单独组织，而是与其他要求一起评审。功能扩展:关键是要弄清楚它是什么，它与原始功能有什么联系。可能有必要单独组织一次会议。新项目:重点是澄清为什么要建立这个项目，项目包括哪些模块，模块之间的联系是什么，以及每个模块的功能和实现。

因此，从信息量来看，新项目的评价密度最高，也是对表达逻辑和评价效率的最大考验。我所理解的高效评审向协作团队传达了统一的项目价值，使他们能够理解彼此的角色、任务和需要在现场执行的行动。彼此角色之间最重要的联系是什么？我们都知道人们对新事物的信任度相对较低。产品经理在需求评审会议上最重要的任务是帮助每个人建立这种信任，并发出两个信号:这是值得做的；这件事是可以做到的在下面的

中，我将重点介绍在进行需求评审时，新项目是如何变得更加高效的。

03首先，解释需求价值最直接的方法是让产品经理了解需求价值，但这远远不够，你需要让协作团队也了解需求价值然而，协作团队通常不会像你一样对需求背景做太多的研究。

如何在尽可能短的时间内实现需求价值？数量指标例如，

是一个赠品系统。这个系统的价值也可以用很多方式来描述:效率提高了，以前的行业问题解决了，老板也注意到了，等等，但是这些都不够直接。

想在尽可能短的时间内解释这个系统的重要性。你需要知道这是多大的盘子。你的意思是，你必须调查清楚，零售超市一年内赠品的营销规模是多少，以及什么样的盘子与你的项目直接相关？把这个数字算出来，需求的价值一目了然。

第二，它显示了在为需求设计方案之前的准备工作

这是我在以前的工作中容易忽略的一个步骤，但是最近它受到了很多关注。如前所述，人们对新事物的信任度相对较低。同样，协作团队对新项目的信任度相对较低。他们经常怀疑产品经理-

是否是老板要求的，而你只是一个执行者。这是一个明确的要求还是你拍着额头想出来的？最重要的是，作为一名产品经理，你是否清楚地考虑过这件事，或者为此做了一些准备？

因此，有必要在审查会议上同步准备工作和相关核心结论。例如，你做过什么样的竞争研究？公司的战略层有什么指示？你对已经运行过的一些测试用例有什么核心结论吗？

这一步的重点不是使需求更清晰，而是增强协作团队对新需求的信任——我作为产品经理，在组织今天的评审会议之前已经做了大量的相关准备工作。这件事我已经想清楚了。

第三，逻辑+模块的表达

我已经听到一些产品谈论需求评审，或者是对PRD，或者是对原型逐一进行评审。但是说实话，这种方法不适合新项目的评估新的

项目由于其高内容密度，通常会产生“不理解+不知道现在该走哪一步”的负面影响。本质上，这是因为在听者的头脑中没有逻辑线索。

自己设计礼品系统时，会有一个逻辑链，链中的每个关键节点都是一个产品模块。因此，先阐明逻辑链，然后阐明每个链中的产品模块是更好的表达方式。

就像当我读论文时，我先读目录，然后是每一章，然后看到困难的部分。我不时地回到目录上，看看我现在在哪里，并逐渐理解它。

同样，新项目的需求评审是你带领你的团队一起阅读论文的过程。首先介绍目录，然后介绍每一章的具体内容。如果你遇到一张卡片，回顾一下目录，告诉我们我们现在谈论的是哪里。人们一再强调，如果建立了逻辑链，需求审查将成功一半以上。

第四，上帝的视角和用户的视角的结合

我们知道有两种常用的产品视角，上帝的视角和用户的视角前者通常被产品经理用于设计方案，而后者是用户从进入产品到最终退出的完整过程。

以驾驶为例。上帝的视角是我出发前在地图上看到的路线。我可能知道整个旅程需要多长时间，需要多长时间，以及哪些路段可能会被堵塞。用户的视角是每个十字路口、斑马线、交通灯等。我出发后一直看到最后到达目的地。当驾驶

时，驾驶员会听导航，但也会看道路。因此，在介绍需求时，我建议产品经理也应该将上帝的观点和用户的观点结合起来。

例如，当我介绍礼品系统时，我不仅会解释上帝视角的概念，如逻辑、模块和功能，还会从特定配置人员或商店主管的角度解释他们应该如何使用该系统。

只说上帝的观点，这是不容易理解的，也是其他人难以理解的。仅仅通过谈论用户的观点来记住主线太零碎了。他们可以一起帮助协作团队理解这是什么以及如何做。

最后一点，学会区分听众的问题我们必须明白，在一个小时内完全解释一个新项目几乎是不可能的。即使你讲完了，观众也不会消化。这不可避免地会在你讲完后导致很多问题。

此时，产品经理需要学会判断哪些问题应该当场回答，哪些问题应该私下讨论。

我个人的建议是，如果一个问题符合下列条件之一，你必须当场解决它:

是关于价值和为什么要这样做；这与诚信有关。如果这个问题得不到解决，整个产品逻辑将无法工作。会带来联动效应

例如，如果一个问题与前端、后端和用户界面有关，那么您必须当场确认，因为让所有人都聚在一起并不容易。然而，每个团队的那些问题，比如前端细节、交互细节、后端逻辑细节，或者你不确定的点，可以私下讨论。

我们必须记住，有效的需求评审不能解决100%的问题，但能在一小时内解决最重要的问题。为什么

应该在一小时内？随着时间的推移，我们的精力和注意力将会减少。我相信每个人都有这样的经历。所有的方法都是无用的。在

结束时，一些朋友可能会问，难道你不想谈谈需求评估，为什么关注新项目评估？因为当你能处理一个新项目的需求评审时，我相信你能很好地处理其他类型的需求。

#专栏作家#

强哥啊；微信公众号:大李哥找工作，人人都是产品经理专栏作家年轻的产品经理关心新的零售和用户系统，并且擅长问题抽象和分解。

这篇文章最初是由每个产品经理发表的未经许可，根据CC0协议

, Unsplash禁止重印

张图片

本文由 在线网速测试 整理编辑，转载请注明出处，原文链接：https://www.wangsu123.cn/news/1690.html。