西游记中的唐僧说得较多的一句话：我从东土大唐而来，前往西天拜佛求经。这句话涵盖了我从哪里来，要到哪里去以及做什么。同样需求从哪里来？有该如何解决需求？

我相信做产品的人都知道以下两个故事：

故事一：

某富翁想要娶老婆,有三个人选,富翁给了三个女孩各一千元，请她们把房间装满。

第一个女孩买了很多棉花，装满房间。

第二个女孩买了很多气球，装满房间。

第三个女孩买了蜡烛，让光线充满房间。

最终，富翁选了胸部最大的那个。

故事二：

福特：你想要什么？

用户：我想要一匹更快的马

福特：为什么你要一匹更快的马？

用户：因为我想速度更快一些，好节省时间

福特：我造了个东西，叫汽车，比马快多了

我们经常会用这两个故事来阐述关于抓住用户需求的重要性。而关于需求的前世今生，关于用户是否会用一些冠冕堂皇的理由来达到自己的目的，我想用一篇文章尽量把需求说得透彻以好检验自己几年来对于需求的理解。我将以需求现状与原因、来源及获取方法、获取之后如何分析、如何验证的逻辑线进行梳理。

前方干货预警，如果你是销售人员、产品经理，需求分析师，或者是你想往这几方面发展的人建议收藏，因为文章较长，可能需要10-15分钟。

1、关于需求实现的现状以及原因

现实工作中，有各种的原因导致需求无法实践，比如销售人员提出了许多的需求最后都不了了之。有各种原因导致PM与程序猿开启撕逼大战，比如前几天网上看到的PM与程序猿的撕逼上升到辱骂、人身攻击的地步。

那阻碍需求的实现的绝大部分原因是什么？我归结为两方面：

1. 一个是需求本身的问题
2. 一个是沟通的问题

需求本身的问题

1、需求的不完整

比如PM跟UI说：这个图标不够显眼，重新设计一下。 比如销售跟PM说：有客户反映我们的产品不好用，后面的产品你改进一下。很多这样不完整的需求，我们不知道对方真正要表达的意思是什么，所以经常导致需求不了了之。那么问题来了，什么样的需求才是完整的需求？其实这个很难去界定，因为只有用户自己才是验证需求完整性的最合适的人。确保沟通需求时双方对于需求的认知无歧义并在实现过程中无其他因素变更的需求是完整的需求。相关人员在提需求的时候尽量从各个层面来考虑，从大的框架、业务流程、实现目的等方面来讲需求描述清楚。比如图标的配色与整个的风格不符或者这个地方的重点是突出图标，需要将其他地方的设计淡化，将图标的饱和度提高。比如客户反映在执行某项任务时发现我们产品的这个功能隐藏太深无法找到等（举例不一定对）。

2、不切实际的需求

我们经常会听到，这个产品要是有某某功能那就牛逼了这样的谈资。“我要天上的月亮”这样的大部分需求都是不切实际的需求，至于如何定义不切实际的需求？不切实际的需求不仅仅是指那些不能实现的需求，也指那些小众或者没有应用场景的需求。。

3、缺乏站在用户角度思考的需求

比如做婚纱摄影行业的O2O。当然导致这种行业失败的原因有多种，低频、用户的获取、转化等等。但归根结底还是自己YY出了一大堆的需求，而这种需求脱离了用户。需求的真伪我们放在后面来说。

4、需求的频繁变更

需求的频繁变更导致在处理的过程中忘记初心，最后需求的实现就变成了另一个话题。

沟通的问题

1、沟通的变质

相信大家有听说过西点军校的一个故事：

这个故事就反映出了在沟通中需求变质的问题，这里我不再赘述。

2、项目经理或执行人员的控制

由于需求在实现的过程中会涉及到整个项目的时间进度、成本预算、或者优先级等问题。项目经理或者执行人员会在这一过程将需求进行控制，比如担心拖延整个进度选择将需求的主要部分实现或者将需求放在下一个版本实现等状况也是阻碍需求的实现原因之一。

3、程序猿的断章取义

程序猿在实现的过程中将需求进行技术加工，将原本的需求断章取义做成另外一种的结果。大家应该有听过肥皂盒的故事：为了区分空的肥皂盒与装了肥皂的肥皂盒，一群博士生在讨论做一个这样的机器需要怎么来实现，而实际上只需要一台风扇即可。

以上说的涵盖了造成需求不能实现的大部分原因。当然这些都是表象，据其本质原因离不开利益冲突、工作量的增加，而这是另一个层面的问题了。

二、需求的获取及方法

西游记中的唐僧说得较多的一句话：我从东土大唐而来，前往西天拜佛求经。这句话涵盖了我从哪里来，要到哪里去以及做什么。同样需求从哪里来？

内部来源

1、领导以及同事，或者自身挖掘

一般一个公司只从事一个行业（如果多个行业，那就将同事局限在同行业），同事基本上是行业中的精英，他们能够对产品提出一些独到的见解和思考，从他们那里去探寻会得到一些意想不到的反馈。

2、自身挖掘

可以关注行业的一些动态、数据等报告，常见的几个统计报告网站：企鹅智库、易观智库、艾瑞咨询。也可以通过自己分析竞品来挖掘。

外部来源：用户或者客户、合作伙伴。我们可以通过接触到最终的用户来了解他们的需求。用户通常会用语言、动作、表情来反馈他们的真实意图。但基本上用户能说出来的需求只是基本的需求，更深层次的需求需要我们去挖掘。

了解了来源，如何获取？

内部来源的获取方法：

• 对于领导跟同事，需要有针对性的问题提问或者头脑风暴。这个跟用户访谈有点类似。
• 对于一些行业上的数据我们可以在大方向上引用数据。对于竞品分析出的需求，可以借鉴参考。

