1.3 需求优先级 (MoSCoW / Kano)

一句话

优先级不是 “哪条更重要” 的投票，而是固定产能下的排队规则：先判断这条需求不做会死成什么样，再算它值多少钱，最后按 “单位产能的收益” 排序；MoSCoW 管底线（这次发布缺了就作废），Kano 管满意度（做了涨多少、不做掉多少）。

三个必须先破的误区

误区	现实
都很重要，所以全是 P0	产能固定时，优先级是排序不是标记；全是 P0 等于没排，实际执行顺序退化成 “谁先催”
优先级由老板 / 客户的声音大小决定	决策权可以给老板，排序依据不能；没有依据的优先级，每次开会都会翻案
MoSCoW 就是 P0–P3 换个说法	MoSCoW 的 Must 有硬定义：缺了这次发布就整体作废；“很重要” 不等于 Must

🔑 优先级排序的真正产出不是 “先做哪个”，而是 “显式放弃哪个”。没有放弃清单的排序，等于把 150 点的需求池硬塞进 45 点的产能。

MoSCoW：四档的定义比档位名重要

档位	判据（满足才算）	常见误用
Must	缺了它，本次发布整体作废：不合规、会资损、核心流程走不通	“这个功能老板很关注” → 应该降 Should
Should	痛，但它有可接受的人工绕过，且绕过成本可量化	绕过要每天 3 小时人工 → 其实已经是 Must
Could	有更好，没有不影响上线与验收	把 “未来可能要做” 全塞进 Could，池子膨胀
Won't	这一次明确不做，并写清什么条件下复议	不记录直接删掉 → 半年后同一条需求重提一遍

Must 要落到三问，三问都答 “否 / 很低” 的，不可能是 Must：

不做会违法、违反合同、或直接资损吗？
有绕过吗？绕过的单位成本 × 频次是多少？（例：每单人工补录 2 分钟 × 3000 单/天 = 100 人时/天，等于不可绕过）
晚一个迭代做，损失是多少钱？换算方法见 4.1 技术投入的收益模型。

Must 超过 60%，就是定义错了

DSDM 方法论给的经验上限是 Must 类不超过总工作量的 60%（按工作量算，不按需求条数算）。理由可推导：一个迭代的估算误差通常在 ±30%–50%，Must 占到 90% 时，任何一条估偏都会把发布日期冲掉。

Must 占比	含义	后果
≤ 50%	有余量吸收估算误差	发布日可信
60%	上限	一旦有变更就要砍 Should
80%	把 Should 改名叫 Must	每个迭代都延期，且每次都归因于 “需求变更”
100%	没有优先级	排期 = 把需求池抄进甘特图

⚠️ Must 与 Should 的分界线不是 “多想要”，而是 “没有它这次发布能不能验收”。用 “重要性” 划线，Must 一定会膨胀到 80% 以上。

同时别忘了 NFR 之间天然会互相打架（性能 ↔ 安全、可用性 ↔ 成本）：冲突时的优先顺序必须在需求阶段写成一句话，写法见 1.1 功能性需求与非功能性需求。

Kano：把 “满意度” 拆成五种需求

类型	提供时	不提供时	例子	商业含义
必备型 Must-be	无感（理所当然）	愤怒、投诉	支付成功钱要扣对	缺失即出局，做好不加分
期望型 Performance	越好越满意（线性）	越差越不满	外卖配送时长	竞争主战场，靠投入换分
兴奋型 Attractive	惊喜、口碑	无感	首个 “次日达”	差异化窗口，迟早被抄成标配
无差异 Indifferent	无感	无感	首页换配色	投入不产生满意度
反向 Reverse	越做越不满	—	强制看 30 秒广告	做了是负收益，应主动移除

需求会沿 “兴奋 → 期望 → 必备” 迁移

阶段	免密支付	竞争含义	投入策略
2020 年	兴奋型：惊喜	抢增量	快，允许不完美
2022 年	期望型：比谁更快	拼效率	持续优化
2024 年	必备型：不支持就被投诉	保底线	只求不出错，别再加投入

这条迁移规律的实际用法：同一条需求隔一段时间要重新做一次 Kano 分类。按两年前的结论排今天的优先级，会把 “必备型” 当 “兴奋型” 投入，白花钱还挨骂。我的判断是多数 To C 品类在 18–36 个月内完成一次迁移，被抄得越快的品类迁移越快。

怎么测：正反问句 + 五级量表 + 评价表

每道题问两遍——提供时、不提供时：

功能性问题：如果系统提供 X，你的感受是？
非功能性问题：如果系统不提供 X，你的感受是？
选项固定五档：我喜欢 / 理应如此 / 无所谓 / 能忍受 / 我不喜欢。

评价表（行 = 功能性问题答案，列 = 非功能性问题答案）：

