产品经理，我们每天都离不开各种各样的需求

日取其半，万世不竭

作为产品经理，我们每天都离不开各种各样的需求，需求的来源往往十分广泛，可能来自老板、运营、市场、客服、用户中的任何一个人，也可能来自突如其来的灵光一闪。这些需求往往天马星空，可做可不做，偶尔还自带必须、马上需要的属性。产品经理往往在需求方和有限的研发资源之间纠结，游击，被敌视，直到变得强大。

而不管看或者不看，需求总是在那里，不喜不悲。直到某个洒满阳光的午后，老板把你叫到跟前，说道：那个XXXXX的需求，上了么？

脑海中开始飞速旋转，搜索起这些关键字，却得到了一个“找不到对象”的答复，不得不坦白此时心中所想。直到被吐槽完毕后，才想起数天前，与老板闲聊时候一带而过的过程中曾经提及。

此时追悔已是无用，摸了摸强且秃的前额，决定痛改前非，好好梳理一下需求。

02 什么是需求

讲到这里，我们先来谈谈什么是需求。这里我抛出一个自己的定义：需求是用户在一定时期内未经满足的需要。

这里包含了两个维度的概念，一是时间维度，是要在一定时期，因为需求总是有其生命周期的，刚开始的时候，需求不旺盛，最后的时候，需求已经变得可有可无。

二是空间维度，需要未被满足，如果已经满足了，他也不是需求，而是已经成型的方案或产品。

产品经理的工作重心，就是发掘产生价值的用户需求，并在合适的时间点让需求得以实现。

03 需求池的诞生

需求总是在源源不断的产生，相应的研发资源总是有限的，不可能无限制的满足所有人的需求，这个时候，就需要工具来管理和沉淀需求，这就是产品经理常用的——需求池。

需求池正如其字面意义，需求的池子，满满一个池子里，全是需求。

可事情总是有轻重缓急之分，需求也可谓是千奇百怪。例如根据手机壳改变软件主题颜色，又或者通过机器推荐资讯实现商业目标。

实际上，需求不分对错，有些看起来天马行空的需求，只要能择时去做，是能体现很大价值的，而很有价值的需求，时机不对，依然能拖垮整个企业。共享单车如果不是伴随着移动互联网的发展，是很难做出后来的成绩的（当然OFO的滑坡又是另一个课题了）

所以，我比较主张需求不分大小，不分缓急，一律进入需求池进行沉淀。这样可以简化流程，也可以避免需求的遗漏。

在这里解答一下为什么急的需求也要进需求池，而不是立即开始行动？

• 一是因为紧急需求往往时间紧迫，通常没有时间进行深入思考，导致为了满足需求而做需求，记录进入需求池的过程本身也是一个思考的过程，给紧急情况设置一重缓冲，降低失败率。
• 二是因为研发都需要进行排期，忽略实际情况闷着脑袋往前冲，偶尔一次可能还好，而紧急的情况随时都有发生，发生重大错误的概率也将随之增加。

我的做法是，紧急需求也纳入需求池进行管理，要合理安排产品版本，不能因为紧急需求的突然增加打乱既定的工作计划，紧急情况对原定计划有较大影响时，适当给原定工作计划进行延期。

04 需求池的真身

说了这么多，需求池到底长成什么样子？

需求池的具体形态是一张二维图表，用人话表述就是一张excel表格，大概长下边这个样子。

下面对一些主要的字段进行说明：

1. ID：这是需求的唯一ID，增加一个需求ID则增加1；
2. 端口：记录需求所涉及的端口，例如安卓、iOS、后台，这里是对需求做一个初步的划分，如果涉及到多端，一般记为综合或拆分成多条子需求（大企业拆分比较好，小企业直接记为综合）；
3. 模块：记录需求所涉及到的模块，例如登录注册、用户管理、财务管理等；
4. 需求名称：一句话简单描述需求是做什么的，例如根据手机壳颜色更换软件主题色；
5. 需求描述：更详细描述需求的相关信息，例如需求提出的背景、需求要达成什么目的、需求的详细说明等；
6. 需求来源：粗略记录需求的来源方，例如产品、市场、领导等；
7. 优化类型：记录当前需求的类型，例如是新功能，功能优化，bug修复；
8. 优先级：记录需求的优先级，一般用高中低或数字表达，需求的优先级是动态的，会随着企业的战略目标不断发生改变；
9. 复杂度：很多需求池模板中不会包括复杂度这一项，其实加入复杂度是有一定好处的，他可以帮助你在众多需求中找到优先级虽然并不高，但是调整后就能很大提升使用体验的需求；
10. 提出时间：记录需求被提出的时间，用于区分需求产生的年代（有些项目真的可以沉淀下来很有年代感的需求）；
11. 提出人：提出这个需求的人，有助于在需求详细设计时追踪到原始需求；
12. 跟进人：决定在某个版本实现需求时，指定跟进的产品经理；
13. 状态：需求当前的状态，根据不同的阶段，可以分为进入需求池（初始状态）→待论证（需求有待进一步论证）→待设计（论证完成后有价值并决定近期开展后续工作）→设计中（正在进行详细设计）→设计完成→研发中（已经正式安排研发排期）→已上线（需求正式上线），此外还有个特殊的状态——已关闭，针对需求因各种原因提前终止其生命周期；
14. 预计实现版本：对产品计划上线的版本进行计划（和研发版本不一定是一致的），产品部门规划的预计实现版本往往会提前研发几个版本，提前有所规划后，可以和相关部门的同事提前沟通，提升版本的成功率；
15. 实际完成版本：版本上线后，更新需求实现的版本号，以便后期追溯；
16. 上线时间：记录版本实际上线的日期；
17. 备注：针对各种情况进行补充说明，例如需求关闭的原因。

通过记录上面的信息，就可以通过筛选功能对需求进行方便的查看和分析。

05 有必要这么复杂么

不得不说，上边的需求池真的太复杂了，一共17个字段，不过稍微分析一下可以发现，其中：

• 不用过脑子的字段有4个（ID、需求来源、提出时间、提出人）
• 稍微过下脑子的字段有5个（端口、模块、需求名称、优化类型、复杂度）
• 需要脑袋瓜飞速运转的字段有3个（需求描述、优先级【优先级真的很重要】、状态）