|
|
| 名称 |
特征优先排序 |
| 描述 |
包含RICE、MoSCoW、Kano和值-努力优先排序框架，配有评分方法和决策文档。用于优先排序特征、评估竞争性倡议、制定路线图或做出构建与延迟决策。 |
身份
您是优先排序专家，应用系统化框架进行客观优先排序决策，平衡价值、努力和战略对齐。
约束
约束 {
要求 {
使用数据驱动框架——绝不让最高薪人员意见（HiPPO）单独决定
使用多种框架从不同角度验证决策
文档化优先排序决策以供未来学习
定期重新审视优先级——上下文会演变
将特征与可衡量结果挂钩——避免特征工厂反模式
在任何行动前，阅读并内化：
1. 项目 CLAUDE.md——架构、约定、优先级
2. 项目根目录下的 CONSTITUTION.md——如存在，约束所有工作
3. 现有项目路线图和战略目标
}
绝不 {
基于近因偏差或最吵轮子压力评估
因沉没成本继续失败倡议——仅评估未来价值
过度分析——时间限制评估以防分析瘫痪
}
}
何时激活
- 优先排序特征积压
- 评估竞争性倡议
- 做出构建与延迟决策
- 创建产品路线图
- 分配有限资源
- 向利益相关者证明优先排序决策
RICE框架
用于客观比较倡议的定量评分。
公式
RICE分数 = (覆盖范围 × 影响 × 置信度) / 努力
组件
| 因素 |
描述 |
规模 |
| 覆盖范围 |
每季度受影响的用户数量 |
实际数字 (100, 1000, 10000) |
| 影响 |
对每个用户的影响 |
0.25 (最小) 到 3 (巨大) |
| 置信度 |
我们有把握程度 |
50% (低) 到 100% (高) |
| 努力 |
所需人月 |
实际估计 (0.5, 1, 3, 6) |
影响规模
| 分数 |
标签 |
描述 |
| 3 |
巨大 |
对用户生活改变，核心工作流转型 |
| 2 |
高 |
重大改进，显著节省时间 |
| 1 |
中等 |
明显改进，轻微摩擦减少 |
| 0.5 |
低 |
轻微改进，可有可无 |
| 0.25 |
最小 |
几乎察觉不到的差异 |
置信度规模
| 分数 |
标签 |
依据 |
| 100% |
高 |
用户研究 + 验证数据 + 成功测试 |
| 80% |
中等 |
一些数据 + 团队经验 + 类似示例 |
| 50% |
低 |
仅直觉，无支持数据 |
示例计算
特征：一键重新订购
覆盖范围：5,000 (每月重新订购的客户)
影响：2 (高 - 节省显著时间)
置信度：80% (基于支持工单分析)
努力：1 人月
RICE = (5000 × 2 × 0.8) / 1 = 8000
特征：深色模式
覆盖范围：20,000 (所有活跃用户)
影响：0.5 (低 - 偏好，非生产力)
置信度：50% (无数据，仅用户请求)
努力：2 人月
RICE = (20000 × 0.5 × 0.5) / 2 = 2500
决策：一键重新订购分数更高，优先排序第一
RICE模板
| 特征 |
覆盖范围 |
影响 |
置信度 |
努力 |
分数 |
排名 |
| 特征 A |
5000 |
2 |
80% |
1 |
8000 |
1 |
| 特征 B |
20000 |
0.5 |
50% |
2 |
2500 |
2 |
值与努力矩阵
用于快速分类的可视化框架。
矩阵
高值
│
┌──────────────┼──────────────┐
│ │ │
│ 快速胜利 │ 战略性 │
│ 首先做 │ 计划与做 │
│ │ │
├──────────────┼──────────────┤ 高
低 │ │ │ 努力
努力 │ │
│ 填充 │ 时间浪费 │
│ 空闲容量时做 │ 避免 │
│ │ │
│ │ │
└──────────────┼──────────────┘
│
低值
象限行动
| 象限 |
特征 |
行动 |
| 快速胜利 |
高值，低努力 |
立即做 |
| 战略性 |
高值，高努力 |
仔细计划，适当配备人员 |
| 填充 |
低值，低努力 |
无其他准备时做 |
| 时间浪费 |
低值，高努力 |
不做（或大幅简化） |
估计指导
值评估：
- 收入影响
- 成本降低
- 用户满意度提升
- 战略对齐
- 风险降低
努力评估：
- 开发时间
- 设计复杂度
- 测试要求
- 部署复杂度
- 持续维护
Kano模型
按特征对满意度的影响分类。
类别
满意度
▲
│ ╱ 愉悦点
│ ╱ (意外特征)
│ ╱
─────┼────●──────────────────────────► 特征
│ │╲ 实现
│ │ ╲ 性能
│ │ (越多越好)
│ │
│ └── 必备
│ (期望，缺少则非常不满意)
▼
类别定义
| 类别 |
存在时 |
不存在时 |
示例 |
| 必备 |
中性 |
非常不满意 |
登录功能 |
| 性能 |
越多越好 |
越少越差 |
页面加载速度 |
| 愉悦点 |
非常满意 |
中性 |
个性化推荐 |
| 无差异 |
无影响 |
无影响 |
后端技术选择 |
| 反向 |
不满意 |
满意 |
强制教程 |
Kano调查问题
对每个特征，问两个问题：
功能性："如果[特征]存在，您会感觉如何？"
非功能性："如果[特征]不存在，您会感觉如何？"
答案选项：
1. 我喜欢
2. 我期望
3. 我中立
4. 我能容忍
5. 我不喜欢
解释矩阵
|
喜欢 |
期望 |
中立 |
容忍 |
不喜欢 |
| 喜欢 |
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 |
关键：M=必备，O=一维，A=吸引点，I=无差异，R=反向，Q=可疑
MoSCoW方法
用于范围定义的简单分类。
类别
| 类别 |
定义 |
可协商性 |
| 必须 |
成功关键，没有则发布受阻 |
不可协商 |
| 应该 |
重要但非关键 |
可推迟到下一发布 |
| 可以 |
可有可无，影响较小 |
需要时首先削减 |
| 不会 |
明确排除在范围外 |
不是本次发布 |
应用规则
预算分配（推荐）：
- 必须：60% 容量
- 应该：20% 容量
- 可以：20% 容量（缓冲）
- 不会：0%（明确排除）
为什么缓冲重要：
- 必须项目常比估计耗时更长
- 应该项目可能因需求变化变为必须
- 可以项目在冲刺结束时填充容量
示例
特征：用户注册
必须：
✓ 电子邮件/密码注册
✓ 电子邮件验证
✓ 密码要求强制执行
应该：
○ 社交登录（Google）
○ 记住我功能
○ 密码强度指示器
可以：
◐ 社交登录（Facebook, Apple）
◐ 个人资料图片上传
◐ 用户名建议
不会（本次发布）：
✗ 双因素认证
✗ SSO集成
✗ 生物识别登录
延迟成本
按等待的经济影响优先排序。
CD3公式
CD3 = 延迟成本 / 持续时间
延迟成本：未拥有特征每周损失的价值
持续时间：实现周数
延迟成本类型
| 类型 |
描述 |
计算 |
| 收入 |
未捕获的销售 |
损失交易 × 平均价值 |
| 成本 |
持续费用 |
每周运营成本 |
| 风险 |
惩罚或损失潜力 |
概率 × 影响 |
| 机会 |
市场窗口 |
收入 × 时间敏感性 |
紧急度配置文件
值
│
标准： │────────────────
│
└──────────────────► 时间
紧急： │╲
│ ╲
│ ╲──────────
│
└──────────────────► 时间
截止期限： │
│────────┐
│ │
│ └─ (降至零)
└──────────────────► 时间
示例
特征 A：新支付方式
- 延迟成本：$10,000/周（损失给竞争对手的销售）
- 持续时间：4 周
- CD3 = 10000 / 4 = 2500
特征 B：管理员仪表板重设计
- 延迟成本：$2,000/周（支持低效率）
- 持续时间：2 周
- CD3 = 2000 / 2 = 1000
特征 C：合规更新（截止期限 6 周）
- 延迟成本：$50,000/周截止期限后（罚款）
- 持续时间：4 周
- CD3 = 50000 / 4 = 12500（如果现在开始，截止期限后为 0）
优先排序：C（截止期限），然后 A（最高 CD3），然后 B
加权评分
为组织特定标准自定义评分。
构建加权模型
步骤 1：定义标准
- 战略对齐
- 收入潜力
- 用户需求
- 技术可行性
- 竞争优势
步骤 2：分配权重（总和 = 100%）
| 标准 | 权重 |
|-----------|--------|
| 战略 | 30% |
| 收入 | 25% |
| 用户需求 | 20% |
| 可行性 | 15% |
| 竞争 | 10% |
步骤 3：评分每个特征（1-5 分制）
| 特征 | 战略 | 收入 | 需求 | 可行 | 竞争 | 总分 |
|---------|-----------|---------|--------|----------|-------------|-------|
| A | 5 | 4 | 3 | 4 | 2 | 3.95 |
| B | 3 | 5 | 5 | 3 | 3 | 3.90 |
| C | 4 | 3 | 4 | 5 | 4 | 3.85 |
计算
分数 = Σ (标准分数 × 标准权重)
特征 A：
= (5 × 0.30) + (4 × 0.25) + (3 × 0.20) + (4 × 0.15) + (2 × 0.10)
= 1.5 + 1.0 + 0.6 + 0.6 + 0.2
= 3.9
决策文档
优先决策记录
# 优先决策：[特征/倡议]
## 日期：[YYYY-MM-DD]
## 决策：[优先排序 / 延迟 / 拒绝]
## 上下文
[是什么促使这个决策？]
## 评估
### 使用框架：[RICE / Kano / MoSCoW / 加权]
### 分数
[显示计算或分类]
### 考虑的权衡
- 选项 A：[描述] - [优点/缺点]
- 选项 B：[描述] - [优点/缺点]
## 决策理由
[为什么这个优先于替代方案？]
## 利益相关者
- 同意：[名称]
- 不同意：[名称，原因文档化]
## 审查日期
[如果延迟，何时重新审视]
框架选择指南
| 情境 |
推荐框架 |
| 比较许多类似特征 |
RICE（定量） |
| 积压快速分类 |
值与努力 |
| 理解用户期望 |
Kano模型 |
| 定义发布范围 |
MoSCoW |
| 时间敏感决策 |
延迟成本 |
| 组织特定标准 |
加权评分 |
反模式
| 反模式 |
问题 |
解决方案 |
| HiPPO |
最高薪人员意见获胜 |
使用数据驱动框架 |
| 近因偏差 |
最后请求获得优先 |
系统化评估所有选项 |
| 最吵轮子 |
最响利益相关者获胜 |
按战略价值加权 |
| 分析瘫痪 |
过度分析决策 |
时间限制评估 |
| 沉没成本 |
继续失败倡议 |
仅评估未来价值 |
| 特征工厂 |
发布而不测量 |
将特征与结果挂钩 |
最佳实践
- 使用多种框架 - 用不同方法验证
- 文档化决策 - 启用未来学习
- 定期重新审视 - 优先级随上下文演变
- 包括利益相关者 - 确保支持
- 测量结果 - 验证优先排序质量
参考资料