用户研究与需求优先级：从访谈到 RICE/KANO
用三种用户研究方法听到真需求，再用 RICE/KANO/MoSCoW 把一堆需求排成能落地的 roadmap
- 会用 5 个用户访谈、小问卷、画像与旅程地图三种方法
- 掌握 RICE 打分公式、KANO 分类、MoSCoW 砍需求
- 理解怎么把一堆需求排成 roadmap
用户研究三招：听到真需求
用户说的和真正做的常常两回事，所以要交叉验证。
5 个用户访谈：别问“你要不要这个功能”，要问“上次你遇到这个问题时是怎么解决的”。听具体故事，不听表态。
小问卷：访谈出假设后，用小批量问卷去验证“是不是普遍现象”，量比访谈大。
用户画像与旅程地图：把典型用户是谁、从哪一步到哪一步、每步的情绪画出来，痛点自然浮出来。
用户访谈怎么问：别问引导性问题
访谈最大的坑是引导性提问。「你是不是觉得这个功能很好用？」——用户出于礼貌会说「还行」，你什么都没问出来。正确问法是开放式、问过去发生的具体行为：「上次你想导出数据的时候，最后是怎么弄的？当时卡在哪？」让人讲故事，不要让人选是或否。用户说「我需要XX」时，追问「你上次没XX的时候是怎么解决的」——那才是真需求。
引导性：「你会想用 AI 自动写周报吗？」（用户客气说会）好问题：「上次写周报你花了多久？中间最烦的是哪一步？」听行为故事，不听表态 yes/no。
需求优先级三件套
RICE = (Reach 触达人数 × Impact 影响大小 × Confidence 信心) / Effort 投入。四个数一乘一除，分高的先做。它把“凭感觉排需求”变成“按数字排需求”。
基本型：没有用户就骂（闪退、登录失败），必须先做。期望型：做得越好用户越满意（速度越快越好），线性提升。兴奋型：没有也行、有了惊喜（彩蛋、小动画），超预期。口诀：基本型=没有就骂，兴奋型=有了才爽；期望型=越多越好。
把需求分成 Must have（这版必须）、Should have（应该有）、Could have（有更好）、Won't have（这版不做）。版本永远塞不下所有需求，敢于明确写出“这版不做”才是成熟。
RICE 打分的局限
RICE 把排期变得「看起来很客观」，但要清醒：四个数全是拍的估算，不是精确测量。Reach 你拍脑袋、Impact 你主观给 0.5 还是 1、Effort 研发估的人月往往不准。两个需求分差 20% 以内，根本不算拉开差距，别纠结小数点后一位。RICE 是帮你对齐讨论的工具，不是算出真理的公式。
分差 < 20%：两个需求差不多，拍板别纠结Effort 由研发估，往往乐观，留缓冲RICE 排序后还要过 KANO：基本型需求分再低也得做。
需求池管理
所有进来的需求（老板提的、用户投诉的、运营想做的）先倒进一个池子里，别直接进 roadmap。每周过一遍池子：新需求补 RICE 分，已经过时的删掉，排上的标版本。这样老板临时塞需求时，你能拿出池子说「这个 RICE 分排第几、为什么这版做不了」，而不是每次都临时抢资源。
需求池里的每条需求最好带四个字段：来源（谁提的）、RICE 分、对应哪个用户故事、状态（待评估/已排期/已砍掉）。砍需求时别偷偷删，标成「Won't have」并写一句理由——三个月后有人再提，你不用重新争论一遍。池子不是垃圾桶，是决策的依据，定期清理才不会越堆越乱。
什么需求都接、从不砍：版本永远排不满真正重要的事只记需求不记理由：半年后忘了当初为什么砍老板一句话就改优先级：用 RICE 分和用户故事说话，别拍脑袋
怎么排成 roadmap
先用 KANO 判断哪些是不做会出事的底线，再用 RICE 给剩下的打分排序，最后用 MoSCoW 砍掉这版装不下的，剩下的就是 roadmap。排序的本质不是“哪个听上去最酷”，而是“单位投入换来最大用户价值”。
# 示例口径：给 5 个需求算 RICE 分并排序（教学数据）
# R: 触达人数(万) I: 影响(0.5/1/2) C: 信心(0.5/0.8/1.0) E: 投入(人月)
reqs = [
("修复模型乱码", 20, 1.0, 1.0, 1),
("新增主题皮肤", 10, 0.5, 0.8, 2),
("支持导出PDF", 15, 1.0, 1.0, 2),
("接入第三方账号", 5, 0.5, 0.5, 3),
("模型提速", 20, 2.0, 0.8, 4),
]
scored = sorted(
[(name, R * I * C / E) for name, R, I, C, E in reqs],
key=lambda x: x[1], reverse=True,
)
for name, s in scored:
print(f"{name}: RICE={s:.1f}")
# 预期输出（从高到低）：
# 修复模型乱码: RICE=20.0
# 模型提速: RICE=8.0
# 支持导出PDF: RICE=7.5
# 新增主题皮肤: RICE=2.0
# 接入第三方账号: RICE=0.4
# 结论：先做“修复乱码”这类高触达、低投入、高信心的事“App 打不开就闪退”被用户大量投诉。按 KANO 分类，它属于？
两个需求 RICE 分分别是 12.3 和 11.8，差 4%，正确做法是？
资深工程师加餐
底层原理 · 大厂视角 · 工程经验，点卡片展开
不必追求一步到位的全自动。更可靠的形态是「AI 出草稿、人一键确认/修改」，按置信度路由（低置信转人工），给出信息来源、提供便捷纠错并把纠正回流成训练/评测数据。让用户始终有掌控感，真实的「采纳率/完成率」比 demo 看起来多智能重要得多。