roadmap-prioritization-planning

路线图与优先级排序技能

掌握说“不”的艺术。制定聚焦的路线图，让组织目标保持一致，推动战略成果，并在资源有限的情况下最大化影响。

RICE 评分体系（完整）

公式

RICE Score = (Reach × Impact × Confidence) / Effort

Reach: How many users affected? (1-100+)
- 10+ = 10
- 100+ = 100
- 1000+ = 1000

Impact: Per-user impact (3, 2, 1, 0.5)
- 3 = Massive (10x improvement)
- 2 = High (significant improvement)
- 1 = Medium (noticeable improvement)
- 0.5 = Low (minor improvement)

Confidence: How confident? (0.25-1.0)
- 1.0 = High (research backed)
- 0.8 = Medium (some validation)
- 0.5 = Low (minimal validation)
- 0.25 = Very low (assumption)

Effort: Engineer-weeks needed (1-20+)

评分示例矩阵

Feature          Reach Impact Confidence Effort RICE Score
────────────────────────────────────────────────────────
User Onboarding   50    3      0.8      8      (50×3×0.8)/8 = 15.0
Dark Mode         200   1      0.9      4      (200×1×0.9)/4 = 45.0
API Limits        500   2      0.7      10     (500×2×0.7)/10 = 70.0
Performance Fix   1000  0.5    1.0      5      (1000×0.5×1)/5 = 100.0
Custom Fields     30    3      0.6      12     (30×3×0.6)/12 = 4.5

PRIORITIZE: Performance > API Limits > Dark Mode > Onboarding > Custom Fields

RICE 置信度等级

高（1.0）——有研究支持

• 已开展客户访谈
• 有分析数据
• 客户支持工单予以证实
• 客户需求明确

中（0.8）——经过一定验证

• 合乎逻辑的假设
• 有一到两位客户提出需求
• 行业趋势表明有此需求
• 类似功能在其他地方取得成功

低（0.5）——验证有限

• 基于经验的猜测
• 竞争压力（对手已有此功能）
• 出现了新的机会
• 需要进一步验证

极低（0.25）——纯粹假设

• “感觉是个好主意”
• 没有客户反馈
• 完全未经验证
• 浪费资源的风险很高

其他优先级排序方法

价值与投入矩阵

           Low Effort      High Effort
High Value  QUICK WINS      STRATEGIC
           (Do first)      (Plan carefully)

Low Value   FILL-INS        AVOID
           (If time)       (Skip)

快速见效项： 高价值、低投入

• 优先实施，提振势头
• 增强信心
• 向利益相关者展示进展
• 示例：Bug 修复、小型功能

战略项目： 高价值、高投入

• 带来长期竞争优势
• 需要规划和资源
• 示例：新平台、架构

填充项： 低价值、低投入

• 打磨功能
• 偿还技术债
• 有余力时再做

避免项： 低价值、高投入

• 浪费资源
• 明确说“不”

MoSCoW 方法（更简单）

必须有（发布不可或缺）

• 核心功能
• 缺少这些功能：无法发布
• 通常占工作量的 40%

应该有（重要但可推迟）

• 价值显著
• 即使没有也能发布，但吸引力会降低
• 通常占工作量的 30%

可以有（锦上添花）

• 润色和实用功能
• 预算或时间允许时再做
• 通常占工作量的 20%

不会有（明确不在范围内）

• 明确推迟
• 帮助利益相关者了解优先事项
• 通常占工作量的 10%

Kano 模型（客户满意度）

三类功能：

基本因素（门槛）

• 预期应当具备
• 缺少时 = 非常不满意
• 具备时 = 满意（但不会惊喜）
• 示例：应用的核心功能
• 不带来竞争优势

绩效因素（线性）

• 越多 = 满意度越高
• 越少 = 满意度越低
• 带来竞争优势
• 示例：速度、自定义选项
• 持续提升效果

惊喜因素（兴奋）

• 意料之外的功能
• 具备时 = 惊喜
• 缺少时 = 无感
• 带来显著竞争优势
• 示例：令人惊喜的用户体验、隐藏功能

策略： 先实现必须有的功能，再实现绩效因素，最后添加惊喜因素以实现差异化

路线图规划流程

12 个月战略路线图

结构：

Q1 2025: Initiative Theme
├─ Goal: Business outcome
├─ Key Features: 2-3 major features
├─ Success Metrics: How you measure
└─ Resource: Team size needed

Q2 2025: Initiative Theme
Q3 2025: Initiative Theme
Q4 2025: Initiative Theme

季度规划流程

时间安排： 在季度开始前一个月规划

第 1 周：收集数据

