在实际的产品迭代中，需求并不是一个一个的产生、梳理、设计、实现的，往往是一堆一堆地出现。并且，资源总是有限的。如果没有对需求进行有效的管理，产品工作就会是一团乱麻。这跟消费类似，想买的东西总是很多，而收入总是跟不上，如果不想出现经济危机，就需要对消费欲望进行管理。清楚消费欲望满足哪些需要，哪些是当前必须的，哪些可以在未来满足。对应到需求管理，需要明确的是需求的价值和优先级，确定哪些现在就要加入当前的迭代计划，哪些放到未来慢慢优化。之后，针对优先级高的需求，投入更多的资源，给出洽淡的设计，并跟进落地。这就是需求管理的基本思路：收集需求、梳理需求、确定优化级、设计产品、实现产品。

下面会结合工作中的实践，谈一谈自己的看法。

一、需求收集

产品解决的是一类人的特定场景下的需求，而不是某几个特定的需求，这两者的区别在于，前者的范畴更大、更模糊，同时在不断的演进。也就是说，产品要解决的需求不是某几个特定的需求，而是产品的目标用户群，在特定的场景下的需求，这些需求会随着用户的认知的加深，以及环境的变化不断的变化，是一个动态的过程。产品经理做为产品的设计者，需要捕捉这些变化，甚至是走在用户的前面，也就是说比用户更知道他们需要什么，而不是只是 case by case 的接受用户提交的「需求」，然后把这些需求传达给研发。这也是一再被提出的「产品经理要深挖需求」。

需求收集的关键在于全面、不遗漏。在任何时候，我们收到一个「需求」，这种「需求」往往是来自于某类用户对产品的预期-产品现状，受限于用户的类型和关注点，这种需求比较「片面」。换言之，可能存在有一系列的需求，而某类用户只提出了某个需求，其他同类或者关联的需求没有被提出来。作为产品经理，需要把潜在的需求挖掘出来。

那么，如何挖掘潜在需求呢？通过「一横一纵」来分析。

「一横」

「一横」指的是，分析这个需求是用户在什么情况下会产生？有没有存在类似的场景？

「一纵」

「一纵」指的是，分析在这个需求场景中，存在哪些关联行为可能导致问题，需要系统支持？

针对收集到的需求，我会采取以下的模版记录：

需求收集模版

从上到下来看这张卡片。

1. 给需求一个名称或者编号，方便内部交流；

2. 需求类型可以分为新增和改进；

3. 记录需求是由谁提出来的，方便后续梳理需求和判定需求优先级，可填写用户角色+具体用户姓名；

4. 需求获取的时间也需要记录，一个距今三天和三个月的需求是不一样的，如果是三个月就很有必要和需求来源再进行一次沟通；

5. 把需求描述清楚，可以记录用户描述需求时的原话；

6. 产品经理需要记录需求产生的场景，可以补充业务场景片段，可以是一个流程图，一段场景描述；

7. 对需求进行评论，可以是优先级，可以是疑问，可以是收益；

8. 参考产品，有时用户在表达需求时，会补充说「xxx产品就是这样」，记录下来，后面梳理需求，设计方案时会用到。

维护这样一堆的需求点管理卡片，会有一种需求尽在掌握中的踏实感。推荐用 Trello 来做需求收集。

二、需求梳理

在收集完需求后，产品经理需要进一步细化梳理需求，即搞清楚「需求的三要素」：问题、业务背景、解决方案。

需求三要素

（1）澄清问题

清晰定义问题，分析原始需求背后的真正需求。思考以下问题：

• 要解决谁的，什么问题？

• 目前遇到这样的问题，是如何解决的？

• 问题描述中，有哪些需要澄清的定义？

• 有哪些相关的需求？

（2）了解背景

为了给出更准确的解决方案，还需要进一步了解相关背景，思考：

• 这个需求是未实现对谁产生影响？影响的频率如何？

• 该需求是在什么业务场景中产生的？这些业务场景是怎么样的？

• 有哪些业务术语需要说明？

