在上一篇文章，我们仔细聊过了需求的重要性以及需求的常见挖掘方式。经历了一次次高强度的需求挖掘运动，绝大部分PM都已经得到了很多的备选需求，像是好不容易去果园摘了一箩筐的橘子回来。
接下来，我们就要把一些还没有成熟的橘子给挑拣出去，对我们收集进来的需求进行分析和筛选。那么，在拿到用户的需求之后，我们应该如何对需求进行一个科学的评估和筛选呢？
今天，我们就来聊一聊需求管理。
3.1 构建需求池
在产品经理职业生涯里，工作永远都是围绕着“需求”来展开的。
需求收集 -> 需求分析和筛选 -> 需求实现
上面的步骤重复循环贯穿在产品的整个生命周期。
所以，如何管理需求，就成为所有产品经理必备的一项技能了。
在这里要给大家介绍一下需求池这个东西。
3.1.1 什么是需求池
需求池，很好理解嘛，一个集中存放需求的池子。
需求池是一个跟产品有关的、未来可能会做的功能点的聚集地，需求挖掘阶段将收集到的用户需求都放到池子里，然后在做项目规划的时候，我们会从池子里根据“轻重缓急”和“优先级”筛选出一部分，做为我们产品计划的参考。
需求池内的需求不一定在本次的开发版本范围内，有些可能只是一个想法，有些还需要调研，有些还需要讨论，总之，需求池中的需求和实际交付给开发的需求还是有一定距离。
“好记性不如烂笔头”，一句话而概需求池的由来。你还记得上个月第二周的产品讨论会上xxx提出的想法吗？
赶紧打开需求池看看吧。别让你的好想法就这样溜走，快点记下来吧。
3.1.2 需求池如何构建
需求池的呈现形式有很多种，行业不同、需求不同、产品经理的习惯不同，需求池的构建不一而论。
常见的，可以用Xmind来做，也可以用Excel来做。
对待需求我们需要有一个严谨的态度。不是随便一个想法都能进入需求池的，这个idea满足了我们用户的什么需求？如果需求提交人都回答不知道，那也就没有必要进入需求池了吧。
需求标题、需求描述、产品线、提交人、提交时间、功能模块、优先级、需求状态等，这些需求池的细分项，便于需求的追述、调研、细化，最终快速形成可以交付给开发的需求，让需求更立体化，更清晰，过滤那些想都没有想清楚的需求。
3.2 需求优先级
3.2.1 为什么要做需求优先级排序
产品经理作为最直接接触用户的岗位，工作中能直观的看到用户的很多需求点，但是，这其中有一部分是用户真正的“痛点”，有一部分只是一些需求假象。
作为产品经理，要能够很理性的梳理出来这些需求之间的逻辑关系，同时，要保持清醒的头脑，理性对待需求的优先级排序和需求的删减。
产品的需求可以说是无上限的，大量的堆积需求，会使得产品非常臃肿，而且毫无特色，而需求的过多，还会导致工期过长，拖慢了产品推出市场的进度，对产品百害而无一利。因此，产品经理需要了解需求的优先级排序和需求的加减法。
3.2.2 需求优先级排序怎么做
优先级是个很难划定的东西，经常被人提到的“四象限法”：对需求进行归类，重大问题修复、重要体验优化、重要的新功能…这种比较主观的归类，每个版本都需要进行一次主观的优先级判断，相对来说太消耗时间了。
有些需求或优化可以直接影响正常的使用和核心功能，这样的需求优先级高，大家很容易达成共识。
对于一些新功能和产品规划的方向性问题上，优先级的确定很可能会演变成一声拉距战，最后就是谁的级别高听谁的。
需求的优先级，最好能够量化，减少主观判断，形成一个可视化的数学计算方法，而且让大家达成共识。
试试从这几个纬度去考虑优先级：
- 运营的阶段性目标是什么？
- 需求服务的用户数量是多少？
- 投入产出比是否合适？
通过这几个纬度的考虑，很容易就能过滤掉一大半的需求，抓住重点，让大家共识重点。
看似简单的东西，可是当时为了优先级争得面红耳赤的时候，谁还会记得它呢？
基于这几个纬度，可以进一步对需求进行纬度细分和权重细分，讨论出一个优先级计算公式。
以后优先级的讨论只要套用这个公式就行，一劳永逸。
3.3 输出功能需求列表
3.3.1 为什么要输出功能需求
为什么要输出功能需求？你说为什么要输出功能需求列表....
前期的需求挖掘、需求整理、需求优先级排序等等围绕需求的工作已经做了一大堆了，是时候该向解决需求迈出第一步了。
功能需求列表，就是把需求分析、筛选和评定优先级之后的结果，以产品功能的形式展现出来，再用列表的方式将其呈现。
功能需求列表的价值，一是在于帮助产品经理自己理清思路，二是在于帮助项目团队的其它成员了解产品的功能需求，各岗位提前做好相关准备。
3.3.2 需要输出哪些内容
我们来看一下功能需求列表大致包含哪些内容：
- 模块：一般来说，每个模块下分3~6个子模块是合理的，否则要考虑重新划分。
- 子模块：也就是一级模块的二级分类，这里就已经涉及到产品架构的梳理了（但我们这里只是大致地梳理一下，后期在产品设计的下一个环节“搭框架”会进一步调整）。
- 功能：要给用户提供什么功能，给这个功能起个名字。
- 功能描述：这个功能具体包含哪些操作，可以描述的具体一些，如，支持用户填写基本信息可自由创建课程，进入课程空间就可对课程进行编辑和管理，还可发布、删除课程等。
- 用户价值描述：也就是可以给用户提供什么价值。
- 需求优先级：这块是整个需求分析工作中核心的部分，判断的准确直接影响着将来产品的方向，在这里我们只需要将我们之前评定的需求优先级照抄过来就好。
- 开发量：一般由研发部门的项目经理或者开发来确定。
- 投入产出比：简单来说，就是商业价值除以开发工作量（或开发难度），当然每个团队可以找出一个合适自己产品需求ROI的计算方法。
- 备注：觉得需要强调的，比较特殊的东西。
现在有越来越多的产品经理会选择直接通过脑图软件来进行功能需求的梳理，然后通过脑图软件自带的标注、附件、笔记、优先级排序等功能进行说明，比如下图这样的：
呈现形式并不是那么重要，重要的是项目团队成员能够通过你的文档更加清楚地了解产品的功能需求，便于产品经理和团队成员进行沟通。
