需求是一个被互联网人说烂的词，却也是最基础的词，产品说需求、运营也说需求、市场也说需求。本篇文章将全面剖析需求的挖掘和分析，总结了管理需求的方法，快来看看吧。

　　“阿境，用户想要在动态上加一个话题功能，我们规划一下吧”

　　“这是用户需求，不是产品需求”

　　“本质上用户是为了能给自己发表的内容打上标签是吗？”

　　“是的，并且需要先判断是真实需求还是伪需求，再进行定义，我们也可以通过用户需求，来分析出我们的产品需求，从而确定我们要做的方案”

　　若你是个PM，想必上述对话的场景，屡见不鲜。

　　那么有几个问题大家思考下：

　　他们说的需求是同一类吗？究竟什么是需求？本质是什么？什么是产品需求跟用户需求？真实需求与伪需求怎么辨别？对于需求分析你有一套明确的思路吗？需求的来源、管理、优先级排期等你能够侃侃而谈吗？……

　　在看过这些问题之后，若你能够在很短的时间内有了明确想法，那阿境觉得可以关闭掉文章，因为这是浪费你的时间。

　　如果没有，那么！且听厦门吴彦祖阿境啰嗦一下吧。

　　产品经理的职责便是在最短时间内最大化地创造价值，那么接触最多的的便是日常处理的需求，而需求分析也是非常关键的一步。

　　如果在看过问题之后，对于部分实施的方法还有疑问，或者是想要系统地进行需求的认知，那么不妨往下看看。

　　另：

　　附上本文导图框架，节约时间。若您感兴趣，可继续深入阅读；若不感兴趣，感谢光临。

　　什么是需求？

　　百度百科的定义是：需求是在一定时期，在一既定的价格水平下，消费者愿意并且能够购买的商品数量。

　　这个定义也是基于经济学当中的定义，如果把它套上产品的帽子，那么我们可以转变为：

　　需求是在一定时期，在一既定的场景下，为了解决某个问题而激发出用户对于某种目标的渴望。

　　从中，我们可提炼出几个点：时间、场景、提出者、使用者、方案。

　　而在实际工作中，脱离了时间、场景的需求，也往往容易被我们忽视。

　　综上所述，简单来说，需求就是在特定的场景下，用户所产生的问题。可以用“用户+场景=需求”的方式来理解，也可以说，需求是预期与现状的差值。

　　天主教教义当中，有七宗罪，分别是：傲慢、嫉妒、暴怒、懒惰、贪婪、暴食、色欲。而我们的产品，正是解决人身上所带来的原罪的产物。

　　而从马斯洛需求模型来看，有自我需求、尊重需求、社交需求、安全需求、生理需求。

　　从这两个方面上来看，需求源于人，最初的源头在于用户。而用户的存在，必然会遇到这样那样的问题。

　　一个需求归咎到底，还是满足了用户不同等级的欲望。

　　需求的本质是对用户欲望的满足，以及消除用户的恐惧感，从而解决用户的实际问题。

　　一款好的产品一定是能满足人性或者欲望的。

　　而产品本身是众多需求的集合体，根据不同的组合而成为当前产品的形态，产品功能则是满足了用户的目的，而需求和产品功能是一一对应的。

　　所以我们说，产品经理在处理需求的时候，所具备的同理心这一特质，才能够更好的洞察需求，洞察需求的过程也是在洞察人性，即洞察需求的本质。

　　先来看一句话“用户给产品经理提了一个需求，研发评估了下这个需求不能做”。

　　这当中出现了两个“需求”，这两个是同一个意思吗？

　　很显然不是。

　　从这个简单的例子可以看出，无论是用户、产品经理，还是业务人员，都在谈需求。

　　而需求被赋予了更多的含义时，就需要引入其他更深层此次的概念加以区分。

　　比如，上述例子中，前者是用户需求，后者是产品需求。

　　用户需求主要是指出用户想要怎么做，产品需求则更多的是指导产品需要怎么做。

　　1）什么是用户需求？

　　用户需求是用户当前尚未满足，又渴望被满足的欲望，并由此产生的方案。当用户使用得起产品，并且产品并不能够满足用户当前使用时，用户才会对产品产生新的需求，也就是我们所说的用户需求。

　　用户需求有个较大的特点，不能够指导产品开发，更侧重描述用户想要达到的目的，借此所提出的需求方案（想要的东西），则为用户需求。

　　2）什么是产品需求？

　　产品需求是用户需求经过产品经理的“加工”后所诞生的产物，输出具象的产品方案后实现，在实现之后完成产品既定的数据目标，则为产品需求。

　　产品需求更侧重能够指导产品开发，并且指导产品完成自身的目标（以数据指标作为目标的依据）。

　　3）用户需求如何转化成产品需求？

　　当我们清楚用户需求与产品需求之后，那么我们如何将用户需求转化成产品需求呢？

　　作为产品经理，我们需要收集清楚信息，经过严格且缜密的需求分析，才能达到将用户需求转化成产品需求的目的。

　　要解释真实需求与伪需求的区别，可以看个例子：

　　做个市场调查，问1千个用户是否喜欢黄金，几乎所有用户都是肯定回答。那么这个时候就认定黄金是当下用户的需求，那么便过于草率了。

　　因为再深究下去，用户买了黄金干什么？对黄金的了解清楚吗？等等问题，深入了解完一番之后，用户可能就不会买了。

　　人性是贪婪的，“需要跟购买”是两回事，用户总是“说一套，做一套”。

　　再举个例子，用户告诉我们他需要钱，如果你不追问，可能只是知道他需要钱，并不清楚拿着钱去做什么。用户告诉我们的是他“想要”的东西，而我们需要知道的是“用户内在的心理预期”，从而了解用户的真实需求。

　　可以说，某些情况，用户“欺骗”了我们。

