参与到项目中，经常发现项目的需求源源不断，刚做完一堆需求，马上又有新的需求要做，感觉总是做不完，就像一个“无底洞”。实际上，这里涉及到一个需求管理的概念。项目中哪些该做，哪些不该做，做到什么程度，都是由需求管理的过程来决定的。而需求管理可以通过需求池进行维护跟踪。

需求池概念

1. 使用场景

在项目工作中，经常会碰到客户说我之前给你们提了一个某某需求，怎么还没有上线。然后产品经理根本就没有找到该需求的任何记录。客户的忘性很大，很多时候都不记得曾经说过什么。这个时候就需要有一个通过信息记录，帮助客户找回需求记忆。

在实际工作中，产品经理每天都会面临各种各样的需求，如果仅凭大脑记忆而没有及时记录下来，就容易产生需求信息丢失。此时需求池就是一个很好的工具，产品经理可以随时记录各个来源传递过来的需求，以防需求或者关键信息遗漏。

需求池作为需求管理的一个容器，相当于需求的数据库，为需求分析提供数据来源。需求池一般采用最简单的Excel，原因是简单、易管理。这里不仅仅是简单记录需求是什么，还会记录这个需求相关的一些关键要素。比如用户（who）在什么模块（where）遇到什么问题（what），希望达到什么效果（how）。

需求池的维护原则是宽进严出，“宽进”主要是因为需求池面对的产品经理或者产品部门，是需求的备忘录，所以需要把所有的需求都应该放到池子里。而“严出”则是需求池的需求需要经过筛选、分析、规划之后，才正式从需求池进行到后续的需求文档中安排开发。

2. 需求池属性

需求池的模板参考上图，需求池的关键属性说明如下：

（1）编号

编号就是需求池的顺序号，主要是需求的唯一性标识。通常情况下，项目中会有多个业务系统，每个系统单独维护一个需求跟踪表，需求编号的命名规则即为：系统英文简称_OR（原始需求缩写）_顺序号。

（2）功能模块

把需求划分到系统的某个功能模块，由于需求池的需求还未经过进一步的分析，一般只需要划分到系统的一级菜单。

（3）需求类型

需求类型一般包括：新增功能、功能改进、需求变更、界面优化、Bug修复、删除功能、接口需求等。

• 新增功能：已发布版本中尚未包含的功能。
• 功能改进：对已发布功能做可用性、易用性的改进，比如性能优化、架构优化等。
• 需求变更：相对新增需求而言，提出方的需求发生改变，原来的需求变更为“删除需求”状态，并记录关联关系。
• 界面优化：UI层面的改动，如按钮颜色。
• BUG修复：系统上线之后，反馈回来的Bug视为需求统一管理。
• 删除功能：去除已发布的功能。
• 接口需求：我方是数据使用方，使用对方提供的接口，和我方是数据提供方，提供接口供对方使用。

（4）需求名称

用简洁的短提炼出用户的诉求。比如：文本框搜索框支持点击键盘Enter键触发查询功能。

（5）用户故事

我们要明确用户是在什么场景下，为了完成什么目标而需要做什么任务。即要从场景、目标和任务这三方面去具象化需求。

比如场景：针对查询申请单，查询专员发现运营商反馈的文件不对；任务：支持在原来的查询单上重新发起查询请求，以便运营商接收到新的指令，可以再次反馈文件；目标：运营商根据查询申请单反馈正确的文件。

（6）优先级

需求的优先级可以根据需求重要性：核心需求、基本需求、建议需求和需求的紧迫性：非常紧迫、一般紧迫、无紧迫性这两个方便来定义出三个等级：高、中、低。

（7）提出人

需求的提出者，有疑惑时便于追溯，负责解释需求。

（8）提出时间

原始需求的提出时间，辅助信息。

（9）关联需求

该需求和需求池中哪些需求有关联，一般在需求分析的时候需要参考的相关信息。

比如：同一个需求，但是不同从不同用户采集的信息不一致，或者多个用户对同一个需求信息的表达观点矛盾，那么这个就要用到关联性编号。比如A用户希望登录的时候，需要选择当前用户的所属机构，用户名和密码。B用户建议登录的时候，直接通过用户名和密码即可。这2个需求，就是关联需求。

（10）需求来源

需求的来源主要包括：用户调研、竞品分析、运营反馈、领导意见等。

• 用户调研：通过用户访谈收集需求，可以是面对面沟通，也可以通过微信、QQ、电话等方式获取信息。
• 竞品分析：通过在市面上找到同类竞争产品，深入体验竞品功能，为产品设计及需求收集寻求思路。
• 运营反馈：产品上线后，运营同学会把用户在使用过程中会发出反馈的吐槽的或者建议的信息，反馈给产品经理。
• 领导意见：实际工作中经常会遇到老板一句话的需求，这些需求往往来自于老板身处的高度和丰富的工作经验。

（11）需求状态

随着产品的进展，需求的生命周期会以不同的状态标识，比如：待讨论、需求中、开发中、已发布、暂缓、取消。

• 待讨论：刚刚提出或尚未讨论或技术尚未确认的需求。
• 需求中：已完成排期的需求。
• 开发中：已经进入开发或尚未发布的需求。
• 已发布：已经发布的需求。
• 暂缓：讨论完成尚未排期的需求。
• 取消：无效需求。

（12）开发版本

在经过后续的需求排期之后，记录原始需求是在哪个版本开始实现的。

（13）备注

其它任何信息，如：

1. 被拒绝的理由；
2. 被暂缓的理由和重启条件；
3. 其它相关文档。

3. 如何正确记录一个需求

在产品经理的日常工作中，我们来看一个需求采集的场景。

当产品正在画原型的时候，发现电脑右下角的QQ图像闪烁，打开对话框，看到运营同学发过来的消息，进行如下对话。

需求沟通之后，产品经理需要及时把信息记录到需求池中，以防需求信息的遗漏。而且在需求记录的过程中，还能再次梳理需求，进一步挖掘需求信息，为后面做需求分析和设计提供重要依据。

通过维护一个健康的需求池，我们给需求提出者一种信息反馈，就是他们的需求我们都重视了，已经放到了需求池当中，但是是否安排给开发需要根据所有需求进行“轻重缓急”的权重比较才能决定。这样可以及时给相关人员反馈需求排期和进度。

总结

需求池其实就是信息传递的载体，还可以为后续需求变更提供信息依据，也便于领导或者相关人及时了解需求状态，了解产品的整体情况，了解每个迭代版本完成了哪些需求，便于产品进行进度把控和需求验收。

由于市场环境，用户行为都有可能发生变化，这个时间段的需求有可能过一段时间就失去意义了；或者之前暂缓的需求，在目前的市场环境和产品情况下，该需求的紧迫优先级变高了，需要纳入到下一版本的需求排期。故需求池需要产品经理定期梳理，每次安排产品版本计划的时候都要重新审视一遍需求，对所有的需求再次进行分析和筛选，进行需求优先级的定义。

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

题图来自Unsplash，基于CC0协议。