作为一枚互联网产品经理您是怎么做需求管理呢？

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

故事一：

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

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

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

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

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

故事二：

福特：你想要什么？

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

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

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

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

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

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

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

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

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

一个是需求本身的问题

一个是沟通的问题

需求本身的问题

1、需求的不完整

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

2、不切实际的需求

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

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

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

4、需求的频繁变更

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

沟通的问题

1、沟通的变质

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

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

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

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

3、程序猿的断章取义

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

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

二、需求的获取及方法

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

内部来源

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

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

2、自身挖掘

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

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

了解了来源，如何获取？

内部来源的获取方法：

对于领导跟同事，需要有针对性的问题提问或者头脑风暴。这个跟用户访谈有点类似。

对于一些行业上的数据我们可以在大方向上引用数据。对于竞品分析出的需求，可以借鉴参考。

外部来源的获取方法：

用户访谈。用户访谈是现在的一些公司比较常用的手段，因为这种方法比较有效并且灵活，能够根据现场情况进行应变。但是占用的时间也相对较长，信息的存在也片面。这种方法的要点是注意人群的选定以及需要注意访谈的技巧，涉及到话术及心理方面的因素不在这里分析。

问卷调查。问卷调查的好处是调查面比较广，可以涵盖不同的用户群，但是这种调查不能深入。这种方法的要点是需要注意问卷的设计。

现场观察。有句话说百闻不如一见，但是这种方法太耗时间。要点是需要有洞察用户行为举止能力的人执行。

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

三、分析需求

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

筛选

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

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

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

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

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

分级

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

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

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

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

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

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

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

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

跟踪与管理

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

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

四、验证需求

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

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

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

用最快的方法做出原型，这个原型可以只包含核心的功能。

找到在这个行业的精英以及有创新意识的客户试用。这里为什么要有两种人群，因为行业的精英有可能也比较墨守成规。

收集通过使用之后反馈出来的意见再讲原型改进，然后再找与产品定位的目标人群进行广泛测试。

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

本文将介绍一种需求规划、管理的可视化方法—用户需求地图，该方法将软件开发项目的需求变成一张二维地图，而不是传统的简单列表，只要这一张图，就可以完成全部用户需求的管理工作。

该方法有如下一些优点：

让你更容易看清软件产品的全貌，了解产品功能的完整性

为用户需求筛选和划定优先级提供可视化的工具，帮助你做出决策

更好的进行迭代增量式开发，同时确保有计划、可控的发布产品

为传统的项目计划提供了一个更好的替代工具

有助于管理项目范围，避免范围的无限制蔓延

先上一个用户需求地图的样例，后续介绍如何创建这样的地图

一、需求的获取

常用的需求获取方法包括以下几种：

1、用户访谈

用户访谈是一种最基本的需求获取手段，它是指分析人员以个别访谈或小组会议的形式与用户进行初步的沟通。用户访谈的形式包括结构化和非结构化两种，结构化是指分析人员按照一定准则事先准备好一系列问题，通过用户对问题的回答来获取有关目标软件方面的内容；非结构化则是只列出一个粗糙的想法，根据访谈的具体情况来进行发挥。

2、用户调查

在进行用户访谈时，由于很多关键人员的时间有限，不易安排过多的时间或者项目涉及的客户面较广，不可能一一访谈。因此，就需要借助用户调查的方法，通过精心设计要问的问题，然后下发到相关的人员手中，让他们填写，再从所填写的内容中获取系统的需求信息，这样就可以克服上述的问题。

用户调查最大的不足就是缺乏灵活性，而且可能存在受调查人员不能很好表述自己想法的限制。

3、现场观摩

俗话说，百闻不如一见，对于许多较为复杂的流程和系统而言，是很难用自然语言表达清楚的。因此，为了能够对系统的需求获得全面的了解，实际观察用户的操作过程就是一种行之有效的方法。现场观摩就是走到客户的工作场所，一边观察，一边听客户讲解，甚至可以安排人员跟随客户一起工作一段时间。这样就可以使得分析人员对客户的需求有更加直观的理解。但是，在现场观摩过程中必须切记：建造软件系统不仅仅只是为了模拟客户的手工操作过程，还必须将最好的经济效益、最快的处理速度、最合理的操作流程和最友好的用户界面等作为软件设计的目标。