　　那么这完全是用户的错吗？

　　不是的，用户有时候都不知道自己更需要什么，他们更倾向于给出解决方案，当他们描述出他们的意向内容时，作为产品经理的我们，需要去剖析，从“伪需求”的表层下，挖掘出用户的“真实需求”

　　“伪需求”指的是当前用户并不一定需要，而是根据他们遇到问题所提出的解决方案之一，但并不一定能够完全解决他们当下的问题。

　　“真实需求”是通过梳理需求提出方当前的情况，遇到的问题所分析出来的结果。

　　有一句话在产品界流传甚广：“如果我当初问人们想要什么的话，他们只会告诉我想要更快的马。”

　　从而我们知道，用户的需求是想要一个比走路更快的交通工具。

　　这其实是个谬论，交通工具并不是结果，而是过程。

　　不妨再问一句：然后呢？

　　可能事实上是利用交通工具去上班、去自驾游等，目标不同，所能满足用户需求的产品也不同。

　　由于阿境处于游戏分发行业，恰逢近期接触到了许多用户的反馈，拿其中一点举个例子：

　　“我想要更快的游戏速度体验”

　　在没有深入挖掘之前，我们可能会一股脑地去提升服务器容量、优化游戏代码质量，从而提升游戏速度，但用户是否是真的单纯地想提升游戏速度呢？

　　做几个假设：

　　“更快的游戏速度体验→在有效的时间内玩到更多的游戏内容”“更快的游戏速度体验→获得与游戏对手相同的速度→击败对手”“更快的游戏速度体验→获得成就感”……

　　就这几个假设来看，相同的需求描述，是不同的需求点：

　　A目前遇到的问题是游戏时长少；B的问题是游戏卡顿引发地对战失败，想要赢得胜利；C的问题是在游戏中获得成就感；那么，我们是不是可以这么解决呢：

　　针对于A，提供个防沉迷账号；针对于B，提供个游戏加速器；针对于C，提供相应的成就徽章体系等；乍一看，毫无毛病，仿佛一下子解决了用户的需求，于是又是一番大刀阔斧地改动优化。

　　让我们把自身再抽离来看，ABC是否有更隐蔽的点需要我们去挖掘呢？

　　别忘了，人在描述一件事情的时候，往往会将观点以有利于自身的角度加工并阐述。

　　A可能是因为家长限制了娱乐的时间，从而无法获得更多的娱乐时间，即使提供了防沉迷的账号，也无济于事；

　　B可能是自身技术不太好，即使在相同的速度体验下，依然打不过对手；

　　C可能是对于游戏投入的不够多，导致在游戏当中无法获得更高阶的奖励（物质与名气）；

　　若是如此，那么所应该提供给ABC的功能，可能又是另外一番答案。

　　从上面几个简单的例子，抽象来看，可以剥离出几个观点：

　　1）对于提出问题，用户更倾向于给出解决方案

　　人们往往倾向于解决问题的方案，而很少关心问题本身。所以我们常常会得到“我想要一匹马”的这种声音。

　　并不是用户提出的解决方案对于产品没有建设性，而是往往人在迫切解决自身问题时，提出的观点并不能查观全貌；

　　且用户并非产品的主导者，仅对部分功能有使用，那么在这个前提下，用户提出的解决方案能够一定程度地解决用户当前遇到的问题，但却可能延伸出更多的问题；

　　作为产品经理，通过自身对于产品的目标定位及价值理解，重视用户的解决方案，衡量解决方案底下所埋藏的需求的价值，才是重中之重。

　　2）在描述需求时，用户往往会将自身观点进行或多或少地加工

　　当用户对自身需求有隐瞒时，我们也就对需求的理解有偏颇，相同的解决方案，可以延伸出不同的需求。

　　由此，通过设定不同维度的问题，引导用户以描述性的角度，阐述自身的问题，才能够最大化地避免用户对于自身需求的美化加工。

　　3）需求并不是绝对的，在不同的阶段，用户会给出不同的需求观点

　　在初入游戏的时候，我们更需要的是一个教程带领我们了解更多的游戏攻略；

　　在游戏中度用户的时候，我们更需要的是游戏的体验性，攻略、工具等可能是在这个阶段中较为合适的需求。

　　在成为游戏深度用户的时候，我们更多的是在游戏中得到成就感，游戏成就体系等则应运而生。

　　由此可见，需求并非千篇一律，不同的阶段，用户提供到的是不同的需求观点。

　　“小时候我想要一颗糖，长大了我想要一辆跑车”也就是这个道理，需求受制时间的因素影响，也受制自身的发展影响。

　　这边的挖掘需求更多的是指主动地去挖掘产品需求。

　　这边有两种方式，一是从用户身上入手，从用户身上了解需求；二是从产品数据上入手，从数据上洞察需求。

　　1）更好地洞察用户需求

　　洞察用户的需求本质是还原用户真实的需求，一般会采用直接访谈、问卷的形式，但是用户全靠一张嘴，因为所处的环境、心境的不同，往往得到的结果会有偏颇，在此阿境介绍两个方法。

　　一是深度访谈的方式，二是真实融入用户场景，通过这两种方式来进行洞察用户需求。

　　①与用户进行深度访谈

　　与用户进行访谈，是需求的来源之一。

　　而由于用户更多地是站在自己的角度上去体验产品，所以难免有些片面。

　　在访谈的方式，有比较详尽的方法，阿境后面会单独开一篇文章来介绍，这边就简单概括下。

　　包括结构性访谈、非结构性访谈

　　非结构性访谈：是访谈者提供一个开放性的主题或问题，由报道人自由阐述；结构性访谈：是访谈者根据研究主题事先设计好的具体问题，系统地访谈研究对象；这两个的区别是：

