产品经理每天都需要面对大量需求，很多朋友会通过“需求池”对零散需求进行统一、高效、有序的管理。但需求池只是需求呈现的载体和工具，并不能包治百病，实际操作中会出现各种意外，比如：
无效的需求记录：不是指需求记录的不清晰，而是指明显不符合产品定位、场景不明确的需求未经筛选就被记录。
超量的高优先级：需求方都认为自己的需求更重要更紧急。面对多方的各种催促，出现了大量高级别需求，导致等级制度失效。
短视的版本规划：将迭代周期内的需求塞满即可。把需求、设计、上线做成了下意识的循环，缺乏产品整体层面的发展规划。
为了避免需求管理的效果打折扣，接下来根据需求的流转，依次讲解需求处理过程的管控要点。
需求是产品的源头，产品是需求的解决方案。所以，有效采集需求是需求管理的第一步。虽然每个产品所处的环境存在差异，但是为了不在需求阶段迷失其中，需要从全局角度对需求来源、采集方法、需求筛选（初步）有整体的认知，便于后续对不同需求采取更合适的应对策略。
1. 需求获取渠道
不同产品的适用场景和使用角色都不一样，造成了需求来源较为复杂的现象。可以通过渠道通用属性的方式进行分类。
分类目的在于全面了解产品的相关方，避免遗漏。毕竟不是每个角色都会主动反馈问题和需求，更多情况下需要产品经理主动沟通和挖掘。产品经理不要忘记“沉默的大多数”。
渠道分类的维度也多有不同，本文以内外渠道区分为例：
内部同事：组织内任何和产品相关的角色都有提建议的权利。比如：Boss、销售、运营、技术等。
外部客户：客户通过对应渠道反馈产品需求或问题。在项目中客户也区分决策人、使用人等多种角色。
产品经理：基于对产品、用户、发展战略的观察、分析等行为，进而得出需求。
2. 需求采集方法
需求获取的方法是多样的，有的是产品经理通过设计进行获取，有的是客户主动进行反馈。具体方法如下：
产品方获取：由产品方主动获取需求的方式。如：行业研究、调研问卷、实习轮岗、数据分析、现场访谈……（详见：B端需求调研：客户访谈操作详解）
客户方反馈：由客户方主动反馈需求或问题的方式。如：客服咨询、用户投诉、意见建议、公开渠道的评价（微博、垂直社交媒体……）
客户主动反馈时，产品经理并不能改变采集方式。针对产品经理主动获取情况下，采集方式应当如何选择？我们知道每种方法各有优劣，要结合实际情况灵活选用。影响选择的关键因素有哪些呢？我认为至少考虑以下3方面：
用户是否接受此方式？面向不同角色，或同一角色的不同场合。用户对各方式的接收程度都是不一样的。有时我们希望面谈，但客户总是没时间……
资源是否支持此方式？公司的时间、人力等资源都是有限的，产品经理需要在合理资源限度内完成采集。比如实习轮岗，可以较深入的了解现场，但耗时太长，通常采用的比较少。
能否达到采集的目的和效果？如果调研后没有达到目标，意味着采集无效以及投入资源的浪费。
3. 需求初步筛选
通过各个渠道获取需求后，就进入的记录阶段。会发现需求总是源源不断的过来，但是产品经理的精力以及公司的资源都是有限的。所以要辨别需求的真伪和潜在价值，把不符合要求的需求剔除，不计入该产品的需求池中，避免后续资源的无效投入。
筛选的过程是“砍需求”的过程，是对需求潜在价值判断的过程。除了要对产品本身有所了解，也需要专业能力的支撑才能更加准确的判断。事实上，从需求收集到研发上线之间会经过多次“砍需求”。
此时作为初步筛选，要求并不严格。只需要做2件事：需求场景还原，需求属性分类。
1）需求场景还原
需求有对应的完整场景是筛选的第一步，如果还原不了场景，则认为需求是假需求。场景还原只需要问几个问题，能回答出来且逻辑自洽即可——谁（角色）在什么情况（背景）下，遇到了什么问题（需求）？当前的处理方法是什么？
场景还原时需要将相关的场景进行穷举，避免因场景遗漏导致后续产品设计时出现漏洞。
需要注意的是，有的需求场景还原完整，但不符合本产品定位，此类需求对本产品无价值，但需求本身没问题。建议记录在另一张需求池表单中，作为外延产品的需求储备。
2）需求属性分类
除了需求基本的信息记录，还要判断需求的类型，为后续的需求评级和需求分析提供支持。比如：核心需求，基础需求，衍生需求，技术需求，运营需求，体验需求……
需求分类同样没有标准答案，存在多种维度的分类方式。重点在于你定义的需求类型，在后续分析中是否存在对应行动策略，如果仅作为需求池的统计查看使用，意义不大。
存在潜在价值的需求将被一一记录在需求池中，等待下一轮的筛选和价值分析，直到被某个版本选中……
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
