如何做好需求评审

需求评审是产品经理一项绕不过去的工作，但这可不是一件简单的事情，方案准备是否充分，是否经得住项目成员的灵魂拷问，都在考验产品经理的技能和抗压能力，遵从以下几点可有助于做好需求评审：

为什么做这个需求？

需求是谁提出来的？

哪些角色在哪个场景下提出来的？

需要系统帮忙解决哪些问题？

了解需求背景

如果要做这个需求，需要考虑会对现有系统哪些地方造成影响，可以逐条列出影响的点。（一定要亲自去体验产品，从现有逻辑及交互考虑，避免出现遗漏或方案有冲突）

了解对现有系统的影响

需要考虑需求是共性需求还是个性化需求，思考能否做成通用需求，如果不能的话则要思考是否值得花费人力、物力去做这个个性化需求

将需求分类

是否通过线下或现有的能力去解决？如果将系统改造成怎么样成本是最小的？如果有多个解决方案，我们要选择成本最小的解决方案。（毕竟不是所有的需求都应该通过系统满足，有时会适得其反）

做最优方案

一个系统需求的增加可能会影响其他系统，需要联动考虑

需求影响的范围有多大

评审前分析需求

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

需求评审需要哪些角色参与

俗话说，知己知彼百战不殆，我们要想不被开发怼，就需要先了解开发关注的点，并针对这些点提前准备，以便做针对性的解释

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

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

前端

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

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

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

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

后端

前后端关注点不同：前端关注页面元素与交互，不涉及业务逻辑和数据处理。后端负责处理业务逻辑和数据处理，因此需要关注业务逻辑的清晰性和数据字典的定义。

总结

需求评审中开发关注的内容

团队成员往往不如产品经理了解需求的背景和来源，产品经理最好能说下为什么做这些需求，说清楚这些需求的价值。而不是一句老板提的需求、客户提的需求，这样显得产品经理是个传话筒。当团队成员了解需求的价值后，工作才更有动力和方向，也能提出一些有建设性的意见。

说明需求价值

在评审会议开始前，需提前将方案发给团队成员，让大家先了解方案，有问题可以提出来沟通，这样在会议前很多问题都在线下被解决，等真正评审会议时就是走一遍流程。

会议开始提前几天发方案给团队成员

切记对着PRD讲或对着原型一张图一张图的讲特别的新项目或新需求比较复杂时，如果不建立清晰的逻辑主线，很容易导致听众感到困惑，不知道当前在讨论哪些部分。这可能会导致“听不懂+不知道现在讲到哪一步了”的问题。可将需求评审当做一起阅读文章的过程。第一步先介绍项目的大纲，接着逐一介绍各部分的细节。当遇到难点或疑问点时，回顾下项目大纲，告诉团队当前讨论的内容位置，通过反复强调逻辑链，需求评审就能成功完成大部分工作了。

逻辑+模块的表达方式

评审过程中，会遇到逻辑遗漏或有误的情况，这时候不要当场给出解决方案，因为当场给出的方案一般没有经过仔细思考，很容易掉坑里。可以回答我下去先思考一下，会后给出答复。

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

程序员的世界里都是0和1的世界，我们如果经常把可能、大概这类模棱两可的话挂在嘴边，很容易招来评审人的方案，语言坚定有力，会给人一种主心骨的印象，一定要给到开发明确的需求。

不要说模棱两可的话

在评审过程中，一定要自信，这样才能有条不紊的回答别人的提问，也不要怕被质疑，产品经理都是在质疑中成长的

自信

需求评审通过后，可以顺势开排期会议，这样方便对项目进行管理，避免出现项目失控的情况。

顺势开排期会议

需求评审注意事项

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

如何做好需求评审