真正了解过或经历过“产品经理”这一职位的人，都清楚“需求分析”是产品经理的核心工作之一，那么不知道大家是怎么定义“需求分析”的。
汪叔对“需求分析”的定义是：
“对需求（问题）进行识别并进行分析与定位，寻找最优解，并制定可行性方案”
初入产品时的需求分类
如果大家是刚入行或者入行不久的产品，那么对需求认知并不需要立即上升到“马斯洛需求层次‘等这样的等级，就好比一个刚入行的程序员需要立马知道语言底层原理是什么吗？
刚开始可以简单的分为两类：基本需求和复杂需求
基本需求
基本需求，很简单，这类需求公司往往有详细的流程和解决方案，这种往往并不需要产品经理进行很详细的分析，只需要根据基本的认知和经验就可以进行可行性方案的制定。如：对接产品、简单的功能开发等。
复杂需求
对于复杂的需求，例如：多需求方共同参与的、非常规性需求，此时并没有常规的解决方案，需要产品经理对需求进行分析，这时该如何就行分析？
下面根据汪叔初入产品时的错误案例来说
案例场景
人物：汪小白
背景：初入产品，在新公司接到的首个需求
需求类型：简单需求
需求方：财务部门
具体需求：财务部门：“能否在后台加一个自动核销的功能?”。
大家结合上述案例场景，思考下这两个问题？
1.大家觉得这是一个需求问题，还是一个解决方案？
2.大家觉得拿到这个需求，你会如何开展？
如果是刚入行的产品经理（也就是汪叔）可能就会接着需求方的问题进行询问，
能说下具体需求吗？
是想在哪个模块下加？
想要实现成什么样式？
还有什么其他的要求吗？
最后方案成了一个类似Excel的功能，被领导狠批一顿重新开始，此时已经耽误很多的人力和时间成本。
1.识别、分析与定位
识别
大家应该都意识到了，财务部门提出的“能否在后台加一个自动核销的功能?”。
这个问题并不是财务部门提出的“需求”，而是一个“解决方案”。
在上篇文章中提到过，需求提出者往往给出的并不是需求问题，而是他们脑中通过问题自动出现的解决方案。
也是就说，财务部门觉得要解决他们问题，需要开发一个“自动核销“功能。
那作为入行一段时间的产品经理，此时他们的反应往往是
为什么要加？
是在什么样的场景下或是在什么时候发现需要有个这样的功能？
这就是需求识别 —— 识别产生这个需求（问题）的真正核心点。
上述案例中，识别后发现，原来是财务在每次核销对账的时候，都得在后台导出不同的功能表，浪费很多的时间。
其需求的核心是想节省操作时间，将想要的数据条理化并方便加工。
分析与定位
在进行分析定位时，需要做到一个前置条件，要了解其相关业务的流程和涉及到哪些相关岗位和领导（财务部门尤其重要）。
接下来针对识别的核心问题进行分析与定位，比如案例中，是因为财务想要的数据分别在不同的数据列表中导致操作时间较长等。
在分析与定位的时候，通过类MECE原则进行分析的方法，确立主要问题的基础，再逐个往下层层分解，直至所有的疑问都找到，通过问题的层层分解，可以分析出关键问题和初步的解决问题的思路。
2.寻找最优解
在完成分析后，基本上会有数个解决方案，有十分简便而且快速的，例如上述案例，根据财务部分想要的数据，确定人员和权限后跑定时任务查询数据，也有很高大上的，比如真的做个自动核销功能。
这时大家需要根据需求重要程度、紧急程度、所占开发人员数量等，去寻找符合目前的最优的解决方案，并不是一味的要使用最好的解决方案。
3.制定可行性方案
问题识别了，解决方法找到了，现在到了最后一步-制定可行性方案（出原型等工作）。
这时需要着重考虑三个问题
1.设计的功能是否可以解决需求方的问题？
2.结合业务流程是否所遗漏？
2.技术开发难度和资源占用比例
到最后你可能会发现，不用耗时耗力做一个山寨的Excel，只需仅仅开发几个筛选项和取几个数值做出一个对账单，在加一个导出功能就可以了解决这个问题。
总结
汪叔对“需求分析”的定义是：
“对需求（问题）进行识别并进行分析与定位，寻找最优解，并制定可行性方案”
需求识别：识别产生这个需求（问题）的核心点真正是什么
分析与定位：确立主要问题的基础，再逐个往下层层分解
寻找最优解：寻找符合目前的最优的解决方案，并不是一味的要使用最好的解决方案
制定可行性方案：考虑三个问题。
涉及知识：
MECE，是Mutually Exclusive Collectively Exhaustive，中文意思是“相互独立，完全穷尽”。 也就是对于一个重大的议题，能够做到不重叠、不遗漏的分类，而且能够借此有效把握问题的核心，并解决问题的方法。
该方案重点在于帮助分析人员找到所有影响预期效益或目标的关键因素，并找到所有可能的解决办法，而且它会有助于管理者进行问题或解决方案的排序、分析，并从中找到令人满意的解决方案。
作者：贰汪；微信公众号：天朝贰汪
