从3个方面聊聊，如何正确使用需求池？

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

需求池概念

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）需求来源

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

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

（11）需求状态

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

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

（12）开发版本

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

（13）备注

其它任何信息，如：

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

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

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

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

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

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

总结

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

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

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

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

给作者打赏，鼓励TA抓紧创作！

**赏

1人打赏