从事产品工作的小伙伴，在工作中，应该会遇到出现大量需求，而不知道如何筛选管控的问题，那么，我将从以下几个方面来讨论需求管理：
1. 需求初步筛选
作为产品经理，需要在沟通需求时，对需求的实现方案、所耗成本和资源、预期效果、是否有实现同样目标的低成本替代方案等，有一定的判断力，即需求初步筛选。
下面我们以具体案例来说明，我之前公司因为融资路演，在路演的过程中，就有投资人提出希望能够体验一下活动课程的购买支付流程，那么这个时候，公司CEO提出需求，希望在第三天的路演过程中，投资人可以0元支付，并且提交活动课程订单。
接到需求后，首先分析实际情况，初期开发开发时，未考虑类似这样的免费支付情况，系统无法处理0元订单。开发目前已经全部投入到一个大版本迭代需求中，暂时无法解决临时新增的需求。即使全部人员停止开发当前版本，全部投入到该需求中，开发、测试、上线（提交苹果和安卓应用市场）一共只有2天时间。且该需求仅在当下特殊情况下使用，未来业务场景不存在该情况。那么经过分析该需求从时间上无法完成，且必要性不是很大。
经过沟通，最后解决方案为，发布1元或者o.1元订单，这样投资人如果真的想要体验支付流程，那么就可以直接下单。ps：如果该投资人真的想要要回这1元钱，我们老大给他发红包好了，哈哈哈。换一种思路，完美轻松解决
其实从产品的角度来看，这也算是一个产品MVP，如果该需求经分析，效果和成本可以有很好的平衡，即可作为一个需求，再排期到版本里进行开发，实现线上所有用户都能提交0元订单。
这个案例里，产品经理对当时产品开发资源、时间紧急度、替代方案的思考，就是对一个需求的方案初判的过程。对每一个需求都有这样的思考和判断过程，会更合理的对待需求和待解决的问题。
当然，在产品经理做了需求方案的初判之后，和需求方或者用户的沟通也是非常重要的。共同站在产品和公司的立场出发是跨部门沟通与合作的基础原则，沟通确认性价比最高的方案，让产品和功能以更敏捷的方式推向市场，试错迭代，快速优化。
2. 需求优先级
在通过需求的初判之后，会挡掉一些不合理或可以采取更轻的解决方案的需求，对于留下来的需求，需要记录进需求池。
在记录进需求池的时候，需要对需求的优先级进行排序标注，有两种常见的排序方法。一种是基于四象限法则，另一种则是基于KANO模型。
四象限法则
有些情况下，因为需求的来源和影响因素不同，在排期上总会不易协调。市场需要我们配合做活动，业务部门着急需要满足大客户的要求，开发需要留出做加固，运营部门需要解决用户投诉的体验问题，某个公司大领导提出的所谓高级紧急需求......所以有时产品经理抉择起来会很痛苦，需要综合权衡排期和利弊，考虑最合理并且能说服别人的理由。
最常用的判断方法是基于紧急重要四象限法则，如图所示：
我们可以按照上图，将对需求做一个排序，即：
1）重要并且紧急；
2）重要但不紧急；
3）不重要但紧急；
3）不重要但紧急；
判断需求是否重要的方法如下：
1）不做，会造成问题和负面影响，如影响公司整体战略发展、会影响公司的收入利润等、用户无法正常使用
2）做了，会产生正向的效应和影响，如用户体验变得更好
判断需求是否紧急的方法如下：
1）不做，错误会持续发生并造成严重影响、短期内可控但长期会有糟糕的影响
2）做了，立刻能解决很多问题、产生正面的影响、在一段时间后可以有良好的效果
KANO模型
KANO模型定义了三个层次的顾客需求：基本型需求、期望型需求和兴奋型需求。这三种需求根据绩效指标分类就是基本因素、绩效因素和激励因素。
基本型需求：顾客认为产品“必须有”的属性或功能。当其特性不充足时，顾客很不满意；当其特性充足时，对客户满意度没有多少影响，顾客充其量是满意。例如只要酒店浴室满足了我的基本需要，我并不会关心洗漱台的台面是用什么材料制作的。
期望型需求：要求提供的产品或服务比较优秀，但并不是“必须”的产品属性，有些期望型需求连顾客都不太清楚，但是是他们却希望得到 的。顾客通常谈论的是期望型需求，期望型需求又叫做线性需求，这类需求越多越好。线性需求在产品中实现的越多，顾客就越满意，当没有满意这些需求时，顾客 就不满意。因此，产品的价格通常和线性特性相关。如果酒店有健身器材，我会更加高兴，相比没有这类器材的酒店，我下次可能就会在此入住这里。
兴奋型需求：提供给顾客一些完全出乎意料的产品属性，使顾客产生惊喜。兴奋点和惊喜点常常是一些未被用户了解的需求，客户在看到这 些功能之前并不知道自己需要它们。当其特性不充足时，并且是无关紧要的特性，则顾客无所谓，当产品提供了这类需求中的服务时，顾客就会对产品非常满意，从 而提高顾客的忠诚度。这类需求可以为产品增加额外价格。
那么，如果评估需求类型呢
正常情况下，我们应该去做用户的问卷调查或者用户访谈，而实际中，我们没有那么时间和成本去完成这个事情，仅能靠经验判断或者相关用户做简单调研、模拟用户使用场景等方法来判断需求的优先级高低。
由图可以看出，
1）右下方箭头：一旦实现了一定数量的必须功能，就无法再通过增加这类功能来提高客户的满意度了。无论增加多少必须功能，客户满意度都不会超过中点以上。
2）左上方箭头：只是实现一部分兴奋点就可以明显的提升客户满意度，这也是为什么企业把追求卓越作为企业的价值观之一
3）中间的箭头：期望型功能的增加和客户满意度呈线性增长，所以这类需求越多越好
通过以上分析，我们会对这三类需求分别对待：
1）对于必须完成的功能，在产品发布时需要完成，但并不是要求在第一次迭代时就开发完成。
2）完成尽可能多的线性需求
3）如果时间允许，至少应该确定少量的兴奋点优先级，把它们包含进发布计划
总之，通过以上2个方法，均可以完成需求优先级的判断。优缺点，大家自行判断。
3. 需求来源和负责人
确认完需求的优先级之后，将需求记录进需求池。我个人在带领团队工作中，使用的需求池管理模版很简洁，如图所示：
通过以上表格，记录来自不同部门、不同人各种负责的需求来源，基本可以满足我们在日常工作中的所有工作需要。
其中，需求来源和需求负责人的记录是为了在出现人员变动或排期较长已经记不清的情况下，能够通过当时的需求负责人和需求来源的方式推演复现需求。
此外，需求负责人要对需求从提出到设计开发到上线数据分析的全过程负责，通过表格也能够一目了然每一项具体需求的责任人是谁。
4. 需求排期
我们这里所讨论的需求排期指的是还未进入设计和开发阶段的需求排入到具体开发版本的情况。
产品经理需要综合该产品线的全局需求优先级情况，对该需求进行版本排期，并根据版本排期推算大致的可上线时间范围。这么做的原因主要是：需求所涉及到的业务、运营、市场等部门，往往需要根据大致的可上线时间，做提前的安排和规划。尤其是连接线下业务的功能，需要线下提前部署准备好功能上线后的工作。
产品经理在确认需求的版本排期的时候也需要和涉及到的相关部门负责人员沟通，并在沟通后以以邮件的形式确认并通知（ps：这点很重要，不要最后了，其他人都不清楚，以为那个时间点就要上线了，而没有上线，那么背锅侠只能是你了）。
未完，待续....................
更多精彩分享，请添加群，若添加不了，则添加微信，备注（产品经理）
一个不安于现状、热爱户外、喜欢各种折腾的产品经理，欢迎志同道合的产品加入，让我们一起聊聊产品、聊聊创业、聊聊户外、聊聊各种。。。。。。。