Kano 模型(Kano Model)是产品管理和需求工程领域中一个极其经典的需求分类与质量属性分析模型,由日本质量管理学家狩野纪昭(Noriaki Kano)在1984年提出。
在你之前关注的“多利益相关者优先级博弈”和“效用聚合”语境下,Kano 模型提供了一个完全不同于“加权打分”的视角:它不是问“这个需求值多少分”,而是问 “这个需求的实现程度,如何非线性地影响用户的满意度”。
以下是它的核心精髓:
1. 核心分类:五大质量属性
Kano 模型将需求(或产品功能)分为五类,其中最重要的前三类构成了决策的铁三角:
| 类别 | 通俗定义 | 软件工程实例 | 满意度曲线特征 |
|---|---|---|---|
| ① 必备属性(Must-be Quality) | “理所当然”。做了用户不会更满意,但不做用户会极度愤怒,甚至直接弃用。 | App 闪退率必须低于 1%;支付流程必须保证资金安全。 | 指数衰减型(一旦缺失,满意度断崖下跌)。 |
| ② 期望属性(One-dimensional Quality) | “线性交易”。做得越好,用户越满意;做得越差,用户越抱怨。投入产出比是线性的。 | App 的启动加载速度、电池续航时间。 | 线性正比型(满意度随实现度均匀上升)。 |
| ③ 魅力属性(Attractive Quality) | “惊喜/ wow factor”。不做,用户不会不满(因为没期待过);但一旦做了,用户满意度会急剧飙升,产生口碑效应。 | 早期的 Apple FaceID 或语音助手 Siri;输入法自动纠错。 | 指数增长型(投入少量,满意度激增)。 |
| ④ 无差异属性(Indifferent) | 无论做不做,用户都无感(甚至没注意到)。 | 软件关于页面里极不显眼的图标风格微调。 | 水平直线。 |
| ⑤ 反向属性(Reverse) | 做了反而让用户讨厌。 | 强制推送广告通知、强制用户注册手机号。 | 负向线性。 |
2. 对你的“协同决策”场景的关键价值
结合你之前问的“百点分配法”和“加权效用最大化”,你会发现它们都有一个共同的致命缺陷:把所有需求都放在“线性”赛道上去比高低。
-
百点分配法的盲区:如果评审团里有高管,他可能给“AI 智能助手”(魅力属性)打高分,给“修复登录超时”(必备属性)打低分。但按 Kano 逻辑,必备用例(登录)若不达标,AI 功能做得再好,用户也会因无法登录而愤怒卸载。
-
Kano 的战术意义(先分类,再排序):
-
第一优先极:先拼命填满“必备属性”(达到及格线),这是生存底线。
-
第二优先:集中资源打造“魅力属性”,这是差异化竞争的关键,能让效用曲线指数跃升。
-
维持投入:常规维护“期望属性”(确保投入产出比不亏)。
-
果断砍掉:砍掉“无差异”和“反向”需求,节省资源。
-
3. 实操中如何得出分类(简便调查法)
通常通过设计一对 “正向(具备功能)” 与 “反向(不具备功能)” 的问卷题目来判定。
例如,问用户:
-
正向:如果这款笔记软件支持 AI 自动总结,你感觉如何?(A.很喜欢 B.理应如此 C.无所谓 D.勉强接受 E.很不喜欢)
-
反向:如果这款笔记软件不支持 AI 自动总结,你感觉如何?
根据用户对正反两题答案的交汇矩阵(Kano 评价表),即可定性该需求属于哪一类别。
4. 严格的数学逻辑缺陷(与 Pareto 的呼应)
Kano 模型在形式化上存在一个致命弱点:分类的颗粒度太粗,且极度依赖用户的主观文化背景。十年前“指纹解锁”是魅力属性,现在早已沦为基础必备属性(属性会随时间迁移)。
因此,它无法直接代入你之前提到的“最大化加权效用”数学公式(因为没有连续可微的数值),但它可以作为前置的“硬约束”——即在启动加权计分之前,先用 Kano 模型设置一道“门禁”:
-
如果某个需求被判定为“必备”且尚未达标,无论其在加权聚合中得分多低,都必须无条件拦截(违反生存底线)。
-
如果被判定为“无差异”,直接将其权重系数 wiwi 置零,从聚合公式中剔除。
一句话总结:Kano 模型是优先级决策的“方向盘”——它不告诉你油门踩多大(权重数值),但它告诉你该往哪个方向拐:保底线(必备)、追惊喜(魅力)、省油钱(砍无差异)。 它是主观量化打分之前,不可或缺的战略定性过滤器。
&spm=1001.2101.3001.5002&articleId=164205354&d=1&t=3&u=132871564c4744e689147617f4c87c29)
406

被折叠的 条评论
为什么被折叠?



