提起需求，那得从很久很久以前说起。

01 日取其半，万世不竭

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

而不管看或者不看，需求总是在那里，不喜不悲。直到某个洒满阳光的午后，老板把你叫到跟前，说道：那个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个（需求描述、优先级【优先级真的很重要】、状态）
• 以及剩下5个水到渠成时自然就可以填好的字段（跟进人、预计实现版本、实际完成版本、上线时间、备注）

这么一想是不是简单多了，核心就是脑袋瓜需要飞速旋转的那么三个字段。举个例子，公司Q2季度的目标是提升订单转化，那么我们至少在Q1就需要提前分析获客流程、产品展示、下单流程相关的需求，并提前了解运营是否存在活动需求，相关的所有需求优先级自然会更高。但相关需求的优先级仍然存在先后，这还是由于研发资源、渠道资源始终有限。这个时间段思考的重点在于如何在恰当的时间满足恰当的需求。

06 定时回顾需求

需求池总不能像一只貔貅一样，只进不出。收集需求不是目的，达成公司长期战略目标才是。

需求池是需要定期回顾的，可以以天、以周、以月为时间维度进行回顾，可以自己看、拉着产品团队一起看、可以拉着研发一起看，也可以拉着业务部门代表或目标用户一起看。总之，需求池只是一个开始，是梦想开始腾飞的地方。

07 一点瞎扯

好了，经过半年的时间，需求池越发丰满，原来的小池塘也慢慢变成了一片汪洋大海，我们也将被老板以及各个业务部门的唾沫星子给淹没，如何从口水中脱身，是一门艺术。

这里先思考一下，为什么会产生需求？

因为我们总是有很多未经满足的需要。

所有的需求都应当被满足么？

当然不是，需求存在优先级，机会成本摆在那里。

用户总有需求没有满足，怨气很大怎么办？

转移注意力，或者满足他。

没法满足怎么办？

转移注意力。

忽略上边那段精神分裂般的自问自答，但核心逻辑是，需求得不到满足是一件很不爽的事情，但需求总是不可能被满足的，比较好的做法是，坦诚相待，转移注意力，给予期待。

需求池的目的是沉淀需求，而不是实现每一个需求。作为产品经理，不应该将所有的期待都着眼于通过研发的方式解决，而是可以通过第三方工具、优化业务流程等更多元的方式去尝试解决。用户不是一个群体，而是一个个活生生的人，他们有着各自的习惯、各自的思想，不能满足他的时候，总要想一些其他的办法。

小米的MIUI早期一直通过论坛收集用户的需求，也积极给与反馈，当你看到MIUI重视了你的问题并予以实现的时候，那种幸福感已经远远超过实现了你的需求那么简单。

08 一些工具

经过摸索，有以下工具可以在整理需求的过程中给你带来一定帮助。

（1）钉钉

钉钉可以自定义流程，这为没有独立开发OA的企业带来了福音，我比较喜欢请人事进行协助，自定义需求提交流程和紧急需求提交流程，这主要是针对公司内部人员提交需求。其中，

需求提交流程是：任何人可以在钉钉提交需求→任何人的直接上级明确需求的基本内容，判断是否符合企业价值，符合则通过→产品部负责人接收需求，并分配给相关产品经理进行后续调研→产品经理了解需求详细信息，并进行初步分析，并在钉钉回复需求的后续进展，反馈优先级并记录到需求池。

紧急需求是针对临时的，会打乱既定生产计划但又不得不进行调整的需求，与普通需求提交流程相比，在产品部负责人接受需求后，需要了解紧急需求所会造成的影响，告知主管的上级领导进行决策，通过后则尽快进入设计和研发上线流程。

在这个过程中，需求可以自由的流转给其他人，相关人员也可以及时了解到最新的进展，需求提出后不容易遗漏，每个需求都会被重视，并且产品经理可以在有空的时间进行回复，不至于总是被打断手中的工作。

（2）石墨文档/腾讯文档/SVN

这几种工具能方便的让团队合作编辑EXCEL，需求池的动态可以很方便的共享给其他人。另一方面，需求池属于敏感信息，这几种产品都支持权限设置，不需要企业进行额外的研发即可实现。

————END————

作者：路人，公众号：孚说产品

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

题图来自Unsplash，基于CC0协议