需求伴随着整个产品的生命周期。一款好的产品要不断优化迭代，满足当下的需求是远远不够的，要能回想起过去可能被遗漏的需求，要远眺到未来可能产生的需求。所以在需求阶段也需要细分工作。总结了自己的工作经验之后，我将有关需求的工作分为四个部分：
将从各个地方收集回来的需求汇总到一张需求收集表
在需求收集表中的排除伪需求后，将需求写入需求池
定期每月/每季度将需求池中的需求归档
产品上线后，根据用户反馈和相关数据对需求进行复盘
需求收集
除了工作时间，日常生活中也会和各种各样的人、各种各样的需求打交道。早上上班进入电梯时遇见老板，他随口说的一句话，可能是需求；周末三五好友相聚在咖啡厅一起讨论某款产品的优缺点，可能是需求；从产品用户反馈窗口收到的用户消息，可能是需求……接收到的信息太多，当下又无法判断真伪，此时可以建立一个需求收集表。需求收集表不仅可以记录从别人手中获得的需求信息，也可以记录自己灵光一现的想法，更像是一本随手笔记。工作中不同部门可能都会有自己的需求收集分表，最后会在产品经理或产品助理手上汇总成需求收集总表。以下是需求收集汇总表内容示例：
序号
序号是为了使表格内容井然有序，一目了然，方便统计。
来源
需求一定要清楚其来源。来自大 BOSS的需求肯定要比吃瓜群众的优先级和真实度要高。吃瓜群众所要求的用户体验固然重要，但老板是站在公司长远发展的角度去思考问题，视角更加开阔。还有要知道产品经理是一个极容易背锅的角色（此处有个笑而不语的表情）。
接收人
这里的接收人指的是需求收集分表的需求接收人，并不是总表的接收人。
接收时间
记录下接收的时间方便需求复盘时回忆。
需求背景
这个字段的设置不仅对需求筛选入库需求池时起着重要作用，而且入库需求池后对需求的优先级排序，需求的真伪判断。
需求描述
需求描述是对需求的背景进行分析后，得出的结论，即具体增加的某个功能或者模块。
需求平台
这里记录的是需要添加功能或模块的平台：APP端，PC端或者系统管理后台等。
颗粒度
计算机领域中粒度指系统内存扩展增量的最小值。在这里可以理解为需求的细化程度。例如要增加一个社区互动模块，属于颗粒度大的需求，要增加上传图片的功能，属于颗粒度小的需求。
备注
备注记录的是表头中没有的字段的信息，以供参考。
需求池
“需求池”有个显得更（gao）专(bi)业(ge)的名称叫“product backlog”，指是指产品待办事项的集合。在需求池中的需求是在需求接收表中精挑细选出来的需求，意味着有可行性并且可以进入评审。在需求池中的需求需要排优先级，优先级高的需要尽快开发，优先级低的可以后续再跟进。以下是需求池的内容示例：
与需求收集表重复的字段就不再描述了，这里最重要的是优先级的排序方法。
需求类型
需求类型可以分为产品需求，运营需求，市场需求等，甚至还可以细分。
优先级
不同的公司会有自己的优先级排序方法，但肯定不是凭借产品经理的直觉判断的。常用的有四象限法则、KANO模型等。具体该如何选择适合自己公司的优先级模型后续文章会写。
需求状态
需求状态可以分为入库、评审、开发、完成、拒绝五种状态。
需求归档
需求与人的欲望一样是永远无法被满足的，旧的需求解决后一定会产生新的需求。如此日积月累，不加以整理的话需求表的内容一定会杂乱无章。所以我们需求定期整理我们的需求表（包括需求接收表和需求池中的需求表）。根据实际情况按照月度或者季度归档，是工作更加高效。
需求复盘
工作要定期总结，需求也是要定期复盘的。在产品或者功能上线后，根据使用情况对过去建立的需求进行分析，去验证建立需求时的方法是否正确，产品经理还可以总结对需求工作的心得。需求复盘主要是对接收需求阶段和建立需求池阶段的总结。
接收需求阶段
上线后回头查看接收需求表，可以验证产品有没有满足大多数用户的需求，可以从中提炼出更多的功能点在后续迭代的过程中优化产品。
建立需求池阶段
对这个阶段的复盘只要是验证自己工作中的方法论是否正确，特别是体现在优先级的排序上。如果按照某个方法排好的最高优先级需求，并没有解决核心用户的需求或者与产品的定位有出入，那这个方法一定是错误的，需要及时调整。
这篇文章是个人工作中总结和听过的网络课程总结，如有不足，请指点。