　　非结构性访谈能够通过开放性的问题，了解用户处理某个事情时的方方面面，但需要访谈者记录下全程并且提炼有效信息；结构性访谈则更多的是根据固定设计好的问题进行，可以理解为问卷调查的线下版，对于访谈问题的设定有一定的要求，否则容易造成无效访谈。通过这两种访谈方式，收集用户的真实情况：

　　用户遇到的问题是什么？用户当前在处理问题的时候是怎么做的？用户想要的是什么？在这个过程中，也有几个注意事项：

　　客观真实很重要，访谈者要剥离开自身的主观想法在舒适轻松的环境下进行访谈（最好是用户熟悉的环境）掌控整个过程，引导用户表达自身的想法②真实融入用户所在的场景

　　通常我们在做访谈的时候，是以“设计者”的思维对“使用者”的采访，得出的结果相对来说有一定的片面性，同时我们作为“设计者”，不一定能够设身处地的作为用户的身份来考虑问题。

　　这也就是产品经理拥有“同理心”的重要性。

　　花费一定时间，成为产品的用户，融入到用户的真实场景当中，借此观察用户的在相应场景的行为及感受体验。

　　在这个过程中，我们可以观察几点元素。

　　分别是：用户、环境、任务、目标、行为。

　　用户：用户是怎么去做这件事的？环境：用户当前所处的环境如何？任务：用户当前的任务是完成什么事？目标：这件事完成的目标是什么？行为：用户用什么方式来完成这件事？通过真实融入用户所在场景，并且观察这几个元素，来实现“边参与边观察”的目的。同时在这个过程中去真实的感受用户的情感变化，再将情感变化具象化为实际的数据或者描述。

　　2）从产品数据表现发掘需求

　　做产品，数据是很重要的一环。

　　往往每个团队会搭建自身产品的数据概览，包括用户行为数据和业务数据。

　　具体数据不过多展开。

　　通过产品的数据，包括渗透率、留存率、页面转化等，长期观测，能够结合着察觉到产品数据的变化，而数据变化的背后是用户行为的改变，从而发现用户的需求迁移。

　　一般看数据，看现状与看变化。

　　看现状主要是了解业务距离产品目标的差距，能够加深PM对业务的认识。

　　看变化主要是养成数据感，通过数据变化，发掘产品问题，从而制定解决方案。

　　在拿到手一个需求的时候，如果是一句话需求“在直播tab想要添加一个悬浮球”，那么作为产品经理，没有充足的信息，很难评估该需求是否成立。

　　那么，作为需求本身，提出的同时，我们需要得知哪些必要信息呢？

　　包括需求的场景、解决的问题、目标等。

　　之所以需要理清需求的细节，一是因为有部分需求是伪需求，那么当提出人在梳理需求细节的过程中，可能就会幡然醒悟该需求也许是个伪需求；二是对于产品经理来说，清楚需求的基础信息，才能够更好地去评估需求。

　　可以看下阿境整理的需求九要素，当这些问题在需求的提出时也能够一起提交，那么便能够比较好地进行需求的评估。

　　1）需求的类型

　　一般分为两类，政策需求、线上bug需求、线上漏洞需求、合同期限需求、普通需求等。

　　政策型需求一般是根据国家颁布的法律法规所衍生出的需求，普通需求则为除了政策型需求以外的需求。

　　之所以需要区分需求的类型，则是因为政策型需求的必要性及严重性，故无需过多的分析，在满足政策的要求下，最小化成本执行即可。

　　2）需求的场景

　　根据百度释意，需求的场景是指在一定的时间、空间（主要是空间）内发生的一定的任务行动或因人物关系所构成的具体生活画面。

　　需求的场景有几个要素：用户（who）、时间（time）、空间（where）、动机（why），行为（what）。

　　即，什么用户在什么时候，哪个地方，因为什么动机做了什么事情。

　　3）需求解决的问题、解决的痛点

　　在需求对应的场景下，用户遇到了什么问题？在这个问题下，是完全无法进行下一个步骤，还是仅仅是操作不顺畅等。

　　在描述问题的时候，需要越详细越好。

　　4）当前针对该需求的解决方案是什么

　　针对于遇到的问题，当前是否有其他方式能够解决？

　　若有，则用户/运营/业务人员等是采用什么方式来进行解决的？解决的具体步骤是什么？需要详细的描述。

　　5）需求的目标

　　需求要达到的目标是什么？

　　一般包括数据性指标（提升多少渗透率/留存等）、优化型目的（eg：用户更好地回到顶部tab）。

　　通常目标尽量可量化，也需要了解当前的情况是如何，才能确定需求能达到什么样的目标。

　　6）需求价值判断

　　需求的价值判断包括需求的频次、覆盖用户、刚需程度，这几个维度主要都作为评估需求优先级的判定标准。

　　①需求频次

　　该需求的使用频率是多久？

　　一个月一次？每天一次？每天多次？不同的触发频率，在评估需求的优先级及选择解决方案的时候会有较大的不同。

　　②涵盖用户

　　需求的目标用户群体？

　　需求涵盖的用户是哪部分用户？该部分用户占据产品的占比是多少？

　　一般了解需求的用户，主要是清楚需求的涵盖范围，作为需求优先级评估的评定标准之一。

　　③刚需程度

　　用户对于需求的需要程度？（如果不做这个需求会怎么样？）

　　当前需求如果有其他的解决方案，用户是否能够使用？使用的情况如何？

　　7）需求的优先级如何

　　这边的优先级主要指需求提出方基于自身所了解的信息，对于需求的评估。

　　另外，可以指出对于需求优先级的评估依据，能够更好地帮助产品经理准确判断需求的真实优先级。

　　8）需求的预期解决方案是什么

　　对于需求的提出人（用户/运营/业务方等），针对于上述需求的基本情况，可以简单阐述需求的解决方案。

