建立需求池

为什么要弄一个需求池出来？

因为一般需求是很多很多的，这些需求之所以多主要原因一方面是因为来源广，老板、公司运营、商务、用户等需求方都可以提需求，有时候是用户提出的一些小细节改动属于小需求，有时候是加一整个功能模块的大需求，另一方面是因为需求提很容易，拍个脑袋想一想又一个需求了，为了能够让这些零零散散的需求（不一定不重要）不被遗忘，所以都统统把这些需求登记到需求池里面，方便后期查询，不会遗漏或遗忘掉。

如何做一个需求池

需求池绝大部分情况都是用表格的形式创建的，主要的工具是Excel表格，一般Excel表格的表头会有这几个字段：序号、需求来源、需求提出者、所属部门、联系方式、需求所属页面（模块））、需求类型（新增、优化）、需求描述、紧急程度（一般分1到4等级，1为最急），期望完成时间，备注等，当然还有一些字段会增加或删减，具体看实际使用情况。

需求池做好，如何维护？

建立好这个表格之后，比较笨的做法就是把这份表格发给可能提出需求的人，然后定期收集他们写好的需求之后汇总，这样会增加产品经理一部分的工作量，首先定期整理，需要把多份表格复制黏贴到一份表格，即便你懂一些excel快捷操作也需要花一些时间，如何能够提高效率？这里我们一般会使用石墨文档、金山文档、腾讯文档等在线共享文档进行编辑。
举例腾讯文档，只需要在电脑端登录微信，找到腾讯文档小程序后打开腾讯文档，然后建立表格后分享链接出去，其他人就可以共同编辑，就省去了产品经理整理和汇总需求的麻烦。
以上都是比较常规的操作，当然还需要根据公司的相关习惯去做，有的公司会有类似于teambition、worktile、tower这类的协同办公平台，也是有需求池，需求池都大同小异，主要是搜集方式不一样，这个倒不复杂，这类软件也是很容易就能上手并知道怎么做。

需求池越做越大，开发资源有限，怎么办？

需求池永远都逃避不了的就是需求会越来越多，开发改进的速度很有可能跟不上需求提出的速度，导致需求越来越多积压起来，所以这个时候需要排一个需求优先级，先把重要紧急的需求先挑出来，先做该需求，或者做一些对产品未来规划帮助比较大的，或者先做老板提过来的需求，再去解决其他需求，对于已完成的需求，应该要标记为已完成，并把已完成的需求移动到另外一张已完成的表中，这样就不会看到需求越来越多了。
需求池的需求永远很难做完，这是没有关系的，对于如何解决掉需求，很多时候会使用到敏捷开发的方法对需求进行快速处理。
敏捷开发也就是10人组成一个小的开发团队，一个萝卜一到两个人一个坑，组成最小作战团队，每个作战团队只负责一个小需求，而需求完成时间是两个星期，一个星期开发，一个星期测试上线，可以让需求能够快速更新迭代，当然对于比较大的需求，则需要派更多的人手去做，这样能快速的“消灭”需求，让产品不断的进行“新陈代谢”。

做好需求分类、设置优先级并反馈

在整理需求之前，产品经理内心要明确 2 件事：负责产品的定位，以及当前阶段产品的目标。这样才能在管理需求的时候，有统一的衡量标准，确定好需求的优先级。优先级的方法很多，比如说紧急重要 4 象限等，我这边的优先级划分标准

  1. bug：评估影响，要尽快解决。
  2. 老板需求：尽快解决，无他，给你发工资的人，偶尔给你提一个需求，难道还要拒绝？还不赶紧处理好。
  3. 能给业务或客户带来直接价值的大小，确定优先级高低
  4. 与产品的定位契合，与公司发展大方向有关的，虽然和现阶段目标无关，但也是要记录到需求池中，虽然优先级可能不高，但会比较重要，需要时常拿出来看看。

举个例子：内部运营工具自动应答工具，不支持设置的关键词搜索，业务团队也反应过好几次，那这个要不要立即做呢？
看下产品当前阶段的目标：当前是要做一款快速拉新工具，帮助运营团队快速获客。虽然自动应答工具搜索不好用，但搜索的场景极少，遇到这种情况，可以查数据库解决问题。于是这个需求的优先级设置的比较低。
最后给业务团队反馈：已列入需求池，遇到类似问题找产品解决，但近半年不会有调整的计划。

总结

需求池最终是服务于版本的，B 端产品经理一定要在深入理解业务的前提下，整理需求并与业务验证，基于业务的目标来制定版本。
在收集需求时，要确保信息的完整和准确，不要想当然的加戏，添加一些自己想象出来的需求，虽然有可能给客户一些惊喜，但大概率是给自己挖坑。