• 上季度的客户反馈
• 支持工单和问题
• 竞争格局变化
• 团队回顾总结的经验
• 对照目标审查指标

第 2 周：确定优先级

• 应用 RICE 评分
• 考虑战略目标
• 评估资源可用情况
• 获取工程团队的估算
• 梳理依赖关系

第 3 周：规划

• 将用户故事拆分为冲刺
• 分配资源
• 识别风险
• 规划沟通

第 4 周：对齐与启动

• 向利益相关者展示路线图
• 工程团队承诺
• 获得高管支持
• 举行全员公告

冲刺规划（每周）

周一：规划

• 选择本次冲刺的功能
• 拆分为用户故事
• 估算投入
• 分配负责人
• 识别阻碍因素

每日：站会

• 你做了什么？
• 有什么阻碍？
• 接下来做什么？
• 最多 15 分钟

周五：回顾

• 哪些方面进展顺利？
• 哪些方面需要改进？
• 跟踪速率
• 为下一次冲刺调整计划

资源分配

团队产能规划

Team Size: 5 engineers
Sprint Length: 2 weeks
Typical Capacity: 40-50 story points

Planning Reality:
- 50% unplanned work (bugs, interrupts)
- 20% operational tasks
- 30% feature development

Result: 50 points × 30% = 15 points for features
→ Add MUST have items first
→ Fill remaining capacity with SHOULD/COULD

资源分配

工程团队：

• 60-70% 用于新功能（路线图）
• 20-30% 用于错误修复和优化
• 10-15% 用于技术债务
• 5-10% 用于运维和支持

产品经理：

• 60% 用于规划和探索
• 20% 用于沟通和协同
• 10% 用于分析和指标
• 10% 用于团队领导

设计团队：

• 70% 用于功能设计
• 15% 用于设计系统维护
• 15% 用于研究和测试

依赖关系与排序

依赖类型

硬依赖

• 功能 A 完成之前，无法开始功能 B
• 示例：先完成支付系统，再推出订阅计划
• 对时间线影响显著

软依赖

• 先完成功能 A 会让功能 B 更完善
• 示例：Web 端经过全面测试后再推出移动应用
• 时间安排灵活

跨团队依赖

• 需要其他团队先完成工作
• 前置时间最长
• 必须尽早提出

风险管理

常见风险：

1. 范围蔓延

   • 缓解措施：经常说“不”，推迟到未来
   • 负责人：产品经理
   • 计划：每周审查范围

2. 关键人员离职

   • 缓解措施：交叉培训、编写文档
   • 负责人：工程经理
   • 计划：入职流程

3. 时间线压力

   • 缓解措施：预留缓冲时间，管理预期
   • 负责人：产品经理
   • 计划：透明沟通

4. 出现技术挑战

   • 缓解措施：安排技术预研时间，制作概念验证
   • 负责人：工程负责人
   • 计划：估算中预留 20% 的应急时间

路线图沟通

面向高管

• 聚焦业务成果
• 展示每个季度如何逐步实现愿景
• 突出竞争差异化优势
• 说明对收入和增长的影响

面向工程团队

• 详细的规格和需求
• 技术复杂度和依赖关系
• 工作量估算和风险
• 资源需求

面向客户

• 聚焦用户的收益
• 时间安排（按季度，而非具体日期）
• 突出最受期待的功能
• 少承诺，多交付

面向销售团队

• 使用“即将推出”的宣传语
• 说明他们可以据此销售的内容
• 纳入客户反馈
• 突出竞争差异化优势

路线图审查与调整

**每周：**冲刺进度 **每月：**季度进度与计划对比 **每季度：**全面更新路线图 **每年：**审查战略方向

重新确定优先级的触发因素：

• 大量客户流失
• 竞争威胁
• 市场变化
• 意外的技术障碍
• 资源可用性变化

故障排查

常见错误与解决方案

错误	可能原因	解决方案
路线图持续延期	估算不切实际	增加 30% 的缓冲时间
优先级争论	标准不明确	举办 RICE 工作坊
资源争用	承诺过多	进行容量规划
依赖关系造成阻塞	识别过晚	在 Sprint 0 进行梳理

调试清单

[ ] RICE scoring consistent mi?
[ ] Capacity realistic mi? (20% buffer)
[ ] Dependencies mapped mi?
[ ] Stakeholder alignment var mı?
[ ] Risk mitigation planı var mı?

恢复流程

1. 路线图延期 → 重新确定优先级，缩减范围
2. 资源冲突 → 使用权衡矩阵
3. 优先级意见不一 → 以数据为依据使用 RICE

---

掌握优先级排序，制定能够带来实际成果的路线图！