　　该方案虽然不一定是最终解决需求的方案，但能够清楚用户对当前问题的预期想法，作为我们做方案的参考依据。

　　9）其他基本要素

　　包括提出人、提交日期、期望完成日期。

　　主要是能够对需求进行溯源及整理。

　　需求分析，实际上的问题是“如何判断一个需求是否要做？”

　　在了解了需求的收集、基本要素以及挖掘需求的方式之后，下一步便是进行需求的分析。

　　但在需求分析之前，除了收集了需求本身的信息，还需要有其他的信息辅助我们做决策，后续才能够对需求进行合理的判断。

　　1）基础信息整理收集

　　当前业务的数据（包括用户行为数据、业务数据）当前业务的运营情况当前产品对于该业务的规划情况竞品分析，了解竞品的情况用户调研访谈情况（调研问卷、访谈等）再了解了业务方提供的信息之后，我们往往无法判断需求是否要做，此时结合上述的五部分内容，补充对于需求的了解，由外而内。

　　“外”指的是竞品对于该需求的处理情况，行业内的解决方案如何。

　　“内”指的是当前业务的数据、运营情况、自身产品规划、用户调研等。

　　两者相结合，能够对需求所处的环境有个全面的了解。

　　2）需求分析八步法

　　阿境总结了“需求分析八步法”，可以说是本篇文章的精品之精品了，不得不看！

　　分别是“析要素、挖场景、推价值、看用户、拆竞品、盯市场、查现状、定规划”，且听吴彦祖给你们一一讲解。

　　从这八步法分析过后，便能清楚需求是否要做，如何正确地剖析一个需求。

　　①“析要素”

　　分析需求基础要素。

　　上述提到需求要素包括需求的类型、场景、解决问题、目标、需求价值、优先级、预期解决方案等，之所以是“析”，是因为从需求提出方接到需求之后，往往是不完善的，我们需要去剖析直到了解完整且正确的需求内容。

　　一丝错误的信息，比如目标不清楚，场景不正确等的偏差，都会影响我们对需求的评判。

　　②“挖场景”

　　挖掘需求对应的场景。

　　这其实是需求基础要素当中的其中一个，但之所以单独拎出来谈，是因为脱离了场景谈需求，是不合适的。

　　用户+场景=需求，场景占据了很大的一个部分。

　　充分挖掘需求所对应发生的场景，从而了解用户真实的问题，才能够得到合适的解决方案。

　　③“推价值”

　　推敲需求价值。

　　这个需求价值可以以用户、产品、企业三个维度的角度来分析。

　　对于用户来说，给用户提升了什么价值？也就是用户价值。对于产品来说，提升了产品的什么功能指标？也就是功能价值。对于企业来说，提升了企业哪部分的收益？也就是商业价值。这三部分综合起来便是在分析过程中所应该明白的需求价值。

　　④“看用户”

　　看待用户对于该需求的看法，了解以及使用情况，这一步是摸<检查>的预期及日常使用情况，从用户视角看需求。

　　一般是采用用户问卷调研，用户访谈的方式，通过直接去接触用户，得到最真实的用户感受，当然，在这当中，合理的设计问卷、合理的设计访谈问题、控制访谈的整体节奏，也是重中之重，是能否得到正确且真实的用户感受的前提之一。

　　⑤“拆竞品”

　　拆解分析竞品（包括直接竞品、间接竞品）的现状，在明白竞品的用户、商业模式等基础信息的前提下，从竞品的角度去分析对应需求的作用。

　　借此达到管中窥豹的目的，结合自身产品，明白相似的需求我们能够从中借鉴到什么内容，给予我们什么样的灵感和帮助，同时也了解竞品的不足，在产品设计中能够适当规避。

　　⑥“盯市场”

　　紧盯市场动向，对于该需求，摸清市场上的看法以及各大产品各自的发展迭代逻辑，通过市场的反馈及发展，剖析该需求所对应的业务的长久规划。

　　⑦“查现状”

　　摸查产品目前现状。也就是产品经理对于当前产品业务的了解程度越高，那么在分析的时候，结合自身产品业务的现状来分析，便能够极大地减少判断错误的概率。

　　这包括产品当前所处的生命周期、业务的数据情况、业务的运营情况，共三大部分能够概括现状。

　　⑧“定规划”

　　确定需求所对应业务的短期、中期、长期规划。

　　根据规划，了解当前需求解决的问题，处在规划的哪一部分。从整体回归局部，以先总后分的分析思路，理清需求的位置。

　　3）需求其余条件评估

　　需求是否符合当前产品发展的方向规划？需求对于平台其他业务有什么联动影响吗？如果做了这个需求，成本层面与收益层面是否成正比？

　　1）为什么要进行需求的收集及记录

　　我们在做版本迭代的时候，往往有一定的需求需要消化，而需求的来源就较重要了。

　　平时缺少了需求的积累，那么在版本迭代的时候，便会手忙脚乱。

　　主要的原因有三：

　　需求来源众多需求并不是当下就需要进行消化需求多级传递导致需求歧义“少壮不努力，老大徒伤悲”，通过平时的需求积累，标注需求的优先级等，能够有效地扩大产品的需求池，从而在适当的时机，通过消化需求，解决用户的真实问题。

　　2）需求收集的本质及原则

　　需求收集的本质，在于“收整”及“归纳”。

　　原则是以用户为中心，以市场为导向，以行业动态为基准，客观地进行需求的收集，同时需要具有远瞻性，当下不符合产品发展的需求，不代表以后不符合。

　　但一定程度上，用户不一定是需求的来源，目标才是。

　　3）需求收集方式

　　需求的收集方式，通常来源于七个：产品规划、内部人员、业务部门反馈、用户反馈、产品数据表现、竞品分析、行业动态。

