需求的来源有很多，需求的处理方式也不尽相同。有效的收集需求，将收集到的需求去伪存真，是产品设计环节中最重要的一环，如同大厦的地基，地基不坚实，大楼是盖不起来的。
我把需求分析分为两个阶段，第一个阶段是收集需求，第二个阶段是处理需求。完成这两个阶段之后，我们就可以进行原型设计，这一点以后再聊。
一、收集需求
收集需求有多种方式，常见的有以下几种：
1.无针对性的用户访谈
一般来说，toB的产品，特定的用户是主要需求的提出者，而产品设计是为特定用户服务，在这种情况下，我们有机会与特定用户进行深度的沟通。但是，即使是明确了需求的提出者，在收集需求的过程中，还是有可能遇到很多“坑”。
如果特定用户不止一个，一定要区分“最终拍板的用户”和“产品的直接用户”
区别在哪儿呢？用户想要什么，是用户的原始需求；而用户想做成什么，是用户将原始需求经过自己的理解得到的需求。所以，在你提出一个问题的时候，不妨再加上一个为什么，往往会起到意想不到的效果。
使用通俗的语言，避免专业词语
如今社会，每个人都对互联网有不同程度的了解，作为用户你无法预估他的专业程度。在访谈过程中，产品经理要尽量用通俗、严谨的语言去谈话而不是一堆专业词语去显示自己的专业度。一旦用户的理解有偏差，你收集的需求将会把你引向歧路。
2.头脑风暴
头脑风暴是比较常见的需求收集方式，对于头脑风暴的流程也有大牛讲解的非常详细，我就不重复了。但是作为产品经理，你更多的起到的是监督和控制的作用，我认为要注意的有以下几点：
第一，确保会议围绕你提出的话题展开，而不是漫无边际的聊天。
第二，不要对任何一个人员提出的话题进行评价或者议论。
最后，控制时间、控制时间、控制时间。
3.用户反馈
我认为用户反馈分为主动反馈与被动反馈两种。
用户在客服、官方微博、QQ群、贴吧、论坛、留言板、投诉等场合提出的意见都可以算是主动反馈；而调查问卷、有针对的用户访谈（焦点小组讨论）、用户回访等方式是被动反馈。
一般来说，主动反馈属于更紧急需求，被动反馈属于重要需求，并可以以此来定义优先级。
4.内部需求（领导、运营、运维、客服）
一般来说，产品经理是对产品结构、流程最熟悉的人，面对内部需求，你需要做的是明确需求提出的目的，并提供解决方案。
拿我遇到过的问题举个例子：有一次，针对产品的订单，运营人员提出一个需求“增加手动处理订单退款的功能”，如果按照运营人员的需求，大约5个工作日可以完成一次版本迭代，我问清楚根本原因是“平台上申请退款的用户很多”，发现订单显示的界面太过复杂、不够明确，导致用户体验很差，后来简化了界面，规避了此类问题，工作量约1个工作日。
5.数据分析反馈
数据是客观放映产品的重要指数，也是收集需求的重要来源，前期是收集的数据是可靠、客观的，这里就不展开讲收集数据了。
数据是零散的，在进行数据分析前一定要有明确的中心，划定一个界限，收集同一个框架内的数据。
单独的数据是死的，有对比的数据才有意义。
为了避免主观意识的影响，同一份数据参考其他人员的分析结果。
二、处理需求
处理需求的阶段，也是产品经理将需求进行筛选，梳理业务流程，设计产品架构的阶段。
1.需求筛选、分类
尽管我们保持严谨的态度收集大量的需求，其中还是有很多需求是“伪需求”，甚至是不合理的，我们第一步就需要将这些需求进行“清洗”，择优去重、去伪存真。
2.竞品分析
由于在这个阶段，产品经理不仅要定义目标用户、产品使用场景，还要确定核心功能，产品流程等等，因此通过竞品（如果有）来辅助处理需求是一种很有效的方法。
通过相似竞品的用户定位、功能反推竞品的需求，与自己的需求进行对比；将自己的需求代入竞品中，看流程是否符合逻辑；与竞品进行对比，分析需求的异同。
3.设置优先级
一般来说，从需求类型来看，基本型需求>期望型需求>兴奋型需求；
从需求来源来看，战略性需求（领导提出）>功能性需求（核心功能）>业务性需求（拉活、存留）>体验性需求（提升用户体验）。
做好最常用的是用四象限法则去评定优先级，另外可以使用RICE评定方法，KANO模型等。
4.需求评审
在这个阶段之前，作为产品经理对于产品应该有了一个完整的模型，但仅仅是理论上的模型，确保UI、UE、前端开发、后台开发、测试参与，从产品开发流程的各个角度对需求进行拆解、分析。需求评审可以看做是产品开发的初始化或者预开发。
