第1章：需求优先级排序——RICE模型、MoSCoW方法、Kano模型实战应用
做SaaS产品，最头疼的事是什么？
我猜是需求太多，资源太少。老板说这个要加，销售说那个客户等着用，客服说用户天天投诉。你手里就几个开发，怎么排？
说实话，我刚带产品那几年，也踩过不少坑。有一次硬着头皮把所有需求都塞进一个版本，结果开发累到离职，上线后用户根本不买账。从那以后，我学乖了——优先级排序不是拍脑袋，得有章法。
今天咱们就聊聊三种最实用的排序方法：RICE模型、MoSCoW方法、Kano模型。这三种工具，我几乎每个版本迭代都会用到。
1.1 RICE模型：用数据说话
RICE模型是我个人最常用的。它把需求拆成四个维度，每个维度打分，最后算出一个综合分数。谁分高谁先上，简单粗暴。
RICE四个字母分别代表：
- Reach（覆盖度）——这个功能会影响多少用户？
- Impact（影响力）——对单个用户的影响有多大？
- Confidence（信心指数）——你有多大把握判断准确？
- Effort（投入成本）——开发需要多少人天？
计算公式很简单：RICE Score = (Reach × Impact × Confidence) / Effort
举个例子。我之前负责一个CRM产品，销售团队要求加一个「批量导入客户」的功能。我们用RICE算了一下：
| 维度 | 评分标准 | 打分 |
|---|---|---|
| Reach | 每月使用用户数 | 2000人（8分） |
| Impact | 1-3分（轻微/中等/巨大） | 3分（巨大） |
| Confidence | 20%-100% | 80%（0.8） |
| Effort | 人天估算 | 15人天 |
算下来：(8 × 3 × 0.8) / 15 = 1.28
另一个需求是「优化搜索速度」，覆盖所有用户（10分），影响中等（2分），信心很高（90%），但需要30人天。得分：(10 × 2 × 0.9) / 30 = 0.6
你看，批量导入虽然只影响部分用户，但投入产出比更高，优先级自然靠前。
1.2 MoSCoW方法：必须做 vs 可以不做
RICE模型适合量化对比，但有时候你需要的不是分数，而是一个清晰的分类。这时候MoSCoW方法就派上用场了。
MoSCoW把需求分成四类：
- Must have（必须有）——没有这个功能，版本不能发。比如支付功能。
- Should have（应该有）——很重要，但可以等下一个版本。比如报表导出。
- Could have（可以有）——锦上添花，有最好，没有也行。
- Won't have（这次不做）——明确告诉团队和客户，这次不搞。
我记得有一次做SaaS后台的权限管理模块。销售说「角色继承」必须上，技术说「这个太复杂，至少两周」。我用MoSCoW一梳理：
- Must have：基本的增删改查权限、用户登录验证
- Should have：角色复制、批量授权
- Could have：角色继承、权限模板
- Won't have：自定义字段级别的权限控制
这么一分，团队立马清楚了。先把Must have搞定，Should have尽力而为，Could have和Won't have直接砍掉。版本按时上线，客户也没话说。
1.3 Kano模型：用户到底想要什么？
RICE和MoSCoW都是从商业和技术角度出发。但有时候，用户嘴上说的和心里想的根本不是一回事。这时候就需要Kano模型了。
Kano模型把需求分成五类：
- 基本型需求（Must-be）——用户觉得「理所当然」的功能。比如登录、注册、数据保存。不做用户会骂，做了用户没感觉。
- 期望型需求（One-dimensional）——用户明确说「我要这个」。比如搜索速度更快、界面更美观。做得越好，用户越满意。
- 兴奋型需求（Attractive）——用户没想到，但你做了他会很惊喜。比如一键生成周报、智能推荐客户。这类功能是差异化竞争的关键。
- 无差异型需求（Indifferent）——做不做用户都无所谓。比如换个主题颜色。
- 反向型需求（Reverse）——做了反而让用户不爽。比如强制弹窗广告。
怎么用？我一般会设计一份问卷，每个功能问两个问题：
- 「有这个功能，你感觉如何？」（满意/无所谓/不满意）
- 「没有这个功能，你感觉如何？」（满意/无所谓/不满意）
然后对照Kano评估表，就能判断出每个需求属于哪一类。
举个例子。我们做SaaS客服系统时，用户普遍要求「工单自动分配」。按Kano一测：
- 有自动分配：用户觉得「还行」
- 没有自动分配：用户觉得「很不方便」
这明显是基本型需求——必须做，但别指望靠它加分。
另一个需求是「智能回复建议」：
- 有：用户「很惊喜」
- 没有：用户「无所谓」
这就是兴奋型需求——投入产出比高，值得优先尝试。
1.4 避坑指南：我踩过的三个坑
讲了这么多方法，最后分享几个我亲身经历的教训。
坑一：过度依赖数据。有一次我们用RICE模型排了一版需求，结果上线后用户根本不买账。为什么？因为数据是拍出来的，不是真实数据。后来我养成了一个习惯：Confidence低于50%的需求，直接降级处理。
坑二：忽略技术债务。MoSCoW方法里，我经常把「重构代码」标成Won't have。结果呢？代码越来越烂，新功能越加越慢。现在我学乖了，每个版本至少留20%的精力处理技术债。
坑三：Kano模型用得太晚。我刚开始做产品时，都是功能做完了才去问用户满不满意。其实应该在需求评审阶段就用Kano模型做一轮调研。早发现、早调整，省得白费功夫。
好了，这一章的内容就到这里。优先级排序没有银弹，但有了RICE、MoSCoW和Kano这三把刷子，至少你不会再拍脑袋做决策了。下一章咱们聊聊如何把需求转化成可执行的产品路线图。