编辑导语：产品经理日常会接收到大量来自其他部门提出的需求，或者自身发现的需求点；但并非所有需求都要立马实现，所以要创建一个需求池进行管理；本文作者分享了该如何创建需求池，我们一起来看一下。

作为产品经理，会收集到来自四面八方的需求，而将这些需求放进我们创建好的需求池中并进行有效管理是我们首要的任务，今天我就来讲一下如何创建需求池。

一、没有需求池的场景和问题

刚刚入行产品经理的时候经历过这样的问题——需求源源不断。

有时候这个需求没做完又会出现新的一堆需求，这些需求都来自客户的、技术的、领导的、团队讨论的、运营反馈的、产品经理自己提出的、还有老板的灵感等等；这些需求来自四面八方。

下面我们来说一下，这种场景下没有需求池，我们都会遇到哪些问题。

1. 信息分散、导致需求遗漏

如果没有需求池统一管理需求，我们就会将随时随地来自四面八方的需求随意的记到方便记录的地方；勤快些的会记录在电脑的各类记事本或写在本子上，还有过于自信童鞋就直接记在脑子里。

举个例子：

我最早留下的习惯是将随时接收到的需求记录在本子上，俗话说好记性不如烂笔头嘛。

将小A提出的需求写在本子的第17页，过了几天将小B提出需求写在第36页 …在过很久又将小C提出的需求写在第N页；等到有一天想做小B提出的需求时，发现在本子上找不到记录在哪一页了，只能苦命的从第一页开找。

这种情况经常发生，有时候需求过多，每天可能会收到不同人提出的多条需求，有时候在本子上找不到还怀疑是不是记录在了电脑记事本中？或者产生“是不是我没记录下来”的自我怀疑。

这些都是因为将零散的需求存储到不同的地方所导致的，时间久了还会导致需求遗漏；各种需求提出人来问，之前提的需求为什么还没有实现？然后产品经理压根不记得或是找不到这个需求。

2. 没有信息源头追溯，传递需求时容易导致需求变形

假设我们有一天想实现一部分需求，这些需求包含自己收集的，也包含其他人收集到的需求经过几手最后到你手上的；当我们在做产品设计的时候发现一些问题（这些问题会因为基于在某个成型产品做迭代而大幅度产生，有些是因为产品本身设计方式导致实现新需求而改动较大），或者对需求内容不理解，想找人确认时，这时想找需求提出人又想不起来或不知道是谁提出的。

那么就产生了没有信息源头追溯的问题，如果按照我们自己理解的方式去做，最后就会导致需求变形。

二、什么是需求池，创建需求池的目的

了解了没有需求池会产生的问题，下面我们来说下什么是需求池。

需求的来源主要有用户需求、老板需求、用户调研等，如果没有需求池，这些需求会散乱在各处；需求池首先解决的问题是将散乱在各个地方的需求汇总，我们可以将任何人，任何时间，任何方式产生的需求统一归总到需求池中，避免丢失。

其次我们在收集需求的第一时间可以和需求提出人了解清楚需求的详细信息，避免过很久后在追溯，找到需求提出人时不记得了，容易导致错过好需求。

创建好需求池后，我们可以通过需求池中统计的信息去判断需求和需求之间的关联性，同时可以通过这些信息判断并明确需求的优先级，从而做好产品的版本规划；我们在日后工作过程中可以按照优先级随用随取，也可以按照制定好的版本按顺序开发。

简单理解，需求池是装需求的池子——是需求管理和项目管理的依据；我们可以根据这些规则信息进行制定需求的版本规划，同时通过需求的记录可以追溯到需求提出人，后续有问题作为和领导、老板沟通的依据。

三、如何创建需求池

上面我们提到，创建需求池的目的是将散乱在各处的需求汇总，那么创建需求池首先要建立固定的格式。

为了日后溯源，还需要记录需求来源信息；为了辅助我们对每条需求进行分析、归类、建立版本规划，还需要有优先级、需求场景等信息，下面我们来看下建立固定格式需要的字段信息都有哪些。

为了方便理解，我将这些字段分成基础信息及扩展信息，基础信息是创建需求池不可缺少的字段，扩展信息可以在基础信息上灵活调整，不是必填信息。

1. 基础信息

基础信息主要包含的信息有：编号、模块、功能点、需求描述、场景描述、需求层次、需求类型、优先级、商业价值、提出人、提出时间、状态。

下面我来依次讲解下这些信息都是什么：

1）编号：需求的唯一标识，可用序号罗列，也可以用日期+当天提交需求的序号统计；作用是作为每条需求的唯一编号和快速查询需求。

