每个项目都会有一个需求池，你的项目应该也不例外吧。技术开发的速度，感觉总赶不上需求池增长的速度，身有体会吧。做不完的需求，清不空的需求池。每次版本迭代的源头，也许不是来自需求池；可是消化不了的需求，总是倒入了需求池。别再让你的需求池成为需求的垃圾堆，说说需求池的那些事儿。
一、需求池的定义
需求池：不在本次开发版本范围内的所有需求。严格来说，即使是下一个开发版本的需求，也可以算作是需求池的范围。需求池中的需求，有些可能只是一个想法，有些还需要调研，有些还需要讨论，总之，需求池中的需求和实际交付给开发的需求还是有一定距离。
二、需求池的由来
“好记性不如烂笔头”，一句话而概之，需求池的由来。你还记得上个月第二周的产品讨论会上xxx提出的想法吗？赶紧打开需求池看看吧。别让你的好想法就这样溜走，快点记下来吧。
三、需求池的作用
记录暂时无法消化的需求；
头脑风暴的源头；
版本规划的源头。
当你没有产品灵感的时候，需求池很可能会帮你一把。
需求有优先级，需求池自然也有优先级。优先级是个很难划定的东西，经常被人提到的“四象限法”：对需求进行归类，重大问题修复、重要体验优化、重要的新功能…这种比较主观的归类，每个版本都需要进行一次主观的优先级判断，相对来说太消耗时间了。有些需求或优化由于影响了正常的使用和核心功能，这样的需求优先级高，大家很容易达成共识。对于一些新功能和产品规划的方向性问题上，优先级的确定很可能会演变成一声拉距战，最后就是谁的级别高听谁的。
是否还有更优的确定优先级方法呢？当然有。优先级最好能够量化，减少主观判断，形成一个可视化的数学计算方法，而且让大家达成共识，也很重要。
试试从这几个纬度去考虑优先级
阶段性目标是什么？
需求服务的用户数量是多少？
投入产出比是否合适？
加入这几个纬度的考虑，很容易过滤掉一大半的需求，抓住重点，让大家共识重点。看似简单的东西，可是当时为了优先级争得面红耳赤的时候，谁还会记得它呢？基于这几个纬度，可以进一步对需求进行纬度细分和权重细分，讨论出一个优先级计算公式。以后优先级的讨论只要套用这个公式就行，一劳永逸。
五、需求池的细分项有哪些？
需求标题、需求描述、产品线、提交人、提交时间、功能模块、优先级、需求状态等，便于需求的追述、调研、细化，最终快速形成可以交付给开发的需求。无法满足这些选项的需求，也就没有必要进入需求池了，对待需求也需要一个严谨的态度。不是你的随便一个想法都能进入需求池的，这个idea满足了我们用户的什么需求？如果提交人回答不知道，我想就没有必要进入需求池了吧。需求池的细分项，让需求更立体化，更清晰，过滤那些想都没有想清楚的需求吧。
小结