（3）建议并确定解决方案

针对问题有哪几种解决方案，各有什么优缺点，建议用哪个？为什么？

需求分类

思考完上面的问题，就完成了需求梳理。下面需要对需求进行分类，目标在于更加有序、高效地实现需求。一般而言，需求可以被分为：功能型需求、数据需求以及非功能需求。

• 功能型需求：指有具体完成内容的需求，比如登录行为、搜索商品等等。这些行为根据不用的场景我们还可以细分为使用场景、维护场景以及运营场景。

• 数据需求：数据相关的需求，如报表需求、指标监控等等。

• 非功能需求：除了功能需求和数据需求，其他需求都归于此类，常见的有系统的性能、可靠性、可维护性等等。

在后续评定优先级中，不同分类的需求会分开评定。一方面是因为实现不同类型需求的人员不同，更重要的是，产品在不同的阶段有不同的侧重点。在产品迭代的初期，我们更加重视功能型需求的建设，需要快速做出功能，占领用户；等产品成熟之后，就需要从野蛮生长转变为精细运营了，这时更看重的是非功能需求的完善。

三、需求优先级

接下来，就是对需求进行排优，按照优先级顺序进入研发。排优的基本思路：精益思维，亦即二八法则，将 80% 的精力投入到哪些最有价值的20%的需求上面。关键在于识别出最有价值的需求，这里有很多的模型，比如麦肯锡提出的重要性象限、KANO模型等。这里不展开讲具体的模型，我打算分享下我日常工作中排优先级的思路。

需求排优思路：

1）用痛点思维分析需求的频次、强烈程度，以及是否有替代方案；

2）将需求按重要且紧急、重要但不紧急、不重要但紧急、不重要不紧急分为四类；

3）按照需求分类有序排优先级

a. 用痛点思维分析需求的频次、强烈程度，以及是否有替代方案

需求的频次可以用小时级、天级、周级、月级来表示，强烈程度可以用非常需要、需求、勉强需求、无所谓表示。

b. 将需求按重要且紧急、重要但不紧急、不重要但紧急、不重要不紧急分为四类

可以综合需求的频次、强度看需求的重要程度，是都有替代方案看需求的紧急程度。

重要程度评估

重要程度评估

紧急程度评估

紧急程度评估

按照需求分类有序排优先级

按照需求的重要和紧急程度排定优先级：

优先级最高：紧急且重要的需求

优先级次高：紧急但不重要的需求

优先级一般：不紧急但重要的需求

这里面需要特别强调的一点是，不紧急但重要的需求，大家不要看到它优先级一般，就觉得它不重要。因为优先级最高的  「紧急且重要的需求」往往都是从  「不紧急但重要的需要」演变来的。做需求管理，很重要的一方面就是将人力和时间分配到重要的需求上，留更多的时间和精力规划重要的需求，不要等着事情变紧急了再急急忙忙出个方案应付，需要做到未雨绸缪。如果日常工作中，发现手头尽是紧急且重要的需求，就需要反思一下了。

四、产品设计

当我们明确了需求的优先级后，把优先级高的需求挑选出来，以「场景—问题—方案」的逻辑来分析，从而导出所需的功能。

在这个阶段，我们会进一步分析需求，还原用户所处的业务场景，梳理业务流，遍历每一个典型步骤、潜在变化、异常，思考每一个环节用户会遇到的问题，然后导出方案。最后还要考虑业务场景的环境和规则，反推得出最终的方案。

总结下，从输入输出的角度理解需求管理，输入就是用户描述的「需求/问题」，输出就是产品功能。输入到输出间，涉及多个环节。

需求收集阶段，全面的将需求收集起来；

需求梳理阶段，分析需求的三要素，确定需求的分类；

需求优先级阶段，评定需求的优先级；

产品设计阶段，拿出优先级最高的需求做设计，导出具体的产品。

当然，产品设计并不是需求管理的结点，后面还有产品实现，另外，上线之后还会产生用户反馈，即新的需求，又会进入需求收集阶段，形成闭环。