第一步、需求获取

为了保证能全面地获取信息，以更好地服务于产品设计和迭代，产品经理必须利用内部外部等多种渠道来获取用户需求。并且因渠道差异，产品经理所采取的方式与方法也相应会有所差异，所以产品经理还必须根据不同的渠道来选择需求获取的方式，并对获取的这些需求做初步记录。这就是本篇文章要讲的第一部分内容，也就是四步搞定需求的第一步：需求获取。

如上所述，需求获取这一步主要包括三个方面的内容：渠道、方式、记录。

一、需求获取渠道

对产品经理而言，需求获取的渠道主要可分为两类：外部渠道和内部渠道。

1.外部渠道

1）市场

需求和产品常常会受到行业政策调整的影响。如“净网行动”、“打车软件专车服务属非法营运”等。

2）用户

产品设计的初衷就是为了满足用户需求。

3）竞品

所谓的竞品，主要可分为两种。一种是用同样的产品功能满足同样用户需求的产品，另一种是用不同的产品功能满足同样用户需求的产品。竞品对用户需求的满足程度、满足方式既会对我们产生影响，也可以为我们的产品设计带来一定的启发。

4）合作伙伴

合作伙伴在商业模式当中扮演着重要的角色，因此他们的需求亦不容忽视。

2.内部渠道

1）产品

用户在使用产品时会产生行为数据，这些客观的数据一定程度上会反映出用户的需求。

2）老板

企业运转的根本目的在于盈利。产品在满足用户需求的同时必须兼顾公司的战略需求。而这方面需求通常是由老板或公司的高层来把握。

3）同事

一款产品从诞生到投入市场，主要需要以下角色参与：产品、研发、设计、运营、市场、销售、客服。其中，运营、市场、销售（解决合作伙伴对产品价值的质疑）、客服（解决用户遇到的问题）是距离用户最近的人，往往最能理解用户抱怨的点也最能提出产品建设性的意见。

4）自己

产品经理应该成为自己产品的用户，而且是产品的目标用户，在使用产品的过程去发现用户需求，如此一来才能更好地帮助用户解决问题。

二、需求获取的方式

需求获取的方式依来源渠道差异可分为外部和内部两大类：

1.外部

1）市场

●政策调整

关注行业相关的政策调整，并思考其对需求和产品的影响。

●动态资讯

关注行业资讯，思考行业动向对需求和产品的影响。

●行业数据

利用行业数据报告、行业数据统计工具获取需求。CNNIC、199IT、易观智库、艾瑞咨询等机构会不定期发布行业的相关报告，这些机构的报告相对而言比较有权威性，具有一定的参考价值。除了行业相关的数据报告，还有诸如百度指数、360指数等基于大量用户数据的数据统计工具。

2）用户

从用户处获取需求，主要通过线上的意见反馈、论坛、App Store评论、线下的用户访谈、问卷、日常观察等方式。这些方式方法概括起来主要可分为两大类：用户调研、用户反馈。

PS：腾讯内部有一个需求研究法则：10/100/1000法则。它的意思是说产品经理每个月必须做10个用户调查，关注100个用户博客，收集反馈1000个用户体验（这想必大家都知道）。法则是死的，但人是活的。虽然我们很可能没办法做到每个月做10个用户调查、关注100个用户博客、收集反馈1000个用户体验，但我们应该记住这个法则传递出的理念：去了解你的用户，尽最大可能去了解你的用户！（这很大程度上依赖于三件事：用户调研、用户反馈、数据分析）

●用户调研

用户调研就是通过问卷调查、用户访谈、信息采集等手段来挖掘用户需求的方式。产品经理要想真正了解用户的需求，就要尽量走到用户当中，去深入了解他们在具体场景下的想法与感受。要做到这一点，很大程度上需要依靠用户调研。

●用户反馈

产品上线后，我们就可以开始收集用户反馈了。用户反馈可以通过线上的意见反馈、产品论坛、App Store评论、安卓应用商店评论、社交媒体评论等渠道获取。其中线上的意见反馈存在一个前提，即产品本身要有反馈入口和良好的反馈机制，如此一来用户才有抱怨产品的地方（之前听一个前辈抱怨XX学院，说发了N封邮件反馈产品问题，统统石沉大海。从那以后他再也不反馈问题了。。。）。通过这些反馈，我们可以了解用户在使用产品的时候遇到的问题以及一些之前根本没考虑到的需求点。

