你是如何处理产品需求的？

高频面试题：你是如何处理产品需求的？

当我们获取完产品需求时，就需要梳理并正确的分析这些需求，需求从“确定出现”，到“落实设计”中间的这样一个阶段叫做“需求处理阶段”，在需求处理阶段大致划分三个步骤：需求梳理、需求分析、需求放大。

（1）需求梳理

1）建立你自己的需求池

这个需求池可能是协作工具的一个模块，也可能是你自己的一张表格，无论是什么，关键是你要在上面记录你在工作中收集到的创意、想法、功能、优化，并做出一个基本的优先级判断。

2）区分需求类型

产品经理可以先将需求大致浏览一遍，进行分类。类型一般简单分为三类：BUG、改进、新增。BUG：产品某个模块或功能无法正常运行，即为bug。改进：产品某个模块或功能可以正常运行，但希望能够改进以提升效率或用户体验。新增：产品目前还没有相应模块或功能，需要新增以满足需求。

还可以根据产品所处在的不同阶段，根据需求的来源进行划分，市场及运营反馈的需求、客户反馈的问题、产品本身的优化等等。

3）对需求进行合理化期望

我们可以从数据的变化、效率的提升等角度尝试对需求做出一些合理化的期望：

相应数据的变化期望，例如：某个你认为可以提升用户兴趣的功能，其必然会在产品的打开次数、DAU、MAU等等数据上产生变化；

效率的提升，例如：某一个流程的优化或者某一个系统内部对象的重构所带来的效率的提升，当然这里的效率可能指的是用户在使用过程中的效率，同样也可能是系统本身的运算效率；

数据的期望和效率的提升是我们在整理需求过程中的一个判断，同样也是需求合理化的体现。

（2）需求的分析

1）分清表面需求和本质需求

需求按认知层面的划分，可以分成表面需求和本质需求，产品经理传达给项目组成员比如开发和测试的需求更多是属于需求实现环节的概念，所以需要从获取的表面需求中提炼出用户的本质需求。理解用户的本质需求，则有利于我们更好地提出产品需求。

a.表面需求（用户想要的）

用户经常从自身角度出发得出问题的解决方案。因为对产品定位、设计的依据等情况不了解，他们的建议很多时候并不是该功能的最好实现方式，也就不足以直接作为产品规划的直接依据。如果根据表面需求来设计产品的话，很可能会出现“头痛医头，脚痛医脚”的情况。

b.本质需求（用户需要的）

用户想解决的根本问题。获得用户的本质需求更可能找出更合理的方案来解决用户的问题。

c.产品需求（我们能给的）

依据用户想解决的根本问题，得出的更好的问题解决方案。解决方案可以理解为一个产品，一个功能或服务，一个活动，一个机制。产品经理首先需从用户那里收集反馈信息，分析用户需求，再根据用户需求进行产品功能规划，这些待实现的产品功能对于产品来说就是产品需求。收集用户反馈，分析用户需求，最终都是为了生产产品需求。

2）对现有逻辑的影响

思考新需求对现有业务逻辑的影响，会不会影响现有业务功能。当然也同样要考虑到一些潜在的影响，这同样是你对需求评估的一个重要标准。

3）需求与现有流程的对应及扩展

新的需求可能会涉及到新的流程、新的功能，当很多新东西出现的时候，我们同样要在逻辑层面考虑到“可复用”，并且在设计中考虑到“扩展性”。

4）展现的丰富 + 从“可用”到“易用”

对于一些针对用户的前端优化需求，可能更多的我们要分析其真实的目的，不仅仅是在设计和交互上进行一次次的优化，很多时候我们更应该从“可用”到“易用”的角度出发去分析需求。

5）多部门配合、多角度规划

很多时候一个需求对应的功能不仅仅涉及到开发和技术，当其实现之后更要市场、运营等等部门进行配合，所以在这之前你就要做到“心里有数”，全面思考并给出合理化的建议和方案。

6）不同需求类型的分析

根据上文提到的，1、对于BUG类需求，至少需要明确：用户做了什么动作？应该出来什么结果？实际出来的是什么结果？2、对于改进类需求，至少需要明确：用户做了什么动作？哪些地方有些卡壳或不便？理想情况下，最佳表现应该是什么？3、对于新增类需求，至少需要明确：用户最终或本质上想要达成什么目的/目标/结果。

（3）需求的放大

需求的放大更针对一些新的功能，或者流程变动；对于一些简单的优化我们直接进行下面的设计可能更加的直接有效，当然这同样是在你的细致思考之后。

1）解构需求链条

针对一些流程性的东西，我们应该对其进行详细的梳理和串联，这时候一张大白纸、一只笔，按照流程写下一些可能是你想到的所有东西，这样更有助于你快速的分析；接下来整理每个节点，整理并划分你写的东西，将其串联起来，为接下来的分析做好准备。

2）寻找背后的逻辑

拆解细分需求背后的逻辑，对每一个你整理的节点进行更加详细的分析，这时候你可以结合你刚刚所写的所有和这个节点相关的信息一起进行考虑，这也会让你思考的更加全面。举个寻找背后逻辑的简单例子：在我们设计用户下订单这样一个操作的时候，其实我们要考虑到订单的整合、支付、交易以及连续的后置操作等等，这也都可以属于下订单背后的逻辑。

3）对应用户形态

当我们从流程和功能的角度对需求进行放大后，接下来其实是将需求对应到具体的用户形态，举个例子：当我们考虑支付方式的时候，除了主流的支付宝，微信这样的支付方式，是不是同样要根据受众人群的不同考虑添加银联支付甚至线下汇款等方式，当然这要根据你的具体业务进行具体的考虑。

4）和用户反复确认

产品经理将需求逐个梳理完以后，要向需求方讲述自己对需求的理解，看与需求方的理解是否一致。在此过程中，必然会出现需求理解不到位、甚至需求理解相反的情况。这很正常。需要产品经理与需求方不断沟通，直至对需求的理解达成一致。

在经过一系列的整理和思考之后，接下来就进入到具体的落地执行阶段，这里可能涉及到对需求进行一次最终的整理。将这些汇总成一份可以呈现的方案，最后进行原型的设计。