---
title: "16.2 反馈分类与优先级"
description: "用 RICE 框架给反馈排优先级"
---
# 16.2 反馈分类与优先级
> 收集了一堆反馈后，如何判断先做哪个？影响范围和严重程度是两个关键维度。
---
## 20 条反馈，先做哪个？
小明的反馈渠道建起来了，一周内收到了 20 多条反馈：
- "登录的时候偶尔会崩溃"
- "能不能加个深色模式？"
- "导出功能什么时候有？"
- "首页颜色太丑了"
- "手机上按钮太小，点不到"
- "加载好慢啊"
- ……
每条看起来都有道理，但他不可能同时做 20 件事。老师傅说："先分类，再排序。"
---
## 第一步：分类
反馈五花八门，但归纳起来无非几种类型。Bug 报告是功能错误或异常，比如"登录按钮没反应"。功能请求是希望新增功能，比如"能否加入导出功能"。体验问题是使用不顺畅，比如"找不到设置在哪里"。性能问题是速度或卡顿，比如"页面加载太慢"。还有内容相关的，比如"这个词用错了"。剩下的归为其他。
分类的目的不是为了好看，而是为了下一步——判断优先级。Bug 和性能问题通常比功能请求更紧急，因为它们影响的是"能不能用"，而不是"好不好用"。
---
## 第二步：判断紧急程度
老师傅教小明用两个维度来判断优先级：影响范围（多少人受影响）和严重程度（问题有多严重）。
P0 是最紧急的——影响大量用户，系统不可用，比如登录功能失效，需要立即处理。P1 是高优先级——影响大量用户，核心功能受影响，比如支付失败，24 小时内要解决。P2 是中优先级——影响部分用户但有替代方案，比如某浏览器显示异常，本周内处理。P3 是低优先级——影响小，不影响使用，比如颜色不好看，有时间再说。
把这两个维度交叉起来，就形成了一个矩阵：
```
严重程度
高 │ [P0] 紧急修复 [P1] 高优先级
│
中 │ [P2] 中优先级
│
低 │ [P3] 低优先级
└──────────────────────────────
大 小
影响范围
```
小明把 20 条反馈往矩阵里一放，立刻清晰了。"登录崩溃"影响大、严重，是 P0；"颜色太丑"影响小、不严重，是 P3。光这一步就把 20 条反馈分成了四个层级，他知道该先做什么了。
---
## RICE：更精确的排序
矩阵能快速分出大类，但如果有好几个 P1 怎么办？老师傅教了小明一个更精确的方法——RICE 评分模型。
RICE 由四个维度组成。**Reach**（触达）是多少用户受影响，用每月用户数来衡量。**Impact**（影响）是对用户的影响程度，用 1-3 分来打。**Confidence**（信心）是你对这个评估有多大把握，用百分比表示。**Effort**（工作量）是需要多少时间和资源，用人月来算。
计算公式很简单：
```
RICE = (Reach × Impact × Confidence) / Effort
```
小明试着给三个功能打分：
| 功能 | Reach | Impact | Confidence | Effort | RICE |
|------|--------|--------|-----------|--------|------|
| 导出功能 | 100 | 3 | 80% | 2 | 120 |
| 深色模式 | 500 | 1 | 100% | 3 | 167 |
| 修复登录 Bug | 1000 | 3 | 100% | 1 | 3000 |
结果一目了然：修复登录 Bug 的 RICE 分数是深色模式的 18 倍。直觉可能觉得"500 人想要深色模式，应该先做"，但 RICE 告诉你，修复一个影响 1000 人的严重 Bug 远比满足 500 人的"想要"更重要。
::: tip RICE 的价值
RICE 不是为了精确计算，而是为了让你把假设和数据摆到台面上。当你纠结"先做哪个"时，把数字列出来，答案往往就清楚了。
:::
如果觉得 RICE 太重，还有一个简化版叫 ICE：Impact（影响，1-10 分）、Confidence（信心，1-10 分）、Ease（容易度，1-10 分），三者取平均。ICE 适合快速决策，RICE 适合需要更严谨评估的场景。
---
## 反馈管理流程
有了分类和优先级，小明建立了一个简单的反馈处理流程：
用 GitHub Issues 或 Notion 都能管理这个流程。关键不是工具，而是养成"收集→分类→排序→处理→反馈"的习惯。特别是最后一步"通知用户"——当你修复了用户报告的问题，告诉他们。这会让用户觉得被重视，下次还愿意给你反馈。
---
## 学会说"不"
小明最难学会的一课是拒绝。
有人说"能不能加个聊天功能"，有人说"能不能支持 Markdown"，有人说"能不能做个手机 App"。每个建议听起来都不错，但你的时间和精力是有限的。
核心功能优先于边缘功能，修复 Bug 优先于新功能，小投入大回报的事优先于大投入小回报的事，与产品方向一致的需求优先于偏离方向的需求。
当你需要拒绝时，不要冷冰冰地说"不做"。如果不是目标用户的需求，可以说"这不在当前计划内，但感谢建议"。如果与产品方向不符，可以说"我们的重点是 X，暂时不会做 Y"。如果只是资源有限，可以说"这个建议很好，已记录，会在后续考虑"。
说"不"不是忽视用户，而是对产品方向负责。你是产品的负责人，不是所有反馈都要采纳。老师傅说："好的产品不是功能最多的，而是最专注的。"
---
## 常见问题
### Q1: 所有反馈看起来都重要怎么办？
用 RICE 或 ICE 框架客观评分。把数字列出来，优先级自然就清晰了。感觉"都重要"往往是因为没有量化比较。
### Q2: 用户催促什么时候实现？
诚实回答。不要给承诺，但可以说"我们正在评估，会在后续版本中考虑"。给了承诺又做不到，比不承诺更伤害信任。
### Q3: 如何避免被用户牵着走？
保持产品愿景。用户反馈很重要，但你是产品负责人。收集反馈、分析数据、判断优先级，然后你来决定做不做。Henry Ford 说过："如果我问人们想要什么，他们会说一匹更快的马。"
---
小明学会了给反馈排优先级，但有些反馈太模糊了——"不好用"到底是哪里不好用？"体验差"差在哪里？
下一节，我们来学怎么真正理解用户。