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

丨前言

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

一．需求来源

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

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

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

二．为什么创建需求池

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

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

2.1 明确量化需求优先级

---

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

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

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

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

量化在于【量化模型】的搭建，量化需要考虑的有需求方（业务方）紧急程度、使用方紧急程度、开发设计资源三个；由此得出基础量化模型：【评分=业务迫切度/总工作量】。总工作量无外乎：数据产品经理、数据分析师、数据开发、UI、测试的工作量之和；业务迫切度需要结合公司综合考虑业务方、使用方的情况共同搭建出业务迫切度的模型，通过分析公司的整体情况，最终给定的业务迫切度由5部分构成：重要程度（5分制）、紧急程度（5分制）、使用人员岗位（5分制）、使用频率（5分制）、是否年度里程碑（2分制）。越上层的的领导可能决策性的数据需要更多一些，基于平台定位，所以我会让这个点作为业务迫切度的重要因素；看板使用也是分频率的，可能有的报表看板一天使用一次，有的一个月使用一次，那周期越长显然分值越低；年度里程碑就属于公司规划内需要看重一些。

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

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

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

需求池是集中管理需求、量化需求优先级的好工具，可以将很多需求放入进去管理，使用同样的量化标准（可以让每个人都信服），让每一个需求优先级的量化都有迹可循。通过量化，不仅能够解决“下个版本要做谁的需求”，还能够作为和领导沟通的“证据”。

2.2 新版本规划的依据

---

现在我们迭代计划为一周到两周，有时候感觉月度的计划是江郎才尽才凑的需求，只是为了项目经理管控的需求个数而建立的，自己并没有真正的计划下个版本要做什么。

为什么B端产品会出这种原因呢？有的可能因为公司业务比较少，有的可能刚入门没有规划，有的属于来一个需求沟通完就完事了，不进行记录...而我刚入行的时候属于后者，俗话说：“好记性不如烂笔头”，脑子再好用，也敌不过时间的杀伤力。每次当列下版本计划的时候，总是感觉隐隐约约有个需求，但是就是想不起来的那种痛苦感，真想当时就记录下来；这时需要一个需求池，对于需求进行及时记录、及时整理并且集中管理。

通过“需求池”作为管理、沟通的依据，将沟通的需求行之有效的记录下来；不仅能够安慰需求提出者，让需求者心里有一个想法：需求被重视了；另一有价值的点就是能够做到让自己不慌，清晰的规划处下个版本将要做的内容，作为新版本规划的依据。

三．如何创建你的需求池

“头疼病”的良方叫做“需求池”，开篇也说过，需求池就是承载你的想法、任务、目标、灵感...的地方，但是该如何创建呢？下面与大家一起分享

3.1 确定需求池基本字段

---

需求池最基本的字段（如3.1.1 图所示）肯定是必须要有的，基本字段就是对于需求的基本描述以及下版本规划沟通的依据；但是只有基本字段基本是解决不了上述问题的，只是能够缓解一部分的压力，所以我们要综合考虑如何去创建需求池。

图3.1.1 需求池基本字段

3.2 确定需求池增值字段

---

上文也说到过创建需求池的原因是想要通过需求池来进行需求优先级的量化，所以我们首先引入评分的概念；想要通过一系列的算法去把需求池中内容进行评分，公平公正公开，邀请相关人员共同参与，最终得分情况一目了然且对比于其他业务部门的需求以及自己的需求有一个排级情况认知，作为大家均认可的量化评分。

公司里面的年度里程碑计划和非年度里程碑计划会涉及到评分，所以是否年度里程碑会影响量化需求优先级，需求池中需要存在该字段；

同时我们会建立原始需求记录的字段，因为若是业务方领导或总裁办领导提的需求，总会有很多可挖掘的点，可能我们分析的产品需求只是一部分，原始需求存在，说不定可以剖析出其他的产品需求；

当然我们的优先级被量化之后，各个领导知道了我们对于需求池中需求的评分那么就会给出一个期望上线的日期，所以我们需要记录：期望上线日期；同时为了考量我们的产品规划、设计、开发、测试的进度，会增加一个实际上线日期，用来比对进展情况，一般会在复盘上一个版本使用

这样就根据我们的实际场景构造了一个需求池（后续是否增加字段视具体场景而定），主要包含下列信息（分别用3.2.1脑图和3.2.2 excel表进行展示）

3.2.1 需求池所有字段

图3.2.2（1） BI系统需求池基本字段

图3.2.2（2） BI系统需求池增值字段

Ps：因图片太大，特意将需求池字段展开为“基本”和“增值”字段

总结

需求池的创建源于你的实际场景，具体场景具体分析，不拘泥于形式，以适合自己的方式做好项目管理和需求管理为主；

本文主要以笔者所在公司情况举例，分别阐述了需求的来源，为什么创建需求池以及如何创建你的需求池，希望能够对大家有所帮助。

---

后续定期更新《习惯养成记》系列文章，主要讲述产品经理在实际工作中各个环节方法论的总结，同时也会新增其他系列类文章，可以关注作者或公众号，不错过任何一篇让我们互相成长的新文章。

---

作者：Viper

微信公众号：产品经理交流馆

B端产品经理，曾经负责过海外产品的产品策划工作，现负责大数据BI平台