2）模块：根据产品模块去划分，例如“个人中心”作用是将需求统一归类到某个模块下，在进行版本规划时，可以优先从某个模块中筛选，同时便于根据模块查询。

3）功能点：简单描述需求的功能，也就是要做什么；这样我们快速查看某个需求时，能一眼看明白这个需求是要新增或修改哪个功能。

4）需求描述：需要描述清楚需求的完整性、一致性，需要精准的描述；如果产品经理在后续想不清楚这个需求到底要做什么，可以通过需求详细描述来回想或了解。

5）场景描述：了解用户在什么场景下产生的需求，便于我们分析需求背后的价值，在给开发转述为什么要增加这个需求时，可以清晰的说明是因为哪些原因，更能说服开发愿意做这个需求。

6）需求层次：分为基础需求、增值需求、扩展需求；便于产品经理了解需求属于哪个层级，可根据需求类型、需求价值、优先级、需求层级等结合考虑版本规划。

7）需求类型主要包含：

• 新增功能：目前平台没有实现的功能；
• 功能改进：对目前平台已实现的功能进行优化；
• bug修复：系统功能使用出现问题，与正确的设计逻辑不一致；
• 用户体验：例如页面按钮摆放的问题，发送消息时发送按钮放在右侧，可以按照用户的使   用习惯设计；
• UI优化：页面体现内容，如按钮颜色；
• 内部需求：公司内部产生的需求，如开发一个内部OA系统；
• 删除需求：对平台已有的功能进行简化；
• 接口需求：使用对方提供的接口，或给对方提供接口。

产品经理可以根据这些类型区分，在产品开发阶段根据需求类型考虑先实现哪些，例如：在时间紧急的情况下，有新增功能和bug修复的情况下，我们会优先解决bug修复这类型的问题，先保证项目不会出现问题。

优先级：P0紧急重要 → P1紧急不重要 → P2不紧急重要 → P3不紧急不重要；可根据实际情况根据商业价值、需求类型、需求层次等信息综合判定优先级，按照四象限法则将需求分别放进这四象限中，最后按照顺序一一完成；可以帮助产品经理有条不紊的完成工作，也可基于优先级这几个分类考虑到版本规划中。

商业价值：可以按照0-10标注，不需要考虑实现难度，在需求讨论时团队讨论决策即可；提前分析好商业价值能帮助我们了解清楚当前需求是否值得做，做完后能带来什么价值；不做的话会有什么损失。

开发量：需求的开发工作量，可以通过这个信息规划开发每个版本的工作内容，也方便我们了解每个需求的开发难度。

提出人：原需求的提出人，便于日后有疑问可追溯。

提出时间：需求的提出时间，方便我们了解是什么时间提出的需求，同时可以利用提出时间来规划需求的紧急程度。

状态：需求的生命周期，待讨论、暂缓（标注原因）、拒绝、需求中、开发中、已发布；主要作用是可以对需求的流转状态进行跟踪，可以了解需求在不同阶段的状态，发现问题及时调整。

2. 扩展信息

扩展信息包含：

• 原始需求：即需求提出人的原描述内容，主要目的为了保留提出人的表述，过后对需求理解有误或跟需求人对接时方便提出人回忆需求内容。
• 价值描述：需求的价值分析，需求的价值可能会根据时间变化而改变，根据团队讨论好的价值分析，将分析原因简明概要的写在上面，日后回溯时可以迅速了解到当时是出于哪些思考确定的价值分析。
• 录入人：需求是谁录入的，日后也可根据此信息找到录入人了解需求详细情况。
• 负责PD：状态进入到“需求中”时确定；目的是记录，需求完成后或出现什么问题可以找到该负责人。
• 设计负责人：状态进入到“开发中”时补充；目的是记录，需求完成后或出现什么问题可以找到该负责人。
• 开发负责人：状态进入到“开发中”时确定；目的是记录，需求完成后或出现什么问题可以找到该负责人。
• 测试负责人：状态进入到“开发中”时确定，或者开发结束后补充；目的是记录，需求完成后或出现什么问题可以找到该负责人。
• 期望上线时间：需求提出人期望该需求的上线时间，可以通过此时间来考虑需求实现的优先级。
• 最终上线时间：记录最终上线时间。
• 备注：对该需求的备注信息。

最终需求池的模版（基础信息）：

最终需求池的模版（扩展信息）：

四、总结

需求池是产品经理不可缺少的工具，本文中主要根据没有需求池容易产生的问题介绍了什么是需求池、创建需求池的目的及创建需求池所需要的字段信息。

最终的模板字段需要按照公司实际业务灵活变动，文中提供的字段信息仅为参考，主要目的是为了帮助产品经理创建并管理自己的需求池。

本文由 @张悄悄 原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自 unsplash，基于CC0协议