4、竞品分析

可以将竞品分为两大类：用与我们相同或相似的功能满足用户同样需求的产品、用与我们不同的功能满足用户同样的需求的产品。所谓竞品分析，就是寻找出有代表性的竞争产品，从多个维度对比该产品与我们的产品之间的相同之处与不同之处，从中分析出两者的优劣之处，得出结论，为产品的设计与迭代提供突破口或带来启发（这是指单次的竞品分析）。

二、需求分析

需求分析方法有：

结构化分析方法：包括面向数据流的结构化分析方法，面向数据流结构的Jackson方法和面向数据结构的结构化数据系统开发方法。

面向对象的分析方法：从需求分析建立的模型的特性来分，需求分析方法又分为静态分析方法和动态分析方法。

结构化分析方法

结构化分析方法的实质是着眼于数据流，自顶向下，逐层分解，建立系统的处理流程，以数据流图和数据字典为主要工具，建立系统的逻辑模型。

结构化分析的步骤如下：

通过对用户的调查，以软件的需求为线索，获得当前系统的具体模型

去掉具体模型中非本质因素，抽象出当前系统的逻辑模型

根据计算机的特点分析当前系统与目标系统的差别，建立目标系统的逻辑模型

完善目标系统并补充细节，写出目标系统的软件需求规格说明

评审直到确认完全符合用户对软件的需求面向对象的需求分析方法

面向对象的需求分析方法

面向对象的需求分析方法的核心是利用面向对象的概念和方法为软件需求建造模型。它包含面向对象风格的图形语言机制和用于指导需求分析的面向对象方法学。目前已经衍生许多种OOA方法。

每种方法都有各自的进行产品或系统分析的过程，有一组可描述过程演进的图形标识，以及能使得软件工程师以一致的方式建立模型的符号体系。现在广泛使用的OOA方法有统一的建模语言（UML）已经在企业中广泛使用，它把Booch、Rumbaugh和Jacobson等各自独立的OOA和OOD方法中最优秀的特色组合成一个统一的方法。UML允许软件工程师使用由一组语法的语义的实用的规则支配的符号来表示分析模型。

在UML中用5种不同的视图来表示一个系统，这些视图从不同的侧面描述系统。每一个视图由一组图形来定义。

三、创建需求地图

1、需求地图的组成

需求地图主要由三部分组成，由上自下分别是模块区、待排期需求区和已排期需求区，已排期需求区由多个发布计划组成，如下图所示：

2、模块的分解

模块就是将待开发的产品的功能进行分解，按功能从属关系表示的树状层级视图。待开发产品的各子系统、子模块可以看作是产品目标下层的功能，对其中每项功能模块还可以继续分解为第三层、第四层……甚至更多层级的功能模块，理论上根据待开发产品的规模，可以无限极的分解产品的功能模块。

通过需求分析得到的模块形成了待开发产品的“骨骼”，把这些模块录入翼发云软件研发管理系统后，能够自动在用户需求地图中自动生成层级的、包含关系的模块关系图，显示在需求地图第一部分“模块区”中。

邮件管理系统通过需求分析得到第一层级的四个模块：邮件组织、邮件管理、日历管理、联系人管理。依次再将这些模块分解为更小、粒度更细的第二层级的模块，邮件组织分解为邮件搜索、邮件整理两个子模块；邮件管理分解为发送邮件、读取邮件、删除邮件三个子模块；联系人管理分解为创建联系人、编辑联系人、删除联系人等。（注：橙色的模块是最下层的模块）

对应的树形视图如下所示：

3、用户需求的生成

根据用户需求调研和分析，把用户需求的基本信息如名称、需求描述、验收标准、预估工作量、优先级等录入系统。

三、用户需求的排期

当用户需求录入系统后，会出现在需求地图的待排期区域里，待排期区域里的需求就是还没有安排开发时间的需求，这时可以通过拖拽的方式，把需求拖到发布计划里，从而完成需求的排期工作，排期区域里的需求就是已经安排了开发的需求。是不是很简单。

通过多次拖拉用户需求后，最终完成了用户需求地图：

来源：pm28