需求管理的两个维度：需求来源管理和需求实现管理

                                                西部数码（west.cn）10月17日讯：产品经理在平时的工作中有一大部分工作都是在“为客人点菜”——需求管理。

一个流传较广的段子，形象地描述了产品经理的角色：
你去饭店，坐下来。
你：服务员，给我来份宫保鸡丁！
服务员：好嘞！
【这叫原始需求。】

大厨做到一半。
你：服务员，菜里不要放肉。
服务员：不放肉怎么做啊？
你：不放肉就行了，其它按正常程序做，不就行了，难吗？
服务员：好的，您稍等。
【这叫中途需求变更。】

大厨：你大爷，我肉都回锅了。
服务员：顾客非要要求的嘛，你把肉挑出来不就行了吗？
大厨：行，你大爷~
然而还是一点点挑出来了。
【改动太大，部分重构。】

你：服务员，菜里能给我加点腐竹吗？
服务员：行，这个应该简单。
【低估改动成本】

大厨：不知道腐竹得提前泡水？炒到一半才说？跟他说，想吃腐竹就多等半天。
服务员：啊，你怎么不早说？
大厨：我怎么知道他要往宫保鸡丁里放腐竹。
然而还是去泡腐竹了。
【新需求引入了新研发成本】

你：服务员，菜里加茄丁了没有？我去其它饭店吃可都是有茄丁的。
服务员：好好好，您稍等，您稍等……
【奇葩需求】

大厨：宫保鸡丁里放茄丁？？
服务员：茄丁抄好了扔里边不就行了吗”
大厨：那TM还能叫菜吗？哪个系的？
服务员：客户要，你就给炒了吧。
大厨：你顺道问问他腐竹还要不要，我这盆腐竹还占着地方呢！不要我就扔了。
【奇葩需求也得实现】

10分钟后
你：咦，我上次吃的不是这个味啊？
从厨房杀出来的大厨：我*****
【最终决战】


以上的人物：

你 = 客户

服务员 = 客户经理 + 产品经理

大厨 = 码农


产品经理在平时的工作中有一大部分工作都是在“为客人点菜”——需求管理。
为了避免发生上述的灾难性案例，作为一个合格的产品经理，需要分析客户需求并根据团队的能力给出恰当的产品解决方案。这就需要产品经理做好需求的管理。
需求管理分为两个方面：需求从哪里来，需求到哪里去了。
[ol]

需求的来源管理：如何挖掘需求，哪些需求值得去做，需求有哪些分类

需求的实现管理：mvp内容如何规划，如何做好优先级排期，临时需求怎么处理等
[/ol]
需求的来源管理
在上述案例中，原始需求就有很大的问题，原始需求直接作为开发需求来做，必然会导致项目失败。
合格的产品经理对话应该是这样的：
你去饭店，坐下来。
你：服务员，给我来份宫保鸡丁！
服务员：好的，请问有什么忌口吗？

你：有，最近在减肥，不要放肉。
服务员：这宫保鸡丁不放肉的话可就不是宫保鸡丁了。

你：但我喜欢吃宫保鸡丁，所以请你们给我炒一道没有肉的宫保鸡丁。
服务员：你看这样行不行，我们可以用茄丁来代替鸡丁，味道差别不大，并且更健康。

你：这样也行。
服务员：还有其他想吃的吗？

你：我还喜欢吃腐竹。
服务员：好的，我们这有凉拌腐竹，上菜速度快，可以先给您先上一份。

你：好，那快点上菜吧。


可以看到，分析清楚客户的真实需求，再进入开发阶段，客户吃到了腐竹，茄丁，和宫保鸡丁的味道，厨房也能正常的干活，是个双赢的结果。
1、马斯洛需求理论
任何一个产品需求都是基于人类本身的诉求产生的，回答需求从哪里来的问题，不得不提到马斯洛需求理论。
马斯洛于1943年在《人类动机的理论》论文中将需求分为五类（引自维基百科）：

生理上的需求：级别最低、最急迫的需要，如：食物、水、空气

安全上的需求：低级别的需要  如：对人身安全、生活稳定以及免遭痛苦、威胁、拥有财产等

情感和归属的需求：社交需求，对友谊、爱情以及隶属关系的需求

尊重的需求：较高层次的需要，如：成就、名声、地位和晋升机会

自我实现的需求：最高层次的需要，初级表现形式是认知和审美的需求 如：自我实现，发挥潜能

五类需求是以层次的形式出现的，由低级的需要开始，逐级向上发展到高级层次的需要。当低层次需求得不到满足时，高层次需求也会处于不稳定的状态，比如食物缺乏时，会不顾一切手段抢夺食物。