功能 ↓ / 非功能 →	喜欢	理应如此	无所谓	能忍受	不喜欢
喜欢	Q	A	A	A	O
理应如此	R	I	I	I	M
无所谓	R	I	I	I	M
能忍受	R	I	I	I	M
不喜欢	R	R	R	R	Q

A = 兴奋型，O = 期望型，M = 必备型，I = 无差异，R = 反向，Q = 矛盾答案（该样本作废，说明题目有歧义）。

Better / Worse 系数：把分类压成两个可比的数

Berger 等在 1993 年给出的两个系数，把 A / O / M / I 的比例压成两个数：

Better = (A + O) / (A + O + M + I)     # 提供后的满意度提升，∈ [0, 1]
Worse  = -(O + M) / (A + O + M + I)    # 不提供时的满意度下降，∈ [-1, 0]

结果	解读	优先级含义
Better 高、Worse 低	兴奋型	窗口短就 Should，窗口长就 Could
Better 高、Worse 高	期望型	竞争主战场，按 ROI 排
Better 低、Worse 高	必备型	必须做，但不必做到极致
两者都低	无差异	Won't，且不必再调研

两个使用前提：

必须分人群统计。同一个 “导出 Excel”，财务专员是必备型，运营是兴奋型；混在一起算，两类结论会互相抵消。
问卷只覆盖现有用户。新用户与流失用户对 “必备型” 的判断往往不同，样本偏差要在结论里写明一句。

从 Kano 到 MoSCoW：映射表

Kano 类型	现状	落到 MoSCoW	理由
必备型	现有系统缺失	Must	缺失即合规 / 资损 / 流程断
期望型	竞品已达到	Should	不追会丢单，但不至于作废发布
期望型	竞品也一般	Could	投进去换来的分差不值
兴奋型	差异化窗口 ≤ 2 个季度	Should	窗口过期就白做
兴奋型	窗口 > 2 个季度	Could	先小成本验证，再决定投入
无差异	—	Won't	投入不产生任何满意度
反向	现状已存在	Won't + 排期移除	负收益，越早删越好

🔑 Kano 回答 “值不值得做”，MoSCoW 回答 “这次做不做”。前者与时间无关，后者与迭代绑定——把 Kano 结论直接当排期，是把长期地图当短期时刻表用。

需要横向比较时：把 “重要” 换成可算的数

方法	公式	输入	适合	失效点
RICE	(Reach × Impact × Confidence) / Effort	影响人数、影响强度、置信度、工作量	需求池大、量级差异明显	Impact 与 Confidence 都是主观分，容易 “先想要的结果再打分”
WSJF	Cost of Delay / Job Size	业务价值 + 时间敏感性 + 风险降低，除以工作量	有明确发布窗口、延迟有成本	工作量估不准时，排序变成 “谁估得小谁先做”
成本-收益	(收益 − 成本) / 成本，或直接折现	可折算成钱的收益与成本	基础设施 / 平台类投入	收益难折现时（体验、品牌）会系统性低估
MoSCoW	定性分档	底线判断	迭代内排期	不做横向比较，同档内无顺序

RICE 的算例（三个不同形态的需求）：

需求	Reach（人/季）	Impact	Confidence	Effort（人日）	RICE
A 一键复购	120,000	1（中）	0.8	20	4,800
B 发票自助开具	30,000	3（巨大）	1.0	15	6,000
C 首页皮肤	500,000	0.25（极小）	0.5	10	6,250

C 排第一，这就是 RICE 最典型的失效：Reach 极大、Impact 极小的需求会靠乘法赢。两种修法：给 Impact 设下限（< 0.5 不进池），或改用 WSJF 把 “时间敏感性” 显式拉出来当分子。

⚠️ 算出来的第 1 名与第 2 名差距小于 20% 时，算术已经不构成理由。这时排序依据应该是 “哪个先做能让后一个更便宜”（依赖关系），或 “哪个不做会被追责”（可解释性）。把这句话写进决策记录，比多算一位小数有用。

优先级必须和产能一起看：交付周期 = WIP / 吞吐

优先级只管 “做哪个”，WIP 管 “同时做几个”。两者不管其一，优先级都没有约束力。利特尔法则直接给出可推导的结论：交付周期 W = 在制品数 L / 吞吐率 λ（推导与排队论前提见 34.2 性能建模）。

团队吞吐 λ	并行需求数 L	平均交付周期 W	结论
3 条/周	3	1 周	排进去就能较快交付
3 条/周	9	3 周	排进去 3 周后才见结果
3 条/周	15	5 周	优先级已经失效，所有需求都 “在做”

一个 6 人团队、每 2 周交付 30 点、需求池 150 点：3 个迭代（6 周）内能承诺的上限是 90 点，第 91 点之后全是排队。把 120 点标成 “高优先级”，只是让 120 点一起卡在队列里。

