需求池管理有进有出宽进严出

　　不知道大家有没有一个感受，就是虽然产品在不断的更新迭代，但是需求还是会源源不断的增加，感觉怎么也不会减少。这时候就需要用需求池这个工具，来管理这些源源不断的需求了。
　　一、需求池是什么？
　　需求池主要产品汪用来收集和管理各方来源的各类需求，这里不仅仅是简单记录需求是什么，还会记录这个需求相关的一些关键要素。另外初次进入需求池的需求是通过简单筛选和评估的。总的来说，需求池管理有两个原则：有进有出、宽进严出。
　　二、需求池有哪些要素？
　　编号
　　编号就是需求列表的顺序号，主要是作为当前需求的唯一性标识。
　　功能模块
　　根据现有的产品模块进行分类，初步判定此需求属于哪个功能模块的类别，若是新增业务功能，则此项可以待定不填写。
　　需求描述
　　如果是比较简单、不复杂的小需求，直接描述要解决什么问题。如果不是小需求，则不仅需要描述要解决什么问题，还要把为什么要解决问题的原因一并记录下来。（解决问题的原因，多数情况下需要产品汪刨根问底的去问，去了解实际上用户的需求到底是什么和想解决怎样的用户需求）
　　需求来源
　　直白的理解就是此需求从哪里来，是谁提了这个需求。
　　以产品汪作为需求主要提出人来分类的话，可分成如下两类：
　　被动告知需求：
　　主要业务部门，包括市场部、运营部、财务部、管理层等主要业务部门，需求目的是为了上线某一个新业务或者是新活动，这时候产品要做的是了解新业务或者新活动的内容，梳理出业务流程，整理涉及到的逻辑出demo等等；
　　客服，需求目的是解决某一类用户问题，当存在一类用户频繁咨询或投诉这类问题，客服是会把这类用户问题提交给产品组，产品来评估从业务和产品角度怎么进行优化此类问题；
　　QA，针对于视觉或者交互的细节QA在测试过程中，会遇到一些细节的小问题（主要是历史遗留），这时候会提交给产品，一般此类需求等级较低；
　　用户意见反馈，每月收集整理用户提交的意见反馈（吐槽或建议），分析用户吐槽的问题是否具有普遍性还是个例，用户的建议是否能实现，背后想解决什么样的问题；
　　主动收集或挖掘需求：
　　竞品分析，主要是在研究竞品或者同类型产品中，发掘比较好的功能且适用于自己产品（能解决一部分用户的需求或者能为企业带了一定的收入）
　　用户研究，自己在论坛、贴吧、微博等内容社区，了解社区里那些属于自己产品的目标用户或潜在用户都在吐槽或者期待产品的哪些内容，产品要做的是了解这些问题背后的原因是什么，其次是怎么能解决这些吐槽或者满足用户需求。
　　需求类型
　　需求类型主要是记录此类需求属于哪一个类别的，前期需要定义好需求类型有哪些？主要需求类型有：
　　新增功能、功能改进、体验提升、BUG修复、内部需求等。
　　（我们公司主要是按需求来源划分的需求类型，业务需求、UI优化、QA优化、技术优化、产品优化、用户建议，和需求来源整合在一起，属于需求来源的一部分）
　　需求添加时间
　　此需求添加到需求池的时间，而不是需求提出人初次提出的时间。目的统计需求明确到需求上线的周期。
　　优先级
　　需求池中的需求优先级可以用高、中、低来初步进行确定哪个需求的优先级更高。通过需求评审后的需求，优先级更应该按照1、2、3、4的顺序进行排列。假设用高、中、低来确认需求优先级，会存在什么问题呢？当确定下个版本上线5个功能点（其中2个高、2个中、1个低），由于开发进度和开发资源的问题，5个功能点中只能如期上线3个功能点，那么就需要考虑在2个中的需求中先上线哪个？这样的话，前期按照高、中、低来评审需求优先级就存在不严谨性。
　　优先级判断原则：（四象限法则和kano模型结合）
　　重要且紧急（基本型需求） —— 必须g抓紧时间做。比如会影响到用户主流程使用的功能。（高）
　　紧急但不重要（魅力型需求） —— 只有在优先考虑了重要的事情后，再来考虑这类事。（中）
　　重要但不紧急（期望型需求） —— 只要是没有前一类事的压力，应该当成紧急的事去做，而不是拖延。比如节日优惠相关的需求，但是现在距离下一个节日还有3个月。（中）
　　既不紧急也不重要（无差异型需求） —— 有时间再处理，比如IOS和安卓视觉个别小按钮视觉不太一致。（低）
　　状态
　　待讨论、暂缓、拒绝、已明确。已明确的需求基本上下一步就是进行版本规划了，这时候需要重新评估需求优先级（用1、2、3、4数字标识），定哪个版本上线、版本啥时候发布。
　　备注
　　其他任何信息，如：需求期望完成时间、被拒绝原因、暂缓原因。
　　三、需求池有什么作用
　　需求容器
　　直白的来说，需求池就是个需求容器，不同来源的各种需求都可以进入（简单评审），进来之后的需求进行再次的评审，最终决定这个需求的去留。
　　缓冲地带
　　一段时间内来了较多的需求，而自己没法第一时间进行评估需求的合理性，这时候可以将需求先放进需求池内，后期自己再慢慢消化，再严格的评估需求的合理性。
　　版本规划
　　经过再次评审后留下来的需求，可作为下个版本发布的内容或下几个版本迭代的内容，目的是确保在做版本规划时有足够的素材来源，而不仅仅的靠自己盲目的规划。
　　四、总结
　　以上是自己在整理需求池相关内容的一些想法，主要是结合自己工作整理的，由于是自己公司内部使用的，所以可能存在一定的局限性。欢迎大家多交流学习。