（图片来源：维基百科）
一般而言，越是底层的需求，用户量越大，比如满足生理需求的美食类app，外卖app, 滴滴打车。越是高层的需求，新鲜感越多。比如满足归属感的社交app，自我实现需求的音乐类App等。当然在互联网时代，需求的分类界限也越来越模糊，wifi万能钥匙可以说满足了多数人基础的生理需求。
回到上面的案例，满足生理需求是给一碗饭，满足安全需求是保证食品安全，满足归属需求是老客户8折，满足尊重需求是尽力满足没有肉还能吃出宫保鸡丁的味道。自我实现的需求？对不起，饭店这个产品难以满足，想做出一个优秀的产品，一定是深谙人性，需要区分清楚人类表面需求及潜在需求，并且能够持续稳定的产生用户粘性。
2、需求的来源
一个产品需求，必然是满足人性的某一个诉求才值得去做，也就是产品必须有价值才有存在的意义。
获得有价值的需求来源，也可以大致分为两类：
外部来源
前期对用户的研究，调查问卷，访谈发现新的产品需求。来饭店吃饭，肯定是饿了，需求是填饱肚子，这里的用户问卷就是问你要吃什么。
用户反馈的收集，提取和优化策略。用户说菜太咸，上菜太慢，提前做好备菜。
对竞品的跟踪分析，行业分析等等。 隔壁家开发出不要肉的宫保鸡丁，派人学习一下。
内部来源
老板的需求，一个公司的内部或多或少都会有来自上级的需求，靠谱的老板掌握的资源和市场信息能够做出正确的判断，决定产品的方向。比如老板觉得中餐太麻烦竞争激烈，我们需要开发标准化的西餐，做蛋糕。
数据分析产生的需求，根据前期数据埋点获得数据做产品的优化。大部分客户都喜欢吃宫保茄丁，菜单上就增加一个宫保茄丁。
业务部门需求。简单的比如需要市场部门需要更换品牌，改个图标。收银台发现宫保茄丁利润率更高，我们要主推宫保茄丁。
技术部门的需求，某个方案现有技术来实现比较复杂，需要更改需求。大厨发现茄子切丁太费事，改成宫保茄条。
3、用户需要的并不全是产品需求，用户的动机才是需求的本质
任何一个需求来源的用户提出的需求都可能是伪需求，讨论需求来源时我们直接默认了需求是合理的并且真实的。
举个例子：宫保鸡丁这个菜本来就是要肉的，如果要吃茄子，就是另外一道菜了。
区别伪需求和表面需求
关于伪需求被引用最多的一个例子，便是福特汽车创始人说的一句话：
如果听用户的，我们根本造不出汽车来，用户就是需要一匹快马。

用户基于自己的环境和使用习惯很难跳出原有的思维方式，当用户直接提出解决方案的时候，往往意味着诞生了又一个“伪需求”。因为他们所指的方向并不一定能到他们所想去的地方。还有一类需求，用户会用某种行为来代替真实的需求，比如开房去学习，如果把宾馆都改成自习室，也就没有人去学习了。再比如用户说需要一个锥子和钉子，其实他只是要把画挂起来。
问个问题
去伪存真的一个简单方法就是问个问题，你是谁？你想做什么？需要达成目的？即一个需求的用户角色定义是什么，基于什么样的用户场景，能够带来什么样的价值。
一个饿了的客户，只想吃饱肚子，给他一份宫保鸡丁满足需求。另外一个特别喜欢吃宫保鸡丁的客户，最近在减肥，处理的方法就完全不一样了。再有上面的福特汽车例子，如果客户是个赛马选手，他当然是需要更快的马。如果是个普通用户想更快更安全的到达另外一个地方，汽车是个很好的解决方案。
实际上，这个问法也是scrum团队中用户故事的写法，作为一个角色，我想要活动,，以便于商业价值，基于这些分析出场景中用户的动机，然后转换为产品语言，接下来就是需求的实现过程了。
需要的实现管理
我们已经了解到了客户的需求：客户想吃腐竹，带茄丁不带肉的宫保鸡丁，那么如何操作，先做哪个？
理论先行。
1、KANO模型分析法
需求的优先级首先应该根据需求对用户的价值来判断。
日本教授狩野纪昭在1984年提出构了KANO模型，用来对客户需求的满意度进行分类，一共分为五类影响因素（引自维基百科）：

必备因素：满足基础需求时，用户才会使用产品，不会对用户满意度产生影响。当不提供此需求，用户满意度会大幅降低；

期望因素（线性因素）：KANO模型是从线性需求模型演变而来，线性需求在产品中实现的越多，用户就越满意，当不提供此需求，用户满意度会降低；

兴奋因素：用户意想不到的，如果不提供此需求，用户满意度不会降低，但当提供此需求，用户满意度会有很大提升；

