需求管理机制的有效采集和过滤

lsekfe

产品经理每天都需要面对大量需求，很多朋友会通过“需求池”对零散需求进行统一、高效、有序的管理。但需求池只是需求呈现的载体和工具，并不能包治百病，实际操作中会出现各种意外，比如：
　　无效的需求[url=]记录[/url]：不是指需求记录的不清晰，而是指明显不符合产品定位、场景不明确的需求未经筛选就被记录。
　　超量的高优先级：需求方都认为自己的需求更重要更紧急。面对多方的各种催促，出现了大量高级别需求，导致等级制度失效。
　　短视的版本规划：将迭代周期内的需求塞满即可。把需求、设计、上线做成了下意识的循环，缺乏产品整体层面的发展规划。
　　为了避免[url=]需求管理[/url]的效果打折扣，接下来根据需求的流转，依次讲解需求处理过程的管控要点。

需求是产品的源头，产品是需求的解决方案。所以，有效采集需求是需求管理的第一步。虽然每个产品所处的环境存在差异，但是为了不在需求阶段迷失其中，需要从全局角度对需求来源、采集方法、需求筛选（初步）有整体的认知，便于后续对不同需求采取更合适的应对策略。
　　1. 需求获取渠道
　　不同产品的适用场景和使用角色都不一样，造成了需求来源较为复杂的现象。可以通过渠道通用属性的方式进行分类。
　　分类目的在于全面了解产品的相关方，避免遗漏。毕竟不是每个角色都会主动反馈问题和需求，更多情况下需要产品经理主动沟通和挖掘。产品经理不要忘记“沉默的大多数”。
　　渠道分类的维度也多有不同，本文以内外渠道区分为例：
　　内部同事：组织内任何和产品相关的角色都有提建议的权利。比如：Boss、销售、运营、[url=]技术[/url]等。
　　外部客户：客户通过对应渠道反馈产品需求或问题。在项目中客户也区分决策人、使用人等多种角色。
　　产品经理：基于对产品、用户、发展战略的观察、分析等行为，进而得出需求。
　　2. 需求采集方法
　　需求获取的方法是多样的，有的是产品经理通过设计进行获取，有的是客户主动进行反馈。具体方法如下：
　　产品方获取：由产品方主动获取需求的方式。如：行业研究、调研问卷、实习轮岗、数据分析、现场访谈……（详见：B端需求调研：客户访谈操作详解）
　　客户方反馈：由客户方主动反馈需求或问题的方式。如：客服咨询、用户投诉、意见建议、公开渠道的评价（微博、垂直社交媒体……）

客户主动反馈时，产品经理并不能改变采集方式。针对产品经理主动获取情况下，采集方式应当如何选择？我们知道每种方法各有优劣，要结合实际情况灵活选用。影响选择的关键因素有哪些呢？我认为至少考虑以下3方面：
　　用户是否接受此方式？面向不同角色，或同一角色的不同场合。用户对各方式的接收程度都是不一样的。有时我们希望面谈，但客户总是没时间……
　　资源是否支持此方式？公司的时间、人力等资源都是有限的，产品经理需要在合理资源限度内完成采集。比如实习轮岗，可以较深入的了解现场，但耗时太长，通常采用的比较少。
　　能否达到采集的目的和效果？如果调研后没有达到目标，意味着采集无效以及投入资源的浪费。
　　3. 需求初步筛选
　　通过各个渠道获取需求后，就进入的记录阶段。会发现需求总是源源不断的过来，但是产品经理的精力以及公司的资源都是有限的。所以要辨别需求的真伪和潜在价值，把不符合要求的需求剔除，不计入该产品的需求池中，避免后续资源的无效投入。
　　筛选的过程是“砍需求”的过程，是对需求潜在价值判断的过程。除了要对产品本身有所了解，也需要专业能力的支撑才能更加准确的判断。事实上，从需求收集到研发上线之间会经过多次“砍需求”。
　　此时作为初步筛选，要求并不严格。只需要做2件事：需求场景还原，需求属性分类。
　　1）需求场景还原
　　需求有对应的完整场景是筛选的第一步，如果还原不了场景，则认为需求是假需求。场景还原只需要问几个问题，能回答出来且逻辑自洽即可——谁（角色）在什么情况（背景）下，遇到了什么问题（需求）？当前的处理方法是什么？
　　场景还原时需要将相关的场景进行穷举，避免因场景遗漏导致后续产品设计时出现[url=]漏洞[/url]。
　　需要注意的是，有的需求场景还原完整，但不符合本产品定位，此类需求对本产品无价值，但需求本身没问题。建议记录在另一张需求池表单中，作为外延产品的需求储备。
　　2）需求属性分类
　　除了需求基本的信息记录，还要判断需求的类型，为后续的需求评级和[url=]需求分析[/url]提供支持。比如：核心需求，基础需求，衍生需求，技术需求，运营需求，体验需求……
　　需求分类同样没有标准答案，存在多种维度的分类方式。重点在于你定义的需求类型，在后续分析中是否存在对应行动策略，如果仅作为需求池的统计查看使用，意义不大。
　　存在潜在价值的需求将被一一记录在需求池中，等待下一轮的筛选和价值分析，直到被某个版本选中……