　　①来自产品规划

　　作为产品经理，对产品需要有明确性的规划，清晰自己产品定位所在，产品的规划也是极其重要的。

　　在产品/业务的不同阶段，产品经理依靠自己的规划，制定不同阶段的目标，从而延伸出相对应的需求。

　　②来自产品内部人员

　　产品内部人员包括产品经理、研发、交互、设计、老板等，主要代指产研线上的角色。

　　一个产品通常有多个产品经理，在日常迭代当中，产品经理有自己对于业务模块的思考，同时经过一系列的调研、数据等，能够发现自身产品的问题，提出需求。

　　研发、设计、测试等偏研发/设计侧的人员，则是站在自身对于产品的理解所提出的需求，更多的是单独模块，单独功能的优化。如调整主题色、调整客户端接口、优化页面交互方式等。

　　老板这个角色一般是提出战略性、大方向的议题，不一定是具体的需求。如确定产品的发展方向，从而产品经理经过论证确保可行后，根据方向进行分析拆解成具体的需求。

　　③来自业务部门反馈

　　业务部门通常包括运营、售前、售后、商务、市场、客服等。

　　不论是客服还是运营，这些岗位都是离用户最近的岗位，通常我们所说“倾听用户的声音”，而在客户与用户的沟通过程中，运营在工作的过程中，都能够结合用户的需求，以及产品可优化的部分去提出需求。

　　④来自用户反馈

　　用户反馈包括应用意见反馈、用户访谈、社区论坛、主动联系反馈等。

　　倾听用户的声音对于产品，是很重要的。

　　由此产品经理对内需要建立完善的用户反馈机制，对外需要搭建用户调研/访谈流程。

　　其中用户调研包括两种，定性调研和定量调研。

　　定性调研，主要调研文化背景与生活环境、用户的经验和习惯、探索用户行为背后的原因。最具代表性的是用户访谈。定量调研，主要调研各个变量之间的关系，是通过各种数据呈现的客观事实。最具代表性的是问卷调查。在倾听用户声音、用户访谈的过程中，需要注意的是进行信息的解析，也就是根据用户传递的内容，过滤掉失真的那部分，从而得出有效的结果，进而才能够转化成产品需求。

　　麻省理工大学的心理学家罗伯特·费得蒙研究表明，60%的人在10分钟的交谈中会撒谎2到3次，男人和女人撒谎的频率差不多。

　　“人们是无法告诉你他们真正想要的是什么，但是可以通过引导让他们说出来。”

　　准确洞察用户需求的基础是让用户对你说正确的话，有兴趣可以跟阿境单独聊聊，这边不再展开。

　　⑤来自产品数据表现

　　“用户会骗人，数据不会骗人”。

　　可口可乐公司在20世纪80年代，做了一个实验：一款新口味的产品，一款原口味的产品，让实验者挑选，在填写问卷的时候，85%的人选择了新口味的产品。

　　而真正投入市场后，这85%的人，有90%的人又反水选择了原口味的产品。

　　从这个试验中可以看出，用户是会骗人的。但是他们的行为数据不会骗人，最大化的还原了用户的心态、选择。

　　作为产品经理，我们需要根据产品/业务本身的数据表现，发掘问题。从用户层面上来说，在产品当中进行数据埋点，通过用户在产品当中的行为，最大化地了解用户所遇到的问题。

　　通过宏观数据，查看用户在产品当中的行为；比如渗透率、留存、页面转化、人均次数等行为数据的变化，可以了解并分析用户在产品当中遇到的问题，从而形成需求并解决。

　　同时，用户的行为表现在数据上，通过这些，能够清楚用户的行为方式，用户的关注内容，当看得多了之后，会抽象出这个群体用户的行为特征，从而帮助产品经理更深入了解不同的用户群体。

　　ps：下图为脱敏后的一些产品数据图，如渗透、留存、人均次数、打开路径占比。

　　要注意的是，产品的数据表现，并不能够单独来评判一个需求的启动与否，容易有失偏颇，往往需要结合用户调研、用户访谈、产品内部分析等方式加以评估。

　　⑥来自竞品分析

　　《孙子兵法》中提到“知己知彼，百战不殆”。这其中，“知彼”便是了解竞争对手。

　　竞品做的不一定是对的，但是一定是“行出有因”。

　　作为产品经理，需要尽量多地汲取外部相关信息、行业信息，以辅助各种判断和决策。为了跟踪竞品动向，以他山之石鉴己之发展，同时也能够与竞争对手进行抗衡，通过竞争分析来提升产品的竞争力。

　　从产品的战略层面来看，竞品分析能够为产品提供战略、布局规划的参考，同时，在产品设计上取长补短，也能够预警避险。

　　通过竞品分析，了解到竞品的动向后，也可形成具体的产品需求，从而为产品的后续发展做好提前准备。

　　一般对于竞品分析，有两个方面可以收集：

　　平时进行竞品的更新检测，了解竞品动向，收集产品需求。针对于个别业务/功能，对竞品进行针对性分析，输出竞品报告，抽象出需求点。⑦来自行业动态、政策方向

　　根据行业的政策动向，也会延伸出相应的政策性需求，如《计算机信息网络国际联网安全保护管理办法》等的颁布，相应的产品就需要履行相关的法律法规。

　　通常政策性需求的优先级及紧急程度都是最高的，否则产品就会面临下架风险。

　　4）需求收集的几个要点

　　以用户为中心，而非以产品为中心收集需求时，规范记录，保证信息不失真，且可回溯。需求收集需要主动深入挖掘用户的真实需求，而非反馈的表面问题。

　　通常我们把需求的记录称为“需求池”，是产品经理将所有和产品相关的需求信息按一定的规则进行汇总记录的地方。

　　简单点说，就是一个存放需求的地方。

