需求池是需求管理和项目管理的工具，是下版本迭代时不知道做什么的依据，也是产品经理与领导、业务部门沟通更好的证据。

需求池：顾名思义“把即将要做或打算要做的内容放置到一个地方进行储存”，也就是INBOX的概念，有一个区域去放置我们的Stuff，Stuff中可能会包含一系列内容：想法、任务、目标、灵感、idea……

一、需求来源

各种行业，各种类型的产品经理都会跟需求打交道，但是需求的来源却不尽一致。可能对于做业务方向的产品经理，多数的需求是业务方给提出的；对于做2C方向的产品经理，多数的需求时自己通过调研或抽样得出的…

目前笔者在做仓储行业数据平台的产品经理，对于我来说可能需求最重要的两个来源就是【业务方】和【老板（总裁办领导）】；为什么我们的数据平台需求多集中于这两方呢？因为源于数据平台的产品定位是：为企业高层领导决策提供方向，为业务方提供数据分析；

无论是老板（总裁办领导）方的需求还是业务方的需求，他们可能主动向你提出，但是如果在你的产品年度规划中涉及到老板和业务部门的话，就需要你主动出击了。

二、为什么创建需求池

刚入行产品的时候，最头疼的两件事情：下个版本该做谁的需求 和 下个版本要做什么？

后来引入了需求池的概念，需求池两大优势治好了我的“头疼病”：明确量化需求优先级 和 新版本规划的依据。

2.1 明确量化需求优先级

做B端产品经理的时候，特别偏业务方向比较多的时候，会接到各式各样各种领导的需求，其中往往很多的需求有一个共同的特点，比如：这个需求很紧急、这个需求下周要、这个需求马上做……往往这时候我们会有一种感觉：资源是有限的，时间是有限的，需求是无限的；我们下个版本到底该先做谁的需求呢？

最初时接触过四象限的 *** 论，讲述是要把需求分一个重要紧急程度，但是工作使用一段时间的四象限之后，你会发现，仅仅只有重要紧急程度真的不够用，久而久之会发现处在同一层级的业务方领导需求重要紧急程度是一样的，上述问题又出现了，到底先做谁、后做谁呢？

这个时候我们需要对需求优先级进行量化（评分），需要引入一个工具“需求池”，通过需求池能够对需求进行集中管理，集中量化。

原先工作时的一个场景：需求池现在已经摆放了3个业务方的N个都非常紧急的业务型需求了。那么如何去把看似优先级一致的需求量化呢？这是一个很现实的也很烧脑的问题，难在考虑让参与需求量化评分的业务方的人都同意这个方案；

量化在于【量化模型】的搭建，量化需要考虑的有需求方（业务方）紧急程度、使用方紧急程度、开发设计资源三个；由此得出基础量化模型：【评分=业务迫切度/总工作量】。总工作量无外乎：数据产品经理、数据分析师、数据开发、UI、测试的工作量之和；业务迫切度需要结合公司综合考虑业务方、使用方的情况共同搭建出业务迫切度的模型，通过分析公司的整体情况，最终给定的业务迫切度由5部分构成：重要程度（5分制）、紧急程度（5分制）、使用人员岗位（5分制）、使用频率（5分制）、是否年度里程碑（2分制）。

越上层的的领导可能决策性的数据需要更多一些，基于平台定位，所以我会让这个点作为业务迫切度的重要因素；看板使用也是分频率的，可能有的报表看板一天使用一次，有的一个月使用一次，那周期越长显然分值越低；年度里程碑就属于公司规划内需要看重一些。

通过对上述量化模型的分子分母构成因素分析（分子属于维度，进行乘积计算，分母进行加和计算），就得出了需求量化的公式：

评分=（重要度*紧急度*使用人员*使用频率*年度里程碑）/Σ工作量（数据产品经理+UI设计师+数据分析师+数据开发+测试）

当然量化模型建立后，需要征集大家意见，当大家同意后，统一召开需求方评审会议，顺便叫开发设计人员共同参与，给出需求池中每个业务型需求量化评分，会议结束后，需求池中所有业务型需求均已被评分，从高到低优先级一目了然，需求方也没有“怨言”了。