Kano模型：一种产品经理适用的方法论

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