3）竞品

●竞品分析

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

并且，竞品分析应当是持续性的。也就是说，我们应该持续关注竞品的动态，并依据竞争对手的变化适时对自身产品做出调整（这不意味着竞品加了一个shit功能我们也要跟着加，一切应以目标用户的真实需求为思考原点）。

4）合作伙伴

●深入沟通

不同领域的企业，合作伙伴很可能大相径庭。因此，关于合作伙伴的深入沟通这件事不能一概而论。

2.内部

1）产品

●数据分析

通常情况下，有两种东西会直观地反映出一个人的心理，一个是他所说的话，另一个是他所做的事。用户调研和用户反馈，就是去听用户“说话”。而数据分析，则是去看用户”做事”。所谓“做事”，就是用户在使用产品过程中所产生的行为。而用户产生的这些行为，会以数据的形式被记录下来。我们所说的数据分析，就是指这一部分数据的分析。这一部分数据包括PV、UV、日活、月活、页面访问路径、单次使用时长、次日留存率等。对这些用户行为数据进行分析，可以帮助产品经理更好地理解用户的真实需求。

关于这个“更好”，容Smith我举个不太恰当的例子：一个熊孩子跟他爸出去逛街，他在一家玩具店门口停了下来，边说自己累了走不动了边盯着玩具店橱窗上挂着的咸蛋超人流口水。如果你是他爸，你会信他吗？显然不会。因为你不止听了他说的话（累了走不动了），还看了他做的事（盯着玩具店橱窗上挂着的咸蛋超人流口水）。由此，你可以轻易判断出他是想买玩具。同样的道理，产品经理光听用户说还不够，还得看他具体怎么做。这就是上面为什么说数据分析可以帮助产品经理更好地理解用户真实需求的原因所在。当然啦，把用户比作熊孩子，这是一个美丽的错误。。。。

2）老板

●深入沟通

老板往往是站在公司战略层面提出需求的，多数情况下都要特别考虑。当然，老板有时也会基于个人喜好提需求。如果老板的需求是有问题的，最好用委婉一点的方式让他明白，毕竟他是给你发工资的人啊。关于这一点，富兰克林老先生有句经典名言：“ 如果你想说服他人，要诉诸利益，而非理性。”你告诉老板他是错的不顶用，因为他未必真的愿意承认自己的错误。但如果你告诉他做了这个需求会使得公司的利益受损，那么他就会好好考虑一下你说的话了。

PS：富兰克林的这句名言不只适用于跟老板沟通，它适用于跟所有你想说服的人沟通，比如跨部门的沟通。

3）同事

●深入沟通

一款产品从诞生到投入市场，主要需要以下角色参与：产品、研发、设计、运营、市场、销售、客服。其中，运营、市场、销售（解决合作伙伴对产品价值的质疑）、客服（解决用户遇到的问题）是距离用户最近的人，往往最能理解用户抱怨的点也最有可对产品提出建设性意见。因此，产品经理应该多与这些同事交流，通过各种方式把他们眼中看到的问题挖掘出来。同时，产品经理也可以把自己需要了解的一些问题传达给运营或客服，让他们在与用户的接触过程中，侧面问一问这些你所关心的问题。

4）自己

●使用产品

如果罗永浩一边用着苹果手机一边跟你说”我不为输赢，我只是认真“，你还会相信他的情怀吗？显然不会，连锤子之父都不用锤子，锤子才用锤子啊。同样的道理，作为一个产品经理应该成为自己产品的用户，而且是产品的目标用户。产品经理使用自己的产品的次数越多，就越有可能在使用过程中发现需求、更好地帮助用户解决问题。

当然，我们不能强迫一个男性产品经理成为自己设计的女性产品的目标用户，这恐怕有违人性。因此，还有另外一种方法可以帮助产品经理从产品使用中获取灵感，那就是角色模拟。所谓角色模拟，简单来说就是模拟用户在各个场景下的行为。除此之外，产品经理在使用产品时有一点需要特别注意，那就是要避免成为产品的重度用户，以免影响自己对于普遍用户行为的判断。

●观察生活

在现实生活中发现需求。说白了，就是时刻保持好奇心，注意观察平常生活中遇到的一些问题，想想这个问题能否用产品来解决。

