作为产品经理，随时都会接到各种大大小小的需求，这么多需求我该听谁的？先做哪个？我想跟大家分享一个需求管理的工具—需求池， 开始这个分享之前，让我们首先来了解下需求池是什么?
其实产品经理的需求池像是哆啦A梦的口袋，可以把你接收到的所有需求放进去，以便需要的时候随时找出来用，以免发生转身就忘的乌龙。甚至需求池有时候就是产品经理的挡箭牌，当需求过多没有时间处理时可以通过合理规划对紧张工作进行缓冲，所以管理好需求池是产品经理的入门功课了。
01、需求基本属性
当你接收到一个需求，首先要对需求的信息进行一个简单的梳理。
需求来源
需求来源一般分为外部临时需求，常规需求和运营需求
·外部临时需求：用户反馈需求、老板/甲方爸爸业务需求
· 常规需求：业务实际需求（如通过竞品分析或用户挖掘出的需求），第三方合作需求，项目版本需求，产品自身优化需求
· 运营需求：运营活动需求，运营推广拉新需求等。根据需求提出方判断需求来源的类型，可以写的尽量直接简单
需求描述
用户在什么样的场景需要解决什么样的问题就是需求的描述，是需求评审的重要依据，不需要太详细，说清楚要解决的问题，以及为什么会有这样的问题。
02、需求评估信息
梳理完以上需求的基本信息，就可以对需求进行简单评估了，主要包括以下几方面:
需求类型
需求类型分为：新增功能，优化体验，bug修复，内部需求等。
需求优先级
需求类型分为：新增功能，优化体验，bug修复，内部需求等。
优先级可以按照紧急重要的四象限法则或者kano模型来区分，将紧急重要或用户期望度高列为高优先级，优先级从p1-p8(我参考职级,hiahia)排序。
紧急重要四象限法则是时间管理的工具，按照重要和紧急程度分为四个象限：
· 紧急又重要：包括一些突发性的但必须解决的事件，比如客户投诉，危机事件，例如重大系统漏洞等等
· 重要不紧急：比如关于运营的活动规划，提高用户体验的一些需求
· 紧急不重要：计划之外的工作，如老板要求必须满足的奇思妙想等等
· 不紧急不重要：就是一些对用户来说无关痛痒的需求，或者做了对目前版本没有实质性帮助的需求
对于紧急又重要的事情当然是优先级最高去做的，那么我们关注的是到底应该先做紧急不重要的，还是重要不紧急的呢？管理学泰斗德鲁克说“我们需要记录时间，然后分析时间，最后才是安排时间”，时间是有限的，所以把有限的时间用来做重要的事，“要事优先”原则，做产品也一样，好的产品不在于你做了多少功能，而是把用户真正需要的，对于用户来说重要的事专注做，用心做，做到极致。
kano模型
与四象限法则不同，kano模型是按用户的满意度和功能完善程度划分：
必备型需求：当优化此需求，用户满意度不会提升，当不提供此需求，用户满意度会大幅降低。
期望型需求：当提供此需求，用户满意度会提升，当不提供此需求，用户满意度会降低。
兴奋型需求：用户意想不到的，如果不提供此需求，用户满意度不会降低，但当提供此需求，用户满意度会有很大提升。
无差异型需求：无论提供或不提供此需求，用户满意度都不会有改变，用户根本不在意。
反向型需求：用户根本都没有此需求，提供后用户满意度反而会下降。
前三种需求根据绩效指标分类就是基本因素、绩效因素和激励因素。我们做产品设计时，需要尽量避免无差异属性、反向属性的需求，至少做好必要属性、期望属性，努力做魅力属性的需求。
需求优先级
根据需求描述和场景初步判断该需求所属的产品模块，优化现有模块或增加新模块。
版本节点
该需求是否需要对当前产品的现有功能进行版本迭代，小需求只涉及简单页面交互的可能不需要，如果需要版本变更则记录新版本号。
需求负责人
指定产品团队的某一个人负责的需求，需要负责从记录需求到产品上线的一系列工作和责任。
需求添加时间
记录添加到需求池的时间，也就是确认需求的时间，可以知道需求从确认到上线的生命周期。
03、如何维护需求池
整理完所有信息就可以对需求池进行更新了，对新需求要及时补充和维护才能发挥需求池的作用，那么如何维护需求池呢。
谁来维护需求池
这也就是为什么上边说到一定要指定需求负责人了，通常产品团队每个人负责的模块都不一样，那么每个人接收到的需求也是不一样的，需求的接收者也就是记录者，需要先把接收到的需求来源和描述简单记录下来，由产品团队商议由谁来负责这个需求，那么负责需求的人就要负责该条需求整个流程的更新和维护。
需求池维护和更新流程
需求的更新
需求是变化的，需求的内容会变，有可能甲方爸爸上午说的需求下午就会改变；需求的状态也会随着工作的进行改变。
·待确定：新接收的需求，基本信息已经整理完成
· 需求评审中：正在准备需求评审的需求
· 待开发：需求已经评审完毕，但还没有开发
· 开发中：需求已经进入开发阶段的
· 已上线：开发完成已经上线的需求
任何需求的变化都要及时更新。
在管理需求池时，把同一模块的需求进行归类整理，这样在处理该模块时可以一次性解决，提高工作效率。需求池的信息可以根据实际业务扩充或删减，我的需求池还包括很多跟踪信息是需要研发和测试更新的，方便我及时了解项目进度和重要里程碑情况。
04、需求从需求池中取出的规则
指定需求取出
需求提出方指定要做的，需要在当前版本实施的内容，比如针对某些需要配合目前公司运营活动的需求。
按优先级取出
由产品经理按既定优先级取出，将紧急重要的需求或用户期望值较高的需求取出实施需求评审。
小需求取出
通常是一些修复型，细节性的需求，成本较低的 用来在各个版本的研发空余时间 植入进去，就像搭顺风车，比如一些提升用户体验和性能的小功能。
05、如何排出废弃需求
当一个阶段内需求池的内容到达一定容量时，需要定时对产品需求池进行整理和筛选，重新将需求分门别类，将没有实际应用场景的需求，用户无关痛痒的需求，反人类的需求，明显不符合公司战略方向的需求，定时展开需求评审会议，进一步去明确真实需求，删除没有必要的需求。
以上便是我对需求池管理的一些想法，一个完整的产品是由一个又一个需求组成的，做好需求池管理，对产品之路收益良多。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
