自从互联网行业的兴起，需求这个词也从原本传统行业的定义中不断延伸，对于互联网行业的从业者，在每天接收到的海量信息中，懂得哪些是需求，如何筛选，归纳，分析需求，更是尤为重要的能力。通过了解需求，分清轻重缓急，事半功倍的达成目标，而不是成为需求的奴隶，每天被来自各方的需求鞭策，却不知为何而忙碌。

本文结合了笔者在产品行业工作的微薄经验，整理出从需求收集—需求整理—需求分析的方法论，未必会适用于所有的互联网工作流中，但希望系统性的思考过程可以帮助理清思路，在繁杂的需求中找到那个破局的线头。

在进入具体的分析前，我们要知道，什么是需求？

首先要明确的一点，需求不等于需要。

需要是因某种“缺乏”而产生的物质需要和精神需要，例如，我想要吃饭，这是一种物质需要。我想要开心，这是一种精神需要。需要是结果型的指向，而且可能会因为各种因素而不断变化和发展。

而需求可以当做更为具体的需要，要有具体场景具体人物。满足需求可以当做一种可行的选择，在互联网的语境下就是，要在什么场景下，解决了什么人，的哪些问题。核心关键在于解决问题。

例如，我想要吃饭，但是没有工具，问题产生了，这个就是需求，为了解决这个问题，我们可以提供多种选择，筷子，勺子，叉子等等，而哪个选择是真正能满足需求的选择，哪个工具能满足吃饭的这个需求？这个可能又要具体分析，为什么想要吃饭？在哪吃饭？是谁在吃饭？等等，这些就后文再提到了。

由此可以看到，当面对需求的时候，要警惕它是不是个需求，也要将需求的颗粒度拆解到尽可能的细，只有把需求的颗粒度变细，我们才能做出满足需求的产品，当你想从“我想吃饭”这个高度去满足用户，而不去分析里面的原因，很有可能发生的是，用户只想要个饼，你却给了个满汉全席，成本无限高，这的确是一种选择，却未必是分析后的最优选择。

需求收集

在需求收集的阶段，并不需要对需求进行归类或者分析，重要的是将需求在避免收集人主观意识的影响下，完整的收集起来。

收集需求时一定要真实、客观的记录需求提出者的描述，包括需求背景，产生原因，具体期望等等，以便后续分析时做到可追踪，可体验。

可追踪即可以再次找到需求提出者，针对不清晰的地方进行沟通，因为很多时候，需求收集人和产品设计人未必是一个人，需求可能由客服，市场调研，销售等各处收集而来，所以需要尽可能避免需求在转述中产生的理解歧义，在有不理解的时候也可以找到需求提出者进行再次沟通

可体验即对于需求发生的场景及问题，可以复现并再次体验，方便产品设计人真实体验理解需求或找到准确的目标用户群去验证需求。

从需求来源的不同，需求收集有以下几个渠道：

1.被动需求

（1）其它业务部门：此渠道的需求多应用于支撑型或平台型的产品，例如OA，CRM等。此类需求由于通常是为业务部门的工作服务，所以需求通常都比较明确，但是沟通成本仍然很高。

因为业务部门提供的需求虽然明确，但解决方案未必能真正解决问题，甚至成本还通常较高。此时则需要产品设计人去跟业务部门了解沟通，去了解组织机构，业务部门在组织机构的业务流中处于哪个位置，业务部门的职能职责及工作流程，业务部门的目标及战略等。

通过了解这些关键节点，可以梳理清支撑业务部门的方式，也帮助理解业务部门提出需求的真实原因，然后由产品设计人给出可行的解决方案。

（2）客户需求：如来自项目投资人，购买产品的用户等的需求，要去从为客户达成目标，带来的价值，提高效率的方面考虑。

（3）老板需求：之所以将这个单拎出来，是因为来自老板的需求在产品经理的职业生涯中是不可避免的，如果不正确对待老板的需求，甚至会打乱产品正常的迭代节奏。所以要去了解老板需求的来源，是由于公司战略，商业价值，还是体验中产生的需求，或者是看了下其它的文章等。如果是由于公司战略，优先级通常要放到最高。

（4）测试需求：一般都是测试中产生的bug或体验缺陷等，这些需求由于通常来自已经完成的功能或产品，所以考虑下性价比，具体问题具体分析即可。

2.主动需求

（1）竞品分析：竞品分析是产品经理提供新需求的重要渠道，竞品分析适用于产品生命周期的各个阶段，通过研究竞品，可以了解市场动态和竞争对手的产品方案，挖掘出适用于自身产品的需求，也避免新的idea没有经过系统性的沉淀和思考。

（2）用户研究：用户研究也是了解产品，获取需求的重要方式。用户研究发展到现在，也已经有很多切实可行的系统性用户研究方法，用户研究可以帮助产品设计者了解真实的目标用户群体和潜在用户的需求，避免产品设计天马行空，脱离真实用户

（3）数据分析：通常与竞品分析和用户研究结合起来运用，也在产品迭代中可以做行为数据分析，通过数据来挖掘出需求点。

尽管需求的来源渠道有很多种，但在处理这些需求的时候，有个共同点就是要去了解需求产生的真实原因。

需求整理

当产品不断迭代，各方产生的需求越来越多时，整理需求可以避免需求遗漏，同时梳理清需求的开发周期。

（1）分类：可以按照各个产品设计者在实际处理需求时的习惯分类方法，例如按照功能需求和非功能需求分，按照业务需求，项目需求和用户需求分等等，笔者通常按照用户体验/新增功能/视觉优化/质量缺陷的需求种类分类。

（2）需求描述：包括问题描述，使用场景，用户痛点和具体功能描述，这里的问题描述和使用场景主要由需求提出者提供，用户痛点和具体功能描述可以由产品设计者经过沟通和分析后写出

（3）需求处理状态：针对每一条需求，给出需求处理的状态，如不处理，规划中，暂未启动，开发中，暂停开发，已处理。

（4）需求进度：当需求正在开发阶段，可以一目了然看出各个需求进展到哪个环节及需求的排期，如产品设计，技术，交互，UI，测试，发布

（5）优先级：对每一项需求进行优先级判断，通常高/中/低的优先级已经可以整理需求，具体判断优先级的方法在后文需求分析的部分提到。

（5）其它：包括功能模块——需求是哪个功能模块的需求，提出时间——需求提出时间，提出者——需求提出人，方便追踪，版本号——可以为问题产生的版本，也可以为需求解决的版本，责任人/责任部门——对于需求收集人来说，收集到的需求可能需要由多个部门解决。

本篇是需求分析的前置准备，需求收集及需求整理篇，下一篇则进入需求分析篇，面对收集来的海量需求，我们如何分析需求的价值，可行性和优先级，仅供参考，欢迎各位互联网行业从业者一起交流。