外部来源的获取方法：

1. 用户访谈。用户访谈是现在的一些公司比较常用的手段，因为这种方法比较有效并且灵活，能够根据现场情况进行应变。但是占用的时间也相对较长，信息的存在也片面。这种方法的要点是注意人群的选定以及需要注意访谈的技巧，涉及到话术及心理方面的因素不在这里分析。
2. 问卷调查。问卷调查的好处是调查面比较广，可以涵盖不同的用户群，但是这种调查不能深入。这种方法的要点是需要注意问卷的设计。
3. 现场观察。有句话说百闻不如一见，但是这种方法太耗时间。要点是需要有洞察用户行为举止能力的人执行。

以上都是关于需求得来源及获取方法，整个需求获取的过程，执行人员应该都要去主动获取，针对性的制定计划。至于每一个方法的实施步骤及要点，比如在访谈的时候需要注意用户有夸大事实的心理、有抗拒的心理等等这些需要在执行的过程中不断优化和提升。（如果步骤与要点一一写上，那可以成书啦!）

三、分析需求

当四面八方的需求汇集到一起时，这些需求的走向我们该如何处理？

筛选

这一步的作用是确定哪些需求是确定要实施的。

1、将不切实际的需求丢弃

不切实际的需求定义前面已经提到：不切实际的需求不仅仅是指那些不能实现的需求，也包含那些小众或者没有应用场景的需求。我们也可以称其中的一部分需求是伪需求，如果你不能通过应用场景来判断其真伪性，没关系，我们后面还会讲到如何来验证。

2、将与定位背离的需求丢弃

这里讲的定位包含市场和产品的双重定位。不是针对产品的目标消费市场的需求、不是产品的目标人群定位的需求都称之为与定位背离的需求，我们应该将这些需求丢弃。之前我在做一个视频流网关产品的时候犯的一个错误：有用户反馈需要有轮播的功能，而我当时认为可以考虑，而实际上这个功能与产品的定位不符。

分级

这一步的作用是确定需求什么时间点做。

需求筛选出来之后，需要对需求进行分级。

划分需求的优先级有多种方法：四象限法、商业价值与用户体验法、风险-价值法等等。我这里就拿常用的四象限法进行分析，如下图。

问题来了：如何界定紧急跟重要？

需求的紧急从大方向上应该要根据产品所处的阶段来考虑。产品的起步阶段的重点是核心功能的实现，验证产品的可行性。产品的发展阶段重点是功能的扩展和完善，需要做的是探索新的价值。产品的迭代阶段重点是用户体验的提升。在不同的阶段，需求的紧急度衡量的侧重点是不一样的。

大方向上考虑了之后，同一阶段的需求又如何进一步细分排序？这里应该考虑需求在实现上面的时间紧急程度，通常以其影响程度来衡量。如A需求再不处理，会影响50%的用户操作，影响程度恶劣，所以较为紧急。

需求的重要性从宏观角度看应该是根据需求对于用户的惊喜度来定。KANO模型中的三种需求：基本型需求、期望型需求、兴奋型需求。我认为这三种需求的重要性为：基本型需求＞期望型需求＞兴奋型需求。因为对于用户基本的需求如果不满足，这会引起用户的不满，这直接决定了用户是否继续探索你产品的其他功能。期望型的需求属于锦上添花，而用户兴奋型的需求如果满足了则会给产品增添不少好评与魅力。

再详细一点，如果筛选除了一堆重要的需求（同一宏观层级），又如何给重要性排序？这里我们可以根据需求的使用场景来决定：用户在什么情况下会涉及到该需求。说白了就是这种需求涉及的使用场景的多还是少来决定。

跟踪与管理

我相信大家都有各自一套管理方法，这里我也不拿出自己的管理与跟踪表格说事了，因为我的也不一定是好的或者是对的。

这里仅说一下管理与跟踪的要点:应该要包含需求源头，是谁提出？在什么场景下提出的即需求的描述详情？该需求的优先级如何，排在什么时间点做？处理该需求会影响那些因素？后续的计划是什么样的？

四、验证需求

如果前面的三步都做得比较好，那其实第四步就相对很容易了，只需要将处理好的需求（产品）再找相应的用户确认就好。但就怕前面三步都没有处理好而且也不做第四步进行验证就将产品投入市场，那会导致很多的问题。就像一个生意在没有确认是否可复制的时候就进行了盲目的扩张一样的道理。

需求的验证方法有很多，比如AB测试、比如定性定量分析等。具体用哪种方法，具体问题具体分析，下面我讲述一下较为通用的方法。

《四步创业法》里告诉我们如何来验证一个产品，其实也可以把方法应用到需求的验证上：将处理好的需求找特定的用户，看是否解决他们的实际需求就好。这里我们不谈论是软件产品还是硬件产品，方法都一样，只是周期长短不一样罢了。但是问题来了：我们上面说的通过问卷得来的需求，这些都是基于当前的市场来做的，适合于成熟的行业，那非成熟的行业如何验证？

1. 用最快的方法做出原型，这个原型可以只包含核心的功能。
2. 找到在这个行业的精英以及有创新意识的客户试用。这里为什么要有两种人群，因为行业的精英有可能也比较墨守成规。
3. 收集通过使用之后反馈出来的意见再讲原型改进，然后再找与产品定位的目标人群进行广泛测试。

以上，包含了一个需求的整个生命周期，这个周期我花费了差不多两年时间才对其形成一套完整的认知。如果你读到了这里，请反思一下这篇文章是否对你有所帮助。如果有不对的地方，欢迎指出，不胜感激。

本文由 @笔尖轻触 原创发布于人人都是产品经理。未经许可，禁止转载。