现实中关于需求会出现很多问题：
需求太多，跟着跟着跟丢了某一个
需求启动周期长，记不清负责人
时间长了，需求来源渠道不明
需求太多、太复杂了，无从下手
......
这都是没有记录，或没有进行需求管理造成的，时间久了很容易出现扯皮的现象，所以需求的记录和管理是很重要的。
需求的来源也是很广泛的：
老板提出的需求
各个渠道的用户直接反馈的需求
来自数据分析的，数据驱动产品迭代
通过用户研究、调研、访谈或问卷得到的需求
公司内部通知反馈的需求，比如运营团队、市场部、商务部等等
产品经理们自己想做的
......
需求来源特别多，先不说如何辨别需求的真伪，就单纯的管理需求也很重要。
这么多的需求，一层一层的都叠在开发周期上，是错误的，我们需要完成需求池的搭建。
一、需求池
需求池是对现有需求的一个汇总和统计，它的主要作用在于帮助需求评估和管理。
排除第三方工具，这里提供一份相对完整的需求管理架构，供参考。
1、编号：需求的编号，方便在需求池里管理检索查询需求。
2、端口：需求涉及端口，移动端、PC端、Web端、微信小程序等。当业务复杂时，或者负责的端口较多时，这种需求管理是很高效的。
3、模块：基于端口下的模块，比如移动端下的登陆注册、首页、我的、消息、发现、等。
4、子模块：基于主要模块下的子功能，比如消息模块，涉及系统消息、内部IM消息、评价消息等。
5、需求名称：简短概括需求是什么。
6、需求描述：更详细描述需求的相关信息，例如需求提出的背景、需求要达成什么目的、需求的详细说明等。
7、需求层次：基础、扩展、增值。
8、需求分类：每个公司都不一样，一般是新增功能、功能改进、体验提升、Bug修复、内部需求。
9、需求来源：上文提到的。
10、优先级：需求的优先级有很多种，可以是1至5，可以是A至E，可以是高、中、低等，自己能看懂就行。需求的优先级是动态的，会随着企业的战略目标不断发生改变。
11、提出时间：记录需求被提出的时间，用于区分需求产生的年代，有些项目真的可以沉淀下来很有年代感的需求。
12、提出人：提出这个需求的人，对于还没设计的需求有助于在需求详细设计时追踪到原始需求。
13、需求状态：没有标准的规范，一般是初始状态、待论证、待设计、设计中、需求评估、被拒绝、暂缓、待开发、开发中、待测试、测试中、已上线、关闭（终止）。根据公司具体情况制定。
14、预计开发工时（人/天）：预估工作量。
15、开发人员：记录开发人员，以便后期需求改进或追溯。
16、测试人员：记录测试人员，以便后期需求改进或追溯。
17、立项时间：评审通过的时间。
18、预计开始时间：梳理当前任务，预估开始时间。
19、预计完成时间：根据工作量，预估完成时间。有的高层领导有明确的deadline，那就必须记录清楚，并执行到位。
20、实际开始时间：根据实际情况，记录开始时间。
21、实际完成时间：根据实际情况，记录完成时间。
22、上线时间：根据实际情况，记录上线时间。
23、备注：针对各种情况进行补充说明，例如需求拒绝或暂缓的原因。
通过记录上面的信息，就可以通过筛选功能对需求进行方便的查看和分析。
二、注意事项
1、需求池的规范不是固定的，请大家根据公司实际情况制定。
2、需求跟进：
需求池中的需求如果在需求评审会上被拒绝或暂缓，需要在备注中说明情况，也必须通过邮件的方式告知提出需求的人，切忌石沉大海一般毫无反馈。
如果需求已经进入开发队列，产品经理则需要不断跟进需求的状态直到开发完成，最后验收，这里也同样切忌只管头不管尾。
总而言之，需求跟进流程确保每个需求都能有一个结果，这是产品经理的工作职责。
3、需求不分大小，不分缓急，一律进入需求池进行沉淀。这样可以简化流程，也可以避免需求的遗漏。
4、需求池的作用是沉淀需求，而不是实现每一个需求。
5、若是团队共同管理需求池，可以使用在线文档，例如石墨文档/腾讯文档，能方便的让团队合作编辑，而且可以很方便的共享给其他人。而且需求池属于敏感信息，这两种产品都支持权限设置，不需要企业进行额外的研发即可实现。
6、收集需求不是目的，达成公司长期战略目标才是，所以需求池是需要定期回顾的。可以以天、周、月为时间维度进行回顾，可以自己看、和产品团队一起看、可以和研发一起看，也可以和目标用户一起看等等。总之，需求池只是一个开始，要定期回顾总结。
对产品经理感兴趣的朋友，可以移步“如何自学产品”
期待共同交流