　　而需求的信息、类目繁杂，需要有一定的记录方式，才能够使得庞大的需求池多而不乱。

　　下面会讲讲需求的记录方式，以及需求记录的相应工具。

　　1）记录方式

　　①所属板块

　　一个公司可能有多个产品，一个产品可能有多个端，故当混杂在一起时，需要以板块的字段来区分。

　　范例：wap端、安卓端、ios端、小程序端、客户端、服务端等，根据自己公司业务的情况来划分。

　　②所属业务

　　标记需求对应的业务模块，主要便于后期能够根据业务来区分需求的归属。

　　范例：直播、视频、订单、商品、游戏下载等。

　　③需求来源

　　需求的来源标识一般有：来自用户、竞品调研、产品规划、运营/业务需求、政策要求，共五大类。

　　具体根据各公司业务的不同标识来源字段略有不同。

　　④需求状态

　　状态一般分为：待补充信息、待讨论、需求调研中、需求设计中、开发中、已完成、废弃、暂缓。

　　具体细节从描述中可窥探，这边不过多赘述，主要是描述需求从提出之后到完成/废弃的状态过程的记录。

　　⑤需求时间

　　包括开始时间、结束时间。

　　更重要的是结束时间，有个明确的截止时间；一个需求往往有多端参与，包括产品、交互、测试等等，所以在记录这个需求时间的时候，也可以一并考虑不同端人员完成各自任务的时间（涉及到项目管理部分）。

　　⑥需求背景

　　需求背景描述的是需求当前产生的缘由，在什么条件、什么时间、什么场景、什么资源的情况下所产生的需求，重点描述问题所在。

　　可以从大环境趋势、行业动向、公司情况、产品/业务现状四个方面上来阐述背景。

　　⑦预期方案

　　预期方案主要是根据当前需求的信息（包括需求背景、业务运营情况、数据情况等），所得出的预期方案，但仅仅是当下的思考并记录，不一定合适；

　　具体的方案还需与设计者（产品/交互/需求提出方）共同协商讨论。

　　⑧需求价值

　　需求价值侧面反映需求的重要程度，有的会以“重要”“非常重要”来描述，但太过笼统，并且不能定性分析，故需要再拆分为用户价值及产品价值，来描述需求的重要程度。

　　用户价值重点阐述问题被解决的程度，站在用户的角度上思考这个需求是否能真正解决用户当下的问题，解决的程度如何。

　　从俞军老师的理论上来看，用户价值=（新体验-旧体验）-替换成本。

　　产品价值包括三方面，功能价值、情绪价值、商业价值，阿境简单说下。

　　功能价值指通过功能给用户提供服务，解决用户的核心问题；从技术壁垒人无我有、创新点人有我优、细节给用户带来惊喜、行业风口上的产品功能规划的方式去考虑功能价值。

　　情绪价值是产品除了基础功能外，满足用户的心理需求，如成就感、虚荣感等；放大积极情绪、减弱消极情绪是核心点。

　　商业价值代指产品的吸金能力。且先有的用户价值，再有的商业价值。

　　总的来看，产品价值以“提升功能价值、增强情绪价值、构建商业价值”三方面来入手分析需求价值。

　　⑨紧急程度

　　紧急程度一般分为：不紧急、紧急、非常紧急。

　　一般根据实际情况调整。

　　⑩需求难度

　　需求难度一般分为：高、中、低。

　　偏主观性的一个字段，主要通过前期对需求的了解评估，将其与开发简单评估下，做出的评判。

　　⑪相关人员

　　若需求涉及多部门人员，则需要填写需求涉及到的相关人员，便于后期追溯。

　　⑫备注

　　备注当中一般描述字段以外的自由内容。

　　可以添加相应与需求有关的材料，比如竞品调研、用户调研、当前业务数据等等，目的是为了更好的给这个需求做决策。

　　2）记录工具

　　可以采用excel进行记录、也可以采用teambition等协同工具进行记录，切记，工具只是协助我们进行更好的进行需求梳理。

　　3）需求记录原则

　　需求记录原则遵循四个“可”。

　　需求来源可追溯、需求场景可还原、需求分析可实现、需求推进可持续。

　　只有在记录的时候达到这四个，才能够保证需求的传递不失真，真实还原需求是需求分析的首要前提。

　　4）需求池的搭建方法

　　需求池可以说是需求管理的一剂良方，像是产品经理的“需求记账簿”，但是要搭建一个健康、不冗余且有效的需求池，还是不那么容易的。

　　一个健康的需求池要达到的几个要素是：容易查找、清楚需求进度、了解需求状态。

　　以结构化的思维，根据产品实际情况，划分整体需求业务分类。

　　规范各业务方提交需求的需求格式（极其重要！！！），保持需求原始信息的真实记录。

　　进行需求规整，对需求原始信息进行补充，分析及加工。

　　标记需求状态，进行需求信息的持续完善

　　及时维护需求池。设定周期时间，在每个周期时间内都整理一下需求池中的需求，及时进行需求状态的变更调整，抛弃无效需求，完善有效需求。

　　当需求池中积攒了许多需求的时候，一团糟，这个时候就需要根据一定的方法进行需求的挑选、标记及分类。

　　1）需求标注及筛选

　　①标注

　　当业务方/运营提需求上来之后，需要进行需求内容的标注，往往会出现需求内容不全面、需求格式不对等问题，这个时候就需要产品经理对应的去与需求提出方进行深度沟通，挖掘需求当前的有效信息。

　　ps：在提交需求时，产品经理可以提供一份《需求提交规范》给到需求提出方，根据这份指南来走，往往提交上来的需求会相对有效。

　　②筛选

　　这一步骤主要是“去伪存真”，根据全面且详尽的信息，评估出该需求的真实与否，是否是“伪需求”，若是，则需求需要进一步考虑是否废弃。