🔑 优先级排的是 “顺序”，产能定的是 “深度”。深度不够时，再严格的顺序也只保证 “大家一起晚”。

估算的前提是需求小到能估——一个带验收标准的故事才估得准，拆法见 1.2 用户故事与用例。

Won't 清单：放弃也要写触发条件

Won't 不写，等于半年后重来一遍。每条 Won't 至少带一个复议触发条件：

需求	这次不做	复议触发条件
多币种结算	只支持人民币	出现首个境外签约客户，或合规要求变化
移动端 SDK	只做 H5	移动端订单占比 > 30%（当前 12%）
自建风控引擎	先用第三方	风控调用费 > 自研年成本，或规则数 > 200 条

触发条件的作用是把 “争论” 变成 “监控”：条件没到就没人再问，条件到了就自动进池，不必重新吵一轮。这些条件同时是变更单的输入之一，见 1.4 需求变更管理。

把 Must / Should 按波次排进季度节奏，是路线图要做的事，见 58.4 演进路线图；排完之后每条 Must 还要落到可验收的指标，见 1.5 需求到技术的翻译。

反模式

反模式	后果
全 P0 / 全 Must	排序失效，实际顺序由催得最凶的人决定
按 “客户级别” 排优先级	大客户的小需求挤掉小客户的核心流程，整体满意度下降
只排顺序，不定产能	所有需求都 “已排期”，实际全在排队
Kano 问卷不分人群	必备型与兴奋型混在一起，两类结论互相抵消
用 RICE 给整个需求池做总排序后直接执行	Reach 大的低价值需求靠乘法插队
优先级只存在需求系统里，不进迭代计划	开发按 “谁来找我” 排期
Won't 不记录、不复核	半年后同一条需求重走一遍完整评审
优先级与架构约束脱钩	排进一条当前架构做不动的需求，做到一半才发现要重构
兴奋型需求当必备型投入	窗口期已过还在打磨，投入不产生差异化

三条铁律

🔑 Must 的定义是 “缺了这次发布就作废”，不是 “最重要”。 Must 超过 60% 的工作量，先把 Should 改回去。

🔑 优先级必须有放弃清单和复议触发条件，否则它不是排序，是一次情绪表达。

🔑 优先级是 “单位产能的收益”，不是 “重要程度”。 产能不写清，任何排序都无法执行。

自检

Q1 客户说 “这三条都是 Must，一条都不能少”。你先要哪两样东西，才能把其中至少一条降下来？

▸ 答案：① 这次发布的验收标准——拿三条逐一对照 “缺了它验收能不能过”（合规 / 资损 / 主流程），缺了不影响验收且有绕过的，降 Should；② 三条各自的工作量对照迭代产能。有了这两样，“Must” 就从态度变成判定；真正要谈的只剩 “砍范围还是改日期”，而不是 “哪个更重要”。

Q2 Kano 问卷显示 “批量导入” 是兴奋型，Better = 0.72、Worse = −0.15，但竞品 6 个月前已上线同样功能。它还是 Should 吗？

▸ 答案：仍是 Should，但理由变了。Better 高 / Worse 低的形状确实是兴奋型，可竞品已上线 6 个月意味着差异化窗口正在关闭，用户体验一次后会把它归入 “应该有”。此时按 “期望型 + 竞品已达标” 一档排序，并把投入上限定在追平（不低于竞品即可），不追求更好。Kano 分类随时间迁移，问卷结论必须标采集时间。

Q3 一个迭代的 Must 类需求占 85%，怎么用算术向业务方说明危险？

▸ 答案：Must 占 85%、估算误差 ±30%，最坏情况 Must 自身就要 85% × 1.3 ≈ 110% 的产能，发布日必然被冲掉，而冲掉的原因会被记到 “需求变更” 上，掩盖真正病根。修法不是 “加快开发”，只有缩小范围能真正缩小工作量：把已失去理由的 Should 降到 Won't，或把本次发布范围砍一刀。

Q4 团队 8 人，吞吐 4 条需求/周，在制品 12 条。老板问 “我上周加的那条为什么还没上线”？

▸ 答案：用 W = L / λ：WIP = 12、吞吐 = 4，平均交付周期 3 周，所以 “上周加的高优先级” 要等约 3 周，不是 1 周。想让优先级立刻生效只有两条路：把 WIP 降到 4（周期压到 1 周），或从当前在制品里真正撤下一条。只改优先级标签不会让队列变短。

Q5 为什么说 “优先级排序的产出是放弃清单”？

▸ 答案：产能固定，任何 “加进来” 必然对应一次 “挤出去”。如果排序只产出顺序、不产出被挤掉的是哪一条，被挤掉的会以 偷偷延期 的形式发生在执行层——看起来每条都在做，实际每条都没做完，且没人能说清牺牲了哪条。写出 Won't 与 “本次挤掉 X”，是为了让取舍可追溯、可复盘、可复议。