来源|产品刘

需求评审是产品经理一项绕不过去的工作，但对于产品新人来说，可能不是一件简单的事情，方案准备的是否充分，能否经受住项目其他成员的灵魂拷问，都极大的考验着产品经理的技能和抗压能力，今天就来说说如何做好需求评审。

一、分析需求

很多新人接到需求以后，一上来就开始画原型、写文档、约开发评审，结果评审的时候发现一大堆问题，我们接到需求后，首先要分析需求，至少要从以下几个方面去透彻的了解一下需求。

1、了解需求背景

也就是说为什么要做这个需求，这个需求是谁提出的？哪个角色在哪个场景下提出的，遇到了什么困难？需要系统帮忙解决什么问题？

2、了解对现有系统的影响

如果要做该需求，那么会对现有系统的哪些地方造成影响，列出影响当前系统的点。这个一定要亲自去体验产品，根据现有的逻辑和交互去考虑，如果不了解现有的功能，很容易会遗漏或者方案有冲突。

3、需求的分类

需求是共性需求还是个性化需求，思考能否做成通用性需求，如果不能，要思考是否值得花费人力、物力去做这种个性化的需求，这个尤其是每个SAAS产品经理尤其考虑的内容。

4、做最优的方案

是否通过线下或者现有的能力解决？如果系统改造怎么样成本最小？举个例子：医院放射科的主任说需要限制每天临床的加急患者，否则加急的插队多了患者会投诉，但是控制加急的患者靠系统合适吗，是否需要加急医生最有决定权，系统是完成不了这个事情的，所以不是所有的需求都应该通过系统满足，有时会适得其反。

如果有多个解决方案，我们要选择成本最小的解决方案。

5、需求影响的范围有多大

一个系统需求的增加可能会影响其他系统，比如贷后系统变更贷款人以及亲友联系信息，那这些信息要不要同步给客服系统？这些都需要联动考虑。

二、需求评审都有哪些角色参与？

需求评审一般有产品经理、UI设计师、程序员（分为前端和后端）、测试工程师，如果这个项目有项目经理，项目经理也要参与。总之，就是与项目相关的干系人员都要参加。

然后在需求评审会上，大家达成共识了，就开干。

三、需求评审，开发关注的点

俗话说，知己知彼百战不殆，我们要想不被开发怼和质疑，就需要了解开发关注的一些点，然后针对这些点提前准备，针对性的解释。

后端

业务逻辑：就像线下购物中需要将商品加入购物车、在收银台付款后才能带走一样，映射到程序里，就是提供搜索、浏览商品、加入购物车、提交订单、支付的功能。在程序里也是有逻辑的，不可能未付款就给发货，只有有了逻辑，开发才可以按照逻辑去写代码。

数据字典：数据字典就像产品设计中的字段规范，它定义了数据库表中的字段。在数据库设计过程中，开发人员需要了解这些字段的名称、类型、来源以及长度等。数据字典通常包括字段的详细描述，有助于确保数据的一致性和准确性。

实体关系：实体关系描述了不同概念之间的联系。例如，在医院看病时，患者、医生和科室都是不同的实体，它们之间存在关联。科室可以有多名医生，而每名医生则属于一个特定的科室。在产品设计中，我们也需要将业务概念抽象为实体，并明确它们之间的关系。

业务流程：业务流程描述了操作的顺序和方式。就像购物流程中用户浏览商品、加入购物车、提交订单、付款、商家发货、商品配送、用户收货一样，产品设计也需要明确流程。使用流程图的方式可以清晰地表达业务流程。

前端

页面：前端关注页面中的元素和布局。这包括确定页面是否需要表单、下拉框、弹窗等等。

交互：交互包括页面之间的导航关系和需要实现的动态效果。

总结：前端和后端的关注点不同。前端主要关注页面元素和交互，而不涉及业务逻辑和数据处理。与此相反，后端负责处理业务逻辑和数据处理，因此需要关注业务逻辑的清晰性和数据字典的定义。这两个方面的协作有助于实现一个完整的产品。

四、需求评审注意的点

1、首先说明需求价值

团队后端成员往往不如产品经理了解需求的背景和来源，所以，产品经理最好能说一下为啥做这些需求，说清楚这些需求的价值。比如提升工作效率、提升DAU、增加营收额等，而不是一句话，老板提的需求、客户提的需求，这样显得产品经理是个传声筒。

当团队成员了解需求的价值以后，不仅工作起来更有动力和方向，也能提出一些有建设性的意见。

2、评审前先线下打通关键点

需求评审前，可以把方案先发给团队成员，让大家有问题，可以提出来，然后你私下和他沟通，解决他的疑问，这样在需求评审前很多问题就在线下被解决了，等真正需求评审的时候，就是走一遍流程。

此外，你还可以找玩的比较好的开发同事，让他看一遍你写的需求文档，看看有没有什么问题，让他帮你检查一下，这样也可以完善我们的需求文档，起到查漏补缺的效果。

3、逻辑+模块的表达方式

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

新项目通常非常复杂，如果不建立清晰的逻辑主线，很容易导致听众感到困惑，不知道当前在讨论的哪个部分。这可能会导致“听不懂+不知道现在讲到哪一步了”的问题。

在我自己设计赠品系统时，我会构建一个逻辑链，其中每个关键节点代表一个产品模块。因此，我首先会明确阐述逻辑链，然后再详细介绍每个链上的产品模块。这种方式能够更清晰地传达信息。

就好比我们看论文一样：首先浏览目录，然后逐一阅读各个章节。当遇到难懂的部分时，不时回顾目录，以确定当前所处的位置，逐渐理解整篇论文的内容。

同样地，新项目的需求评审就像是一起阅读论文的过程。首先，介绍项目的大纲，然后逐一介绍各个部分的细节。当遇到难点或疑问时，回顾一下项目大纲，告诉团队当前在讨论的内容位置。通过反复强调逻辑链，需求评审就能成功完成大部分工作。

4、逻辑有误时，不要当场下决定

评审的时候，可能会遇到逻辑遗漏或者逻辑有误的情况，这时候不要慌乱，毕竟人无完人，可以先回答我下去确认一下或者我在思考一下，尽量不要当场给出解决方案，当场给出的方案，一般没有经过仔细思考，很容易掉坑里去。

5、不要说一些模棱两可的话

程序员的世界都是0和1的世界，行就是行，不行就是不行，不存在也行吧。我们如果经常把也行吧、可能、大概这类模棱两可的话挂在嘴边，则很容易招致评审人的反感，语言坚定有力，会给人一种主心骨的印象。

6、自信

产品经理在需求评审前和过程中，一定要自信，只有心中充满信心，才能有条不紊的回答别人的提问，也不要怕被质疑，产品经理都是在质疑中成长起来的。

7、顺势开排期会议

需求评审通过后，可以顺势开排期会议，这样方便对项目进行管理，避免出现项目失控的情况。开排期会，也不要给团队成员的时间压得太紧，尽量留一些buff，以便可以应对突发情况。

五、总结

需求评审是每个产品经理都需要经历的一个过程，当我们准备充分了，做好事前沟通，不断总结经验，那需求评审一定会越来越顺利。