　　且在需求筛选这一步中需要进行优先级的评估，高优先级的筛选出来，在近期的版本中进行迭代优化。

　　2）需求分类

　　需求的分类往往是根据业务类型、业务端来区分：

　　业务端主要是：小程序端、app端、服务端等业务类型主要是：直播、视频、游戏等，具体看每个产品的业务而定有的产品较大，一个产品往往多个产品经理负责，那么就需要根据不同的业务分配不同的产品经理进行负责。

　　为什么要排需求的优先级呢？

　　因为“这个很重要”“这个很紧急”“这个优先级最高”往往是业务方的口头禅，那么当那么多所谓的“优先级很高”的需求摆在我们面前，“双拳难敌四手”，总需要有个先后处理的顺序。

　　要记住，需求优先级的本质是“性价比”。

　　在前面提到的，我们会给需求标注“重要程度”、“紧急程度”两个维度，这两个维度怎么区分呢？

　　重要：以核心业务、核心用户、商业价值、竞争优势等方面去评估。紧急：以严重程度、时间对比、需求频率等封面去评估。清楚了“重要”“紧急”这两个维度后，那么按照时间管理四象限的思维。我们就可以分为四个方向：

　　重要且紧急：短期内一定要做的需求。通常是产品重大bug，政策需求，重点是“快且好”。重要不紧急：重要但可以长期做的需求。比如某功能模块的规划等，重点是“有计划”。不重要但紧急：对产品、用户的作用可能不大，但短时间内一定要完成的需求。不重要不紧急：时间维度不敏感，且评估后重要性也低的需求。当然，从四象限模型并不能够完全地解决现实中评估需求优先级的情况，需求优先级的评估需要结合更多的维度。

　　阿境这边总结几个常见的维度，大家可以综合自身业务情况来考虑。

　　1）需求的类型

　　主要包括政策需求、线上bug需求、线上漏洞需求、合同期限等，明确需求的类型主要是为了明确需求的紧急程度，不同类型需求的紧急程度不尽相同。上述提到的需求类型，紧急程度一般是最高的。

　　2）产品发展方向

　　一个产品通常在发展的时候，通常会经历四个阶段：导入期、成长期、成熟期、衰退期；根据产品的不同阶段，产品经理会相对做不同的产品规划，也就是确定产品的发展方向。

　　不同的发展方向，对需求的优先级也有影响。

　　比如一款产品，核心业务包括社区跟直播，但产品近半年的发展方向是社区的内容，那么同时社区与直播的需求，在其他条件相同的情况下，社区需求的优先级是会更高一些的。

　　3）业务价值

　　不同的需求通常涉及不同的业务，业务价值也是需求优先级的一个重点考量因素。

　　业务价值是产品价值的拆分，与之类似。通常包括两部分：商业价值、功能价值。

　　商业价值指的是该业务为产品带来的盈利空间；

　　功能价值则体现在产品的数据指标，如渗透率、留存率，流程转化等，通常是从侧面提升产品整体水平。

　　不同业务的价值是不同的，其他条件同等情况下，业务价值大的需求＞业务价值小的需求。

　　4）影响范围

　　需求的影响范围包括该需求涉及业务模块的目标用户量，需求被用户使用的频率，这两个指标包括了需求的影响范围。

　　更细一步进行拆分，则可进行分析目标用户的用户价值。

　　举个例子：A需求涉及用户1w，B需求涉及用户5w，但1w用户的用户价值远大于5w的用户价值，那么虽然目标用户量A＞B，但其他条件同等的情况下，A需求还是优先于B需求。

　　5）需求成本

　　需求的成本也是需求复杂度及难度的体现，需求复杂度与需求成本成正比。

　　需求的成本包括产品成本、研发成本、交互成本、设计成本、测试成本等。

　　可以理解为一个需求从诞生开始到落地所能够涉及到的所有流程（其中也包括沟通成本等这类无形的成本）。

　　往往我们在估算成本的时候只估算了研发成本，但那只是需求的实现，在实现之前还包括需求的调研、分析及讨论，以及可能涉及跨部门的沟通，这些都是成本之一。

　　评估需求成本需要全面、完善。

　　综上的五个维度，一般是评估需求“重要”、“紧急”的一些评估因素，结合每个因素，往往我们是去进行定性分析；

　　但当多方意见有偏颇时，就需要定量分析，大致的思路便是将每个维度进行打分，然后乘以不同维度的权重，再将其相加，从而得出该需求的最终得分。具体的实际操作方式若有疑问也可跟阿境探讨。

　　另外，需求的优先级不仅仅有上述的方式（ICE分析法），还有KANO模型等。

　　KANO模型由于其方式在真实工作中实用性较低，这边阿境仅简单介绍：

　　基本（必备）型质量——Must-be Quality/ Basic Quality期望（意愿）型质量——One-dimensional Quality/ Performance Quality兴奋（魅力）型质量—Attractive Quality/ Excitement Quality无差异型质量——Indifferent Quality/Neutral Quality反向（逆向）型质量——Reverse Quality可以通过问卷的形式，获得较为准确的KANO分类，再通过Better-Worse系数确定需求所属的象限，进而判断优先级。

　　ps:

　　优先级是相对的，没有绝对的高优先级需求。优先级不是一成不变的，随着时间、产品形态、市场形式的变化，优先级也会随之改变。

　　1）为什么存在需求变更

　　众所周知，开发小哥往往是听到“需求变更”脸色都变了。

　　需求变更有外界的因素（eg：对接不当），也有自身的因素（eg：优化策略）；针对于这两者，都可能存在需求变更。

　　需求变更并不是越多越不好，而是一种风险规避的方式，在项目的进展阶段，越早进行变更，则能够将未来发生的风险降到最低，也能够使需求真正达到原本的目的，解决实际的问题。