三、需求记录

产品相关人员在获取需求之后，还需要对数据进行一个初步的记录，以便于后面产品经理对需求进行分析、管理与实现。而因为每个公司对需求记录的要求是不大一样的，所以这里仅列举需求初步记录需要有的一些基础要素：

1.需求类型

在需求记录时，明确需求的类型，将使得需求更有条理性，便于我们后面的需求管理与实现。而需求要有类型，首先我们必须对需求进行分类。以下是两种基本的分类法：

1）按产品属性划分

需求按性质划分，可分为idea、新增、优化、Bugfix这四种类型。

2）按产品职能划分

需求按职能划分，则可分为功能类需求、运营类需求、数据类需求、设计类需求这四种类型。

PS：需求的这两种分类法来源于@粽小喵的《『三分法』搞定产品需求分析》

3）按需求性质划分

需求获取，按性质可以划分为两类：显性的、隐性的。

我们直接间接从用户口中得知的需求就是显性需求。比如说，滴滴打车满足的是用户便捷出行的需求。比如说我们在出行的时候,还会有聊天和社交的这种需要。你在和用户沟通的时候，他可能无法很清晰的给你表达出来。因为用户无法表达，所以这一部分需求就需要产品经理通过分析自行得出。

因此，在填写需求记录表的“需求类型”这一栏时，格式应该是像这样的：优化/数据类/显性

2.需求来源

从需求获取阶段我们可以看出，需求的来源是多种多样的。每一个提出需求的主体都会有自己特定的立场和观点，明确这个主体是谁，将有利于我们更好地理解他所提出的需求。

在填写需求记录表的“需求来源”这一栏时，可以参照需求获取阶段的几种获取方式，然后以这样的格式记录：用户-用户反馈-产品论坛【昵称】（最好有该用户的联系方式以及简单的用户背景资料）。如果是内部人员提出的需求，则最好以这样的格式记录：内部-运营部-小明（这样做的目的在于方便需求存在疑问时可以快速地找到具体需求提出者，并与之沟通）。

3.需求内容

所谓需求内容，就是需求是什么。

在填写需求记录表的“需求内容”这一栏时，尽量用（主语+谓语+宾语）的语法结构，不要加入主观的修饰语句，避免对后面的需求分析做出干扰。

4.需求场景

需求场景，在我的理解就是对需求产生整个过程的描述。这样来看的话，它其实相当于涵盖了两部分的内容：场景和原因。考虑到场景与原因是一体的，所以我在这里选择不做区分。而关于需求场景的记录，我觉得有必要引入一个概念，这个概念叫“需求场景分析法”。所谓“需求场景分析法”，其实就是利用一些叙事的基本元素对需求产生整个过程的描述。它的具体内容是这样的：

时间（在什么时间碰到了问题？）

地点（在什么地点碰到了问题？）

人物（谁碰到了问题？）

事件（具体碰到了什么问题？）

起因（为什么会碰到问题？）

经过（碰到问题之后他的反应是什么？）

结果（问题是否得到解决？或者说他想怎么解决？他的感受是什么？）

在填写需求记录表的“需求场景”这一栏时，则尽量依据需求场景分析法的各个要素来。

（至于需求编号、记录时间、记录人员这几项，实在没什么好说的，就无需赘言了。）

第二步、需求分析

需求有真假、强弱、缓急……在资源（人力、金钱）有限的情况下，做哪些不做哪些，哪些先做哪些后做，这些都是需要产品经理做出判断的。而判断，须经由分析得出，不能拍脑袋决定。。。换句话说，需求分析的目的，其实就在于通过一定的分析决定做哪些需求不做哪些需求，哪些需求先做哪些需求后做。

需求分析这一步，具体又可以分解成三个部分：需求筛选、需求透视、需求排序。这三者的逻辑是这样的：首先筛掉不做的需求，其次对要做的需求进行进一步提炼，最后对提炼过的需求进行优先级排序。至于为什么是这样一个步骤，是基于这两方面的考虑：1.对不做的需求进行提炼和排序是显然是在做无用功 2.而对未经提炼的需求进行价值评估和优先级排序很可能会产生大的误差。

一、需求筛选

需求筛选可以说是初步的需求分析，主要有4个考察维度：

1.真实性

这个需求是否是目标用户的需求？

目标用户是否真的存在这个需求？

