解读kano模型的应用
kano模型对于知道的朋友来讲，很简单，对于不知道的朋友来讲很神秘，可不管是简单还是神秘，最终体现价值的地方，在于我们如何运用。
<small>作者：枯叶 这是我分享的第48篇原创文章，希望对你有所帮助。喜欢就关注我哦~</small>
<strong><big>kano模型的起源</big></strong>
<small>（本文内容，是我个人对kano模型的实际应用解读，并非标准解读，还请大家不要以绝对化的视角来看待，去探索属于自己的应用方式，是我所推荐的成长方法。）</small>
什么是kano模型？
简单来讲，kano模型是狩野纪昭教授发明的对用户需求分类和优先排序的一种工具，与产品经理的贴合度非常高，于是这样一个非产品行业的教授所发明的工具，成为了产品经理们的方法论。
具体的介绍，由于篇幅有限就不再赘述了，可以自行百度“kano模型”务必要输入完整的关键词，否则会出现“卡农”的搜素结果。
狩野纪昭（Noriaki Kano)是谁？1940年出生的老人家，日本教育家，作家，咨询顾问，1982年担任东京大学的教授，2006年退休。
是的，狩野纪昭和互联网，和产品经理没有什么关系。
我们再来看看什么Kano模型的诞生背景。
在20世纪70年代末80年代初，狩野纪昭和他的同事以客户满意度为模型设计了一种新的方法论，用于提高企业服务，这个方法论最终以他本人的名字命名，换言之Kano模型的正统名字是：<strong>狩野模式（Kano model）</strong>。
20世纪70年代末是什么时候呢？大概在1979年，80年代初也就是1981年，我们将范围扩大，Kano模型的实际诞生时期应该在1976年至1985年中间的某段时间。
在当时的背景下，互联网尚处于开荒阶段，还未抵达应用阶段（我国在1994年实现了与internet的全功能连接）。
这还是那个你所了解并依赖的“Kano模型”吗？
<strong>就是这样一个看似与互联网没有关联的狩野模式，现在成为了互联网产品经理的“圣经”。</strong>
<strong><big>Kano模型的定义</big></strong>
现在，你已经知道了，Kano模型并不是为互联网量身定做的，更不是为产品经理量身定做的方法论，那为什么不把他用在其他地方？
毕竟，这样才会让我们熟练的掌握这个方法，也只有熟练掌握，对Kano模型有更深刻的认识时，我们才能在互联网，在我们的产品里，更有效的去应用。
Kano模型里，将人们对某物的需求定义成了五个层次，包含：<strong>基本需求，期望需求，兴奋需求，无差异需求，反向需求</strong>。
所谓的兴奋需求，便是我们所谈及的“超出预期”这部分的需求。
来看一下每个层次的定义
<strong>基本需求：</strong>
也是基础性需求，理所当然的需求，也是用户认为“必须要有”的功能。
简单的来讲，如果“没有”，用户就会很不满意，如果“有”，用户也不会为此感到满意，毕竟，此类型需求属于“理所当然”的需求。
比如说，需求文档，对于产品经理而言，就是这样的基本需求，如果不会，那你的leader大概会对你极为不满，如果你会，他也不会为此表扬你。
<strong>期望需求：</strong>
此类型需求与基本需求相反，简单的来讲，就是这么一个意思，如果有，则用户会感到满意，如果没有，用户也不会感到失望。
比如说，需求管理，对于我们来讲，就是属于期望需求，作为产品经理而言，将我们的需求管理的越好，我们的leader会越满意，反之，即使你不会管理需求，他也不会对你有所不满，大概就是表现平平之类的吧。
<strong>兴奋需求：</strong>
兴奋需求某种含义上是期望需求的升级版本，有时候我们会提到的超越用户预期，以及挖掘表面需求背后隐藏的需求，便是指期望需求和兴奋需求的关系。
就以表面和背后来讲，期望需求是指用户表面的需求，兴奋需求则是指背后的真实需求。
我们仍然以需求文档来举例。
管理需求文档是我们表面的需求，通过对需求文档的管理，让团队效率更高，有更多的需求可被复用，以及需求尽可能少的变更，始终让团队的战斗力发挥有效价值，这个便是让leader兴奋的需求。
作为产品经理而言，需求反复，需求变更，遗漏需求，相信大家都不陌生，不仅仅是我们的leader，即便是对于我们自身而言，如果真的能减少反复，减少变更，同样也会让我们感到兴奋的，难道不是吗？
<strong>无差异需求：</strong>
无差异需求是指有没有都无所谓的这部分需求，不论提供或者不提供，对用户体验无影响，换言之，即使不做，也不会让客户不满意。
这部分需求，往往是我们要避免的“多余动作”，虽然是这样说，但在工作上，我们却极为容易做出这样的事情。
这个案例算是很经典了，“登录”与“登陆”当我们在文章里写到了“登陆”时，如果产生了情绪，这就代表我们在工作中，会经常性的为了无差异的事情耗费时间，毕竟，这样的错别字，并不会影响用户体验。
<small>（我需要强调，我们所谓的用户，是指使用某产品的人，以需求文档为例，他在开发过程中起到指引，排查的作用，而不是阅读一篇文章，因此文档里的错别字，在一定范围内是被允许且接受的。）</small>
避免无差异需求的原因在于，其会占用我们宝贵且不可再生的资源。
<strong>反向需求：</strong>
是指少数派需求，我们在做需求分析时，需要考虑需求的使用面积，并且在做优先级划分时，也需要按照影响面积来考虑，以满足大部分人的需求为首要目的，与这个原则相反的，便是反向需求，只满足少部分的需求。
反向需求同时也是无差异需求的升级版本，我们所谓的无差异需求，是做不做都没影响，反向需求恰恰就属于，做了就会产生负面影响。
比如，在需求评审时，我们在会议上讨论某文案内容，或者说某参数的设定，这种便是反向需求。
在我们的team里，大部分的成员其实不关心文案也无须关心文案，只有少部分成员会关心这个问题。
正确的处理方法是在评审会议里，讨论大部分人关心的议题，比如功能的业务逻辑，或者说为什么要做某功能。
对于一些少部分人关心的问题，类似于文案，可以在会议结束后，单独沟通。
以上五种需求类型，便是我所理解的Kano模型的五层需求。
我们以基础需求为原点，向正面挖掘，以期望需求或者兴奋需求为目标来要求自己，并且尽量规避反向需求，无差异需求的误区。
无差异需求虽然是做不做都没有影响，理论上，应该是以无差异需求为原点，而实际上，如果我们真的做了无差异需求，就表示会消耗我们的时间，并且这部分被消耗的时间得不到何种汇报，因此无差异需求被提出来时，本身就已经产生了负面影响了。
<strong><big>Kano模型对于产品经理</big></strong>
文章的开篇我已经告诉了大家，我们所熟知的Kano模型，并非互联网特有的一种方法论，实际上Kano模型的适用面积远远超过互联网和移动互联网的面积。
在我们讲述五层需求时，如果用某功能的案例，会让大家更容易理解，但这样却违背了我的初心，毕竟这篇文章的初衷是引导大家学习和成长方向，如果能促进大家的自省，那就太棒了。
用Kano模型来反思一下我们的工作吧。
基础需求：我们要输出需求文档
期望需求：我们要管理需求
兴奋需求：通过需求文档，提高团队开发效率，减少低效时间耗损
<strong>想一想，我们现在所写的需求文档，属于哪个层次？</strong>
无差异需求：写完需求文档后，反复检查三遍，确保没有错别字
反向需求：评审时，我们讨论提示文案应该怎么写
<strong>想一想，我们有多少时间耗费在了无差异需求和反向需求里?</strong>
最近似乎说了很多次差距产生的原因，即便是相同的开始时间，相同的结束时间，相同的经历，也可能产生极大的差距。
同样是一年产品时间，并且做的是相同的事情。
<strong>A不断的做兴奋需求，而B不断的做基础需求，不妨判断一下，谁的成长更快，谁能抓住下一个机会呢？</strong>
切忌满足于做基础需求，这样只会耽误你的时间而已，任何一件事情，都有基础需求和兴奋需求，只是兴奋需求会比基础需求更难挖据，更难发现。
这就像游戏里的难度挑战一样，简易，普通，困难，不同难度下，获得的经验和奖励也是不同的。
我尽量在每篇文章都带上一个功能的说明，这样大家在看文章的同时，也可以逐渐的积累一些功能认识。
刷新功能
我们将刷新功能视为功能模块，来看看刷新功能所包含的需求点有哪些？
1.刷新的触发条件（入口）
2.刷新成功
3.刷新成功-提示文案
4.刷新成功-没有新内容
5.刷新成功-没有新内容-提示文案
6.刷新失败-有缓存的时候
7.刷新失败-有缓存的时候-提示文案
8.刷新失败-无缓存的时候
9.刷新失败-无缓存的时候-提示文案
10.连续刷新时的保护：比如，2秒内刷新10次
11.连续刷新时的提示
12.刷新规则：比如最新的，或者随机的数据
13.刷新数量：比如刷新15条数据
如果大家发现我漏掉的需求，记得留言给我，我会补充上去哒
