名称：优先排序方法 描述：“需求优先排序技术，包括 MoSCoW、Kano 模型、WSJF（SAFe）和 Wiegers 的价值/成本/风险矩阵。提供评分框架、权衡分析和优先可视化。当根据业务价值、客户影响或实施效率来排名需求时使用。” 允许工具：读取、写入、全局、grep、任务
需求优先排序方法
需求与功能优先排序技术的综合指南。
何时使用此技能
关键词： 优先排序，优先级，MoSCoW，Kano 模型，WSJF，加权最短作业优先，价值成本风险，Wiegers，优先级矩阵，必须有应该可以有，惊喜功能，基本需求，性能功能，延迟成本
在以下情况使用此技能：
- 根据业务价值排名需求
- 在竞争功能之间选择
- 分配有限开发能力
- 向利益相关者传达优先级决策
- 平衡客户满意度与实施努力
- 在产品规划中进行权衡决策
优先排序方法概述
| 方法 | 最适用于 | 复杂性 | 利益相关者输入 |
|---|---|---|---|
| MoSCoW | 快速分类，MVP 范围 | 低 | 低 |
| Kano 模型 | 客户满意度分析 | 中等 | 高（调查） |
| WSJF | 敏捷/SAFe 环境，流优化 | 中等 | 中等 |
| Wiegers 矩阵 | 定量价值/成本分析 | 高 | 中等 |
| 机会评分 | 与 JTBD 对齐的优先排序 | 中等 | 高（调查） |
MoSCoW 方法
类别
moscow:
must:
definition: "本版本中不可协商的"
criteria:
- "系统没有它将无法工作"
- "法律/法规要求"
- "核心价值主张"
typical_percentage: "努力占比 60%"
should:
definition: "重要但不关键"
criteria:
- "有显著价值，但存在替代方案"
- "关键利益相关者的期望"
- "竞争对等性"
typical_percentage: "努力占比 20%"
could:
definition: "如果有时间，拥有会很好"
criteria:
- "增强用户体验"
- "低努力，增量价值"
- "差异化但不必要"
typical_percentage: "努力占比 20%"
wont:
definition: "明确不在当前范围内"
criteria:
- "同意延期，不是拒绝"
- "未来考虑"
- "资源限制"
note: "记录以供未来参考"
应用
moscow_process:
1. 列出所有需求
2. 从 MUST 开始 - 要严格（如果所有都是 MUST，那没有一个是）
3. 移动到 WON'T - 明确排除
4. 在 SHOULD 和 COULD 之间分配剩余
5. 验证：MUSTs 应占约 60% 的容量
warning_signs:
- "所有需求都是 MUST" → 更严格
- "没有 WON'Ts" → 你在避免艰难决定
- "MUSTs 超过容量" → 重新评估或减少范围
Kano 模型
功能类别
kano_categories:
basic:
name: "基本（必须有）"
description: "期望的功能 - 缺少会导致不满"
examples:
- "网站无错误加载"
- "登录正常工作"
- "数据可靠保存"
satisfaction_curve: "只防止不满，不创造满意"
performance:
name: "性能（一维）"
description: "越多越好 - 线性满意"
examples:
- "页面加载速度"
- "存储容量"
- "集成数量"
satisfaction_curve: "与投资的线性关系"
excitement:
name: "兴奋（惊喜功能）"
description: "意外的功能创造惊喜"
examples:
- "AI 驱动的建议"
- "个性化体验"
- "创新快捷方式"
satisfaction_curve: "高满意，低期望"
indifferent:
name: "漠不关心"
description: "用户不关心的功能"
examples:
- "技术实现细节"
- "过度工程功能"
action: "降低优先级或移除"
reverse:
name: "反向"
description: "一些用户主动不喜欢的功能"
examples:
- "强制教程"
- "侵入性通知"
action: "使可选或移除"
Kano 调查方法
kano_survey:
question_pair:
functional: "如果 [功能] 存在，你会感觉如何？"
dysfunctional: "如果 [功能] 不存在，你会感觉如何？"
answer_options:
- "我喜欢它"
- "我期望它"
- "我中立"
- "我可以忍受它"
- "我不喜欢它"
interpretation_matrix:
# 功能 → 功能缺失 → 类别
"喜欢 → 不喜欢": "兴奋"
"喜欢 → 中立": "兴奋"
"期望 → 不喜欢": "基本"
"中立 → 中立": "漠不关心"
"喜欢 → 喜欢": "可疑（不一致）"
Kano 可视化
满意度
↑
│ ╱ 兴奋（惊喜功能）
│ ╱
│ ╱
│ ╱
────┼─────────────── 性能
│ ╲
│ ╲
│ ╲
│ ╲ 基本（必须有）
│
└─────────────────────────────→ 实现度
未实现 完全实现
WSJF（加权最短作业优先）
公式
wsjf:
formula: "WSJF = 延迟成本 / 作业大小"
cost_of_delay:
components:
user_value: "对最终用户/客户的价值"
time_criticality: "价值随时间衰减的程度"
risk_reduction: "由功能启用的风险/机会"
formula: "CoD = 用户价值 + 时间关键性 + 风险降低"
job_size:
definition: "实施相对努力"
scale: "斐波那契（1, 2, 3, 5, 8, 13）"
WSJF 评分模板
wsjf_example:
feature: "移动应用离线模式"
cost_of_delay:
user_value:
score: 8
rationale: "现场工作者高度请求"
time_criticality:
score: 5
rationale: "竞争对手在 Q2 推出类似功能"
risk_reduction:
score: 3
rationale: "减少连接问题的支持票"
total_cod: 16
job_size:
score: 5
rationale: "中等复杂度，已知模式"
wsjf_score: 3.2 # 16 / 5
interpretation: "高优先级 - 努力价值高"
WSJF 比较表
| 功能 | 用户价值 | 时间关键性 | 风险降低 | CoD | 大小 | WSJF | 排名 |
|---|---|---|---|---|---|---|---|
| 离线模式 | 8 | 5 | 3 | 16 | 5 | 3.2 | 1 |
| 深色主题 | 5 | 1 | 1 | 7 | 2 | 3.5 | 2 |
| 导出 PDF | 6 | 3 | 2 | 11 | 8 | 1.4 | 3 |
Wiegers 的价值/成本/风险方法
评分维度
wiegers_method:
dimensions:
value:
question: "这提供什么相对好处？"
scale: 1-9
perspective: "客户/业务价值"
penalty:
question: "不拥有这个的相对惩罚是什么？"
scale: 1-9
perspective: "遗漏风险"
cost:
question: "实施的相对成本是什么？"
scale: 1-9
perspective: "开发努力"
risk:
question: "相对技术风险是什么？"
scale: 1-9
perspective: "不确定性，复杂性"
formula: |
优先级 = (价值 × 价值权重 + 惩罚 × 惩罚权重) /
(成本 × 成本权重 + 风险 × 风险权重)
default_weights:
value: 2
penalty: 1
cost: 1
risk: 0.5
Wiegers 模板
wiegers_example:
feature: "双因素认证"
scores:
value: 7 # 高安全价值
penalty: 9 # 如果缺少的较大惩罚（合规风险）
cost: 5 # 中等实施努力
risk: 3 # 已知模式，低风险
calculation:
numerator: (7 × 2) + (9 × 1) = 23
denominator: (5 × 1) + (3 × 0.5) = 6.5
priority: 3.54
interpretation: "高优先级，因为遗漏的惩罚强"
机会评分（JTBD）
重要性 vs 满意度
来自 JTBD 框架：
opportunity_scoring:
formula: "机会 = 重要性 + (重要性 - 满意度)"
data_collection:
survey_questions:
importance: "达到 [结果] 有多重要？(1-10)"
satisfaction: "对当前能力的满意度如何？(1-10)"
interpretation:
score_15_20: "高机会 - 未满足"
score_10_15: "中等机会"
score_5_10: "低机会 - 服务良好"
score_below_5: "过度服务 - 降低优先级"
example:
outcome: "快速找到相关产品"
importance: 9
satisfaction: 4
score: 14 # 9 + (9-4)
interpretation: "中等至高机会"
选择方法
method_selection:
use_moscow_when:
- "需要快速决定"
- "利益相关者熟悉方法"
- "定义 MVP 范围"
- "二元进入/退出决定"
use_kano_when:
- "理解客户满意度驱动因素"
- "产品差异化焦点"
- "有客户调查访问"
- "平衡基本与惊喜功能"
use_wsjf_when:
- "敏捷/SAFe 环境"
- "基于流的交付"
- "经济决策制定"
- "比较不同大小的功能"
use_wiegers_when:
- "需要定量理由"
- "多个利益相关者视角"
- "高风险优先决策"
- "想要加权多个因素"
use_opportunity_when:
- "基于 JTBD 的产品开发"
- "有客户研究可用"
- "寻找未满足需求"
- "以结果为导向的路线图"
结合方法
combined_approach:
step_1: "使用 MoSCoW 进行初步分类"
step_2: "应用 Kano 以更好地理解 SHOULD/COULD 项"
step_3: "使用 WSJF 或 Wiegers 在类别内排名"
step_4: "用机会评分根据客户数据验证"
example_workflow:
- "所有 MUSTs 进入待办事项（不可协商）"
- "Kano 分析 SHOULDs 揭示 3 个惊喜功能"
- "WSJF 对惊喜功能按价值/努力排名"
- "最终待办事项按业务理由排序"
输出格式
优先级报告模板
priority_report:
domain: "{领域}"
method: "{使用的方法}"
date: "{ISO-8601}"
summary:
total_requirements: 25
high_priority: 8
medium_priority: 10
low_priority: 7
detailed_ranking:
- rank: 1
requirement_id: "REQ-001"
title: "双因素认证"
method_score: 3.54
rationale: "遗漏的高惩罚，合规要求"
- rank: 2
requirement_id: "REQ-015"
title: "移动离线模式"
method_score: 3.2
rationale: "高用户价值，竞争压力"
visualization: |
[Mermaid 或 ASCII 图显示优先级分布]
recommendations:
- "立即关注前 5 个高优先级项"
- "考虑延期高成本的低优先级项"
- "根据新信息在 2 周内重新评估"
相关命令
/prioritize- 应用优先排序方法到需求/gaps- 在优先排序前识别缺失需求/export- 导出优先排序的需求
参考
详细指南：
外部：
- Karl Wiegers 的《软件需求》
- SAFe 框架 WSJF 指导
- Noriaki Kano 关于客户满意度的研究
版本历史
- v1.0.0 (2025-12-26): 初始发布 - 优先排序方法技能
最后更新： 2025-12-26