通过考察需求的真实性，过滤虚假的需求。

2.一致性

需求是否符合定位？（战略定位、产品定位）

需求的覆盖面有多大？（有多少目标用户有这种需求？这个需求有多大程度上的代表性？）

出于个人习惯或者特殊场景，很多时候用户提出的需求是存在片面性的。因此，在需求分析过程中应经常使用用户场景分析法，全面了解该需求。

通过考察需求与战略定位、产品定位、目标用户的一致性，过滤掉与产品方向不一致的需求。

（这里同样可以运用到上面所提到的场景分析法）

3.价值性

需求能带来什么价值？（用户价值、企业价值）

需求能带来多少价值？（用户价值、企业价值）

需求实现要付出多少成本？（人力、金钱、时间)

需求时间的投入产出比如何？

通过考察需求的价值性，过滤掉没有价值、价值不大或投入产出比不理想的需求。

（ 在此过程中，可以运用KANO模型，过滤掉反向需求和无差异需求。）

4.可行性

需求在现有资源条件下是否能够实现？（成本和技术可行性）

如果不能，之后是否有实现的可能？（预估，内部沟通）

通过考察需求的可行性，过滤掉超出企业实现能力的需求。

二、需求透视

需求按认知层面的划分，可以分成表面需求和本质需求。需求透视这一步骤，目的就在从获取的表面需求中提炼出用户的本质需求。理解用户的本质需求，则有利于我们更好地提出产品需求。

在具体说这三个概念之前，我觉得有必要再引入一个概念，这个概念叫“需求鸿沟”。“需求鸿沟”的大体意思就是：产品所能满足的需求和用户的真正需求之间，总是存在着一道不可跨越的鸿沟。我们所做的任何努力，都是在缩小这一道鸿沟。

还是以福特造车的老梗为例吧。福特在没造车前曾经问消费者们想要什么，消费者们告诉他说是更快的马。要是一般人恐怕就信以为真了，然而机智的福特早就看穿了一切，他知道消费者们本质上追求的是更快的速度而非更快的马。于是乎，他基于更快的速度这个本质需求造出了车。

马呢，是一种产品，它一定程度上满足了用户对快的需求。而快的极致是什么？瞬移。瞬移在我们现有的技术条件下是不可实现的。但我们能做的就是让用户更快一点，至少比马更快——那就是给用户一辆汽车。也就是说，产品所能提供的，永远是不完美的解决方案。表面需求，就是用户自己想出的1.0版解决方案。本质需求，就是不可达到的终极目标。产品需求，则是产品经理基于现行条件给出的优于用户所提解决方案的2.0版解决方案。

关于这三个概念，其实还有一个典型的例子。这个例子来自于嘀嘀的产品技术副总裁张博在接受采访时曾说过的一段话：(我认为这段话同样很好地阐释了表面需求、本质需求和产品需求者三个概念)

以销售为导向的思维方式是直接满足客户的需求，客户要什么我就给什么，但是用户说的不一定是他真正想要的。以产品为导向的思维方式则是用户要什么，得分析用户背后的需求是什么，从需求的本质倒推产品方案。以前司机在操作其他软件的时候，会突然跳出嘀嘀打车的抢单界面，容易误点抢单。有司机就提出能否增加确认键，多点一次确认键才是真正的抢单。这是用户说的，但产品是不是就该这样做呢？当时产品按照司机的建议做了，反对的声音更大，二次确认键操作麻烦，带来安全隐患。“我们犯了一个错误，司机真正的需求是想解决误抢单的问题，而不是要一个确认键，确认键只是解决问题的方法之一。

PS：-“需求鸿沟”是我从《需求:缔造伟大商业传奇的根本力量》这本书中得到的一个概念，有兴趣的朋友可自行翻书。

–  产品需求更多是属于需求实现环节的概念。在这里提出来主要是因为它跟表面需求、本质需求存在强关联性，和这两者一起能对需求做出更为完整的呈现，方便理解。

1.表面需求、本质需求、产品需求

1）表面需求（用户想要的）

用户经常从自身角度出发得出问题的解决方案。因为对产品定位、设计的依据等情况不了解，他们的建议很多时候并不是该功能的最好实现方式，也就不足以直接作为产品规划的直接依据。如果根据表面需求来设计产品的话，很可能会出现“头痛医头，脚痛医脚”的情况。