　　但需求变更存在项目资源的浪费，所以原则上，能少则少，若有必要，及早变更。

　　产生需求变更的因素有很多，其中包括一下几点：

　　信息传递有偏差，一般发生在与业务方对接需求的时候，导致需求方向错误，且没有经过逐次确认。产品经理前期对业务思考不足，导致设计出的需求无法解决现有问题。撰写需求文档时，逻辑性、完整性、合理性等颇有不足，导致文档不符合开发标准。评审会上对需求的细节没有讨论到位，排期评估上对需求的评估也有偏差，导致需求在开发当中需要及时调整。在开发或测试的过程中，当需求涉及到真实数据的时候，发现产品原本的设计方案与预期设想的不同，于是需要进行变更。业务形态发生变化，当在需求的开发过程中，公司的商业模式或运营模式发生改变，则产品也需要进行及时调整方向。上述六点需求变更的原因中，除了第五、六点，其他方面基本都是可以通过一定方法来减少需求变更的频次的，第五点的变更原因，则是为了更好地达到原本的需求效果。

　　2）如何减少需求变更

　　涉及业务方的需求，在前期对接，且需求产出之后，与业务方确认需求方案是否满足业务。加强对自身业务的了解，多查看行业内的报告，了解自身产品实际数据、运营情况，业务发展方向，从而能够更好地对业务需求进行决策。做需求之前进行充足的需求调研、需求风险评估，需求成本评估等。评审会前、评审会中、评审会后三个阶段，产品经理都需要及时的进行需求疑问点的沟通及确认，避免因需求完整性、逻辑性、合理性而产生的问题。对于需求内容，往往需求撰写者深陷其中，无法直观发现问题，可以内部进行评审/讨论，从而在需求评审前解决掉需求文档本身存在的问题。产品设计中，多留意往常需求变更的原因（例如后台的设计等），灵活总结变更前后特点，做产品需求的设计时多注重灵活性。3）需求变更需要做的事情？

　　一个需求变更，往往不是一瞬间的事，而是一个过程。

　　在产品经理察觉到需求需要变更时，则需要做几个步骤：

　　预先周知项目组该部分内容可能产生变更，若正在开发，则需要及时中止需求，避免投入更多的资源。保证需求合理性的情况下，尽量在最短时间内处理变更方案周知项目组相关人员变更背景，变更内容，变更影响点；同时项目组重新评估需求做到这三步，才算是需求的变更结束。（往往大家容易遗漏掉第一步，导致部分的项目资源浪费，因为在意识到需求需要变更的时候，距离变更后的方案还需要一段思考及修改方案的时间。）

　　需求的评审与开发涉及到项目的流程，这其中涉及项目管理中的项目监控的环节。

　　包括需求开发过程中的周会，用于监控需求当前的状态；产品需求的验收，用于验证需求是否能达到预期等。

　　本文主要聊需求的挖掘与分析，开发过程便不再过多赘述。

　　这边的需求自检并不是指需求文档本身的清单。

　　需求自检清单指的是从需求的萌生后，产品经理所需要考虑的点是否完善且详尽。其诞生的本质是上述文章内容所涵盖的核心点。

　　是否了解了需求的目的、背景、来源等基础信息？是否有对需求进行需求价值的分析？需求的核心用户、发生场景是否了解？针对该需求，所涉及业务模块的数据是否了解？针对该需求，当中涉及到的运营场景及日常运营操作是否清楚？是否有与需求提出方进行完整、详细的了解？对于该需求，其中背后存在的问题，其他竞品是怎么做来解决的？需求完善清楚后，是否有进行需求内容的完整记录？（记录需求池）需求的关键指标（目标）是否清楚？（可采用GSM模型来梳理）需求的业务流程是否清楚？当前情况的流程与需求完善后的流程对比，两者的区别是什么？需求对于平台其他业务有什么联动影响吗？这些逻辑及流程是否了解？现有功能是否能够解决需求所对应的问题？如果能，则还有多少可优化的空间？需求是否符合当前产品发展的方向规划？若符合，处在哪一阶段？如果做了这个需求，成本层面与收益层面是否成正比？

　　需求不会改变，但需求的解决方案会随着时间的改变而变化需求需要根据用户的不同、场景的不同、时间的不同来考虑只有较低层次的需求得到满足后，用户才有动力去追求更高层次的需求需求可做大可做小，就看本质是想要达到一个什么样子的目的（不为了做需求而做）需求考虑性价比（如果做3个需求能够满足80%的要求，做20个满足100%的要求，那么选择前者）

　　这是阿境近来输出的一篇较为系统性的文章，从需求的概念、本质入手，逐步讲到需求的收集、评估以及分析，从概念理解到落地实践，由浅入深，希望能够对需求分析有疑问的朋友有一个系统的认识。

　　也相信认真吸收了文章内容之后，一些关于需求的面试题基本都能够解决了。

　　想说的是，需求分析只是一个思路，但并不是一个固定的框架，用户的需求会变，同样的，需求的分析方式也会随之改变。

　　“要了解怎么分析，并付诸行动，但不能仅仅局限于条条框框按部就班地分析。”

　　需求分析需要结合自身对市场的洞察、用户的研究、产品的思辨，但同时也需要考虑其他多种维度，比如人性。需要“理性+感性”相结合着来。

　　毕竟做产品，是为了有趣。

　　专栏作家

　　阿境，微信公众号：梦想家阿境，人人都是产品经理专栏作家。遇到过三位数的DAU，也有八位数DAU的经历；擅长产品面试的指导，用户需求的洞察，对社交领域有深入的见解。

　　本文原创发布于人人都是产品经理，未经作者许可，禁止转载。

　　题图来自Unsplash，基于CC0协议。

　　该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。