无差异因素：无论提供或不提供此需求，用户根本不在意；

反向因素：用户根本都没有此需求，提供后用户满意度反而会下降。

毫无疑问，产品经理应该避免去实现无差异因素和反向因素。
有两个反向因素的例子，豆瓣把自己的消息系统的名字由豆邮改成私信，仅仅是改个名字，结果遭到豆瓣用户集体反对，不得不重新改回来。支付宝的六一运营活动，也是改名字，给大家的名字后面都加了个宝宝，不少在意安全的用户，也把矛头指向了产品经理。这些站在用户对面的反向需求，用户必然会不满意。
无差异因素则更加悲凉，这种需求很少出现，你费力做出个功能，结果用户一点感知都没有，某种意义上来说，比反向因素更加不值得浪费资源去做。

（需求进展和用户满意度的关系图，来源：维基百科）
可以看到其中的三条曲线basic needs（基本型需求），performance needs（期望型需求），Delighters（兴奋型需求）的实现过程。

基本型需求：产品的基本需求往往属于此类。对于这类需求，必须满足，可以做的按部就班，少量创新。

期望型需求：用户、竞争对手和产品自身都需要关注的需求，平时工作中需要重点关注的需求。

兴奋型需求：用户自身都没有想到的需求，满足此类需求很容易引起产品的爆点。之前的脸萌，朋友印象都是满足这种兴奋型需求。

做一份宫保鸡丁属于基本需求，想吃到腐竹是期望需求。而兴奋型需求，则是类似海底捞的做法；等待的过程中给你提供刷鞋，美甲等更多的服务，给用户带来惊喜。

实现优先级上，首先满足基本需求，其次是期望型需求，然后根据产品的生命周期和市场情况，调整兴奋型需求的优先级。
比如，在产品成长期，可以恰当做些爆点需求，增加曝光度，来快速拉升产品注册人数。
2、分段交付产品功能，MVP实现核心需求
MVP最小可行产品
互联网迭代越来越快，爆发出来的很多需求需要快速验证，这个时候做一个快速的可行性产品是成本最低的试错方法。

一般来说，MVP产品可以从以下几个纬度确定功能范围：
[ol]

用户纬度：MVP集中满足核心用户/种子用户的需求；

功能纬度：找出最核心、与痛点最相关、最小的功能组合。减少需求永远比增加需求更难。这里可以用反向分析法，如果去掉某个功能，会不会影响主体流程。某个需求如果上不了线，用户会不会流失，如果回答是会，则放入mvp中实现，如果不会大胆的放到后续的迭代中做；

产品原型：现在更多的产品会通过微信公众号的形式验证，比如知乎的付费问答值乎，最开始的mvp产品形态主要是知乎服务号的自定义菜单或者朋友圈的分享，如果一开始就放在App端，如果用户没有来得及更新，就错失了市场机会（同一时间，分答已经在市场上跑马圈地了）。
[/ol]
现在，很多的硬件创业团队mvp做法则是设计好了方案，到众筹网站进行展示，收集产品反馈，获得早期用户，快速判断产品是否符合市场需要。
按照产品需求的优先级分段交付：
现在的互联网产品思维都要求快速迭代，并不像传统的软件产品，需要所有功能完备才能推向市场。
分段交付可以理解为后续每一个迭代都是一个mvp，只不过跟从0启动的产品mvp判断标准不同，按照需求优先级来定义每一次分段交付的内容。

分段交付的优点有很多，也是scrum开发模式推荐的做法：

新功能能够快速发布；

能够迅速应对业务需求，拥抱变化；

迭代周期缩短，同时获得迅速反馈；

从需求分析开始交互 设计 开发 测试等角色密切协作，相比于传统的瀑布式开发，效率跟高，更少浪费。

评估产品优先级除了上面提到的用户价值模型还可以从一下几个方面评估：

需求价值：用户价值即上面KANO模型评估结果，基本需求优先做，期望型需求尽量做，兴奋型需求要有一两个，作为产品亮点和差异化竞争策略需要。商业价值，是否对公司有利；

需求主体：是哪一类用户的需求，是否是核心用户，新用户，还是留存用户。受众面是不是足够大；

需求成本：需求实现的需要投入的技术资源和时间资源，以及是否依赖内部外部的一些资源；

需求强度：用户对该需求有多强烈，需求的频率如何。

假设我们仍然接受了客户的需求，不考虑商业价值亏损的情况下，需要做一份加腐竹的宫保鸡丁，满足的只是个别用户的单次需求。而且实现成本又很高，所以这个需求从优先级上是非常低的。所以，不如先上个凉拌腐竹，再做个宫保茄丁。
来源链接：http://www.woshipm.com/pmd/425637.html