2）本质需求（用户需要的）

用户想解决的根本问题。获得用户的本质需求更可能找出更合理的方案来解决用户的问题。

3）产品需求（我们能给的）

依据用户想解决的根本问题，得出的更好的问题解决方案。解决方案可以理解为一个产品，一个功能或服务，一个活动，一个机制。产品经理首先需从用户那里收集反馈信息，分析用户需求，再根据用户需求进行产品功能规划，这些待实现的产品功能对于产品来说就是产品需求。收集用户反馈，分析用户需求，最终都是为了生产产品需求。

三、需求排序

需求排序，简单来说就是依据需求的重要性给需求排列优先级。需求排序有三个基本考虑因素，分别是战略定位、产品定位、用户需求。具体而言，有七个主要的考察维度：

1.相关性

考察需求与企业的战略定位、产品定位之间的相关性。一般情况下越靠近基础服务的需求越重要，因为越基础的服务越靠近产品所满足的本质需求。

2.逻辑性

考察需求之间的逻辑关系。有些需求之间是存在逻辑顺序关系的，必须先完成A之后才能去做B。比如如果没有完善的基础服务，功能性的需求往往也无法实现。

3.价值

考察需求能创造的企业价值、用户价值的性质（哪方面）与数量（多少）。

4.强度

考察需求的强弱。强需求通常具备三个特征：必要性（不可缺少）、高频次（需求次数多）、持续性（长时间保持足够的需求频次）。在考察需求强弱时，可以参考马斯洛需要层次理论。

5.广度

考察需求的覆盖面。也就是具备目标用户占比，或者说提出这种需求的目标用户数量。

6.频率

考察需求在单位时间内出现的次数。一般情况下需求的频率越高，其重要性越高。

7.类型

依据KANO模型对需求做出的分类，考察需求的类型。KONO模型认为用户需求可分为三类：

1）基本型需求

用户认为产品必须提供功能来充分满足的需求。如果这些需求没有得到满足，用户基本上就不会使用我们的产品。如果这些需求得到满足，用户对产品的满意度也不会有多大的波动。比如微信中的聊天功能。（也就是我们常说的痛点）

2）期望型需求

用户认为产品应该提供更优秀的功能来更好地满足的需求。期望型需求并不是产品必须有的需求,有的期望型需求只是用户期望有的，但是用户也不一定会明确表达出来。如果这些需求没得到满足，用户对产品的满意度会下降。一般用户进行产品反馈的，大都是期望型需求。比如微信中聊天表情虽然包。（也就是我们所说的痒点）

3）兴奋型需求

用户自己并没有意识到的隐性需求。这类需求的满足可以给用户带来极大的惊喜。当这类需求得到满足后，用户对产品的满意度和品牌忠诚度将会有显著提高。因为用户没有意识到的缘故，所以这类需求即使没有被满足，也不会引起用户不满。比如微信聊天中的红包功能。（也就是我们说的兴奋点）

这三类需求的重要性判断原则是这样的：

基本型需求最重要，期望型需求和兴奋型需求在不好判断时通过需求重要性公式确定。

期望型需求和兴奋型需求的重要性公式：重要性=功能使用用户百分比(用户使用率)×功能使用次数百分比(功能使用率)×类别重要性百分比

（通常情况下，我们可以将期望型需求百分比定为50%,兴奋型需求百分比定为25%）

关于这个公式，我们可以用一个案例来说明。假设A功能和B功能做一个比较,A功能是期望型需求 50% ，假设有100个用户，有50个使用过A功能，A功能的用户使用百分比就是50%，这50个人使用了10000次，那么使用次数百分比就是10000除以50为200。类别重要性就是50%乘以200乘以50%，级别数值就是50；B功能是兴奋型需求，百分比为25%，100人中有30个人使用过B功能，用户百分比就是30%，30人中使用了90000次，使用次数百分比就是9

 

 

 

• 
   

 

 

 

 

 

 

 

 

作者：Zealtric
链接：https://www.jianshu.com/p/bf91301437f1
來源：简书
简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。

最后

以上就是时尚眼睛为你收集整理的软件工程—需求分析阶段第一步、需求获取第二步、需求分析的全部内容，希望文章能够帮你解决软件工程—需求分析阶段第一步、需求获取第二步、需求分析所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。