# 1 Roadmap Planner

> 远期路线图规划 — 基于OKR和SMART原则制定项目远期目标（季度/年度），生成结构化的ROADMAP.md文档，包含战略愿景、目标与关键结果、里程碑时间轴、风险评估和进度跟踪机制

- Skill: `morning-start/1-roadmap-planner` (Agent Skill)
- Install (CLI): `npx skillmds@latest add morning-start/1-roadmap-planner`
- Raw SKILL.md: https://api.skillmd.com/api/skills/morning-start/1-roadmap-planner/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: morning-start (https://skillmd.com/u/morning-start)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/morning-start/1-roadmap-planner

---


# ① 远期路线图规划 (ROADMAP Planner)

## 任务目标

帮助用户制定项目的**远期规划**（通常为季度或年度），产出标准化的 `ROADMAP.md` 文件。该文件应清晰呈现：
- **战略愿景**: 1-3 年的北极星方向
- **目标体系**: 基于 OKR 的 O（目标）+ KR（关键结果）
- **里程碑时间轴**: 关键节点和交付物
- **风险与依赖**: 潜在障碍和应对策略

## 触发条件

当用户说以下任一话术时激活：
- "帮我写 roadmap" / "制定路线图"
- "设定年度/季度目标"
- "规划远期计划" / "长期规划"
- "创建 OKR" / "对齐目标"
- "定义里程碑"

## 前置信息收集

在开始编写 ROADMAP 前，必须先了解：

```bash
# 收集项目上下文
cat README.md | head -50                    # 项目定位
ls -1 package.json Cargo.toml pyproject.toml 2>/dev/null  # 技术栈
git log --oneline -10                       # 近期活动
# 如有现有的 TODO 或规划文件，也需查看
```

### 必须确认的 5 个关键问题

| # | 问题 | 获取方式 | 权重 |
|---|------|---------|------|
| 1 | **项目当前阶段？** (MVP/成长期/成熟期) | 与用户沟通或读 README | 20% |
| 2 | **时间跨度？** (Q4/2026全年/未来12个月) | 用户明确指定 | 25% |
| 3 | **核心目标？** (1-3个主要方向) | 用户描述 | 30% |
| 4 | **团队规模？** (个人/小团队/企业) | 影响方法论选择 | 15% |
| 5 | **约束条件？** (资源/技术/市场) | 可能影响可行性 | 10% |

## 操作步骤

### Step 1: 定义战略愿景（北极星）

#### 什么是愿景？
愿景是**长期的、定性的、鼓舞人心的方向性描述**，回答："我们最终想成为什么？"

#### 撰写规范

✅ **好的愿景示例**：
```
成为开发者首选的 {领域} 解决方案
让 {用户群体} 能够 {核心价值}
打造 {行业} 最 {形容词} 的 {产品类型}
```

❌ **差的愿景示例**：
```
完成所有功能开发          ← 太操作化，不是愿景
提高代码质量              ← 太模糊，无法衡量
赚更多的钱                ← 太功利，无激励性
```

**检验清单**:
- [ ] 时间跨度：1-3 年（非短期任务）
- [ ] 定性描述：不包含具体数字
- [ ] 有激励性：能激发团队热情
- [ ] 方向清晰：知道往哪个方向走
- [ ] 简洁有力：1-2 句话能说完

> 📖 详细指南: [smart-principle.md](../references/smart-principle.md)

---

### Step 2: 设定 OKR 目标体系

#### OKR 标准结构

```
愿景 (Vision)
    ↓
年度目标 O1 ──→ KR1-1, KR1-2, KR1-3
           O2 ──→ KR2-1, KR2-2, KR2-3, KR2-4
           O3 ──→ KR3-1, KR3-2
    ↓
季度目标 Q1-O1 ──→ Q1-KR1-1, ...
            Q2-O1 ──→ Q2-KR1-1, ...
```

#### 如何撰写优秀的 Objective (O)

**定义**: 定性的、有野心的、激励人心的目标描述

**公式**: **动词 + 名词 + 成果描述**

| 维度 | 要求 | 示例 |
|------|------|------|
| **定性** | 不含数字 | ✅ "建立可靠的市场地位" ❌ "获得100万用户" |
| **有野心** | 跳一跳够得着 | ✅ "成为Top3" ❌ "保持现状" |
| **时限内可达成** | 在规划周期内合理 | 非遥不可及的空想 |
| **可独立存在** | 不依赖其他O | 自身完整 |

**常见 Objective 模板**:
- 打造{形容词}{核心能力}
- 建立{领域}的{地位}
- 实现{功能/能力}的{水平}
- 完成{阶段}的{转型}

#### 如何撰写优秀的 Key Result (KR)

**定义**: 可量化的、可衡量的结果指标，用于验证 Objective 是否达成

**公式**: **指标 + 当前值 → 目标值 + 时间**

**KR 的 4 种类型**:

| 类型 | 格式 | 示例 |
|------|------|------|
| **📈 增长型** | 从 X 增长到 Y | 日活从 1K → 5K (+400%) |
| **📉 减少型** | 从 X 降低到 Y | P95延迟从 500ms → 200ms (-60%) |
| **✅ 达成型** | 完成率为 0% → 100% | 核心模块测试覆盖率 40% → 85% |
| **⭐ 评分型** | 评分从 X 提升到 Y | NPS从 30 → 60 (+30分) |

**KR 质量自检（SMART）**:

| 维度 | 问题 | 通过标准 |
|------|------|---------|
| S (Specific) | 衡量什么？ | 指标明确（如"日活用户数"而非"用户参与度"） |
| M (Measurable) | 怎么算达成？ | 有明确的目标值和当前基线值 |
| A (Achievable) | 能做到吗？ | 有一定挑战性但非不可能（建议增长 30-100%） |
| R (Relevant) | 为什么重要？ | 直接支撑 Objective 的达成 |
| T (Time-bound) | 何时检查？ | 有明确的截止日期或检查节奏 |

**数量控制**:
- 每个 O 对应 **2-5 个 KR**（推荐 3-4 个）
- 整个周期（季度/年）的 O 数量：**1-3 个**（推荐 2-3 个）
- 总 KR 数量：**4-8 个**（过多则焦点分散）

---

### Step 3: 设计里程碑时间轴

#### 里程碑 vs OKR 的区别

| 维度 | OKR (Objective+KR) | Milestone (里程碑) |
|------|-------------------|-------------------|
| **性质** | 结果导向（Outcome） | 交付导向（Output） |
| **衡量** | 定量指标 | 二元状态（完成/未完成） |
| **粒度** | 季度/月度 | 具体日期点 |
| **示例** | "DAU 提升 50%" | "v2.0 发布 (3/15)" |

#### 里程碑设计原则

1. **关键节点**: 标志性的转折点或交付点
2. **时间均匀分布**: 避免集中在季末
3. **可验收**: 有明确的 Done 标准
4. **依赖可见**: 前置条件已标注

**标准格式**:

```markdown
### Q2 2026 里程碑

| 日期 | 里程碑 | 类型 | 负责人 | 依赖 | Done标准 |
|------|--------|------|--------|------|----------|
| 4/15 | M1: Alpha 版本发布 | 🚀 交付 | Team A | 无 | 内部可用，核心流程跑通 |
| 5/01 | M2: 性能优化完成 | ⚡ 改进 | Team B | M1 | P95 < 200ms |
| 5/20 | M3: Beta 公测启动 | 👥 运营 | Team C | M1,M2 | 100+ 外部用户试用 |
| 6/10 | M4: 正式版 v1.0 发布 | 🎉 发布 | All | M1-M3 | 生产环境稳定运行 7天 |
```

**里程碑命名建议**:
- 使用动宾结构: "发布 v2.0"、"完成重构"、"上线新功能"
- 加上版本号或代号: "M1: Project Phoenix 启动"
- 标注类型emoji: 🚀交付 / ⚡改进 / 👥运营 / 🎉发布 / 🔬研究

---

### Step 4: 评估风险与依赖

#### 风险评估矩阵

| 影响 \ 概率 | 低 (L) | 中 (M) | 高 (H) |
|-------------|--------|--------|--------|
| **高 (H)** | 🟡 中等 | 🟠 较高 | 🔴 **必须应对** |
| **中 (M)** | 🟢 低 | 🟡 中等 | 🟠 较高 |
| **低 (L)** | 🟢 可接受 | 🟢 低 | 🟡 中等 |

**每个风险记录**:

```markdown
### ⚠️ 风险 #{N}: {简短标题}

- **描述**: {具体说明风险是什么}
- **影响**: 🔴高/🟠中/🟢低 （如果发生会怎样？）
- **概率**: 🔴高(>50%)/🟠中(20-50%)/🟢低(<20%) （发生的可能性）
- **触发条件**: {什么情况下可能发生？}
- **应对策略**:
  - 缓解(Mitigate): {如何降低概率或影响}
  - 应急(Contingency): {如果发生了怎么办}
- **负责人**: @{who}
- **监控频率**: {每周/每两周/每月}
```

**必填风险项（至少 3 个）**:
1. 技术风险（如：核心技术难点、性能瓶颈）
2. 资源风险（如：关键人员离职、预算削减）
3. 市场风险（如：竞品发布、需求变更）

#### 依赖关系管理

```markdown
## 🔗 关键依赖

| 依赖项 | 类型 | 来源 | 状态 | 备选方案 |
|--------|------|------|------|---------|
| {依赖名称} | 🔗外部/🔗内部/🔗上游 | {来自哪里} | ✅就绪/⏳等待中/❌阻塞 | {如果没有怎么办} |
```

---

### Step 5: 编写完整 ROADMAP.md

#### 标准模板（推荐使用）

```markdown
# {项目名} 路线图 ({时间范围})

> 最后更新: {date} | 负责人: {owner} | 下次评审: {next_review}

---

## 🎯 战略愿景

{1-2句话的北极星方向}

### 核心价值观/原则（可选）
1. {value_1}
2. {value_2}
3. {value_3}

---

## 📅 {年份} 年度目标

### O1: {Objective 1 描述}

| KR | 指标描述 | 当前值 | 目标值 | 截止日期 | 负责人 | 状态 |
|----|---------|--------|--------|----------|--------|------|
| KR1 | {metric} | {current} | {target} | {deadline} | @who | 🔴🟡🟢⚪ |
| KR2 | {metric} | {current} | {target} | {deadline} | @who | 🔴🟡🟢⚪ |
| KR3 | {metric} | {current} | {target} | {deadline} | @who | 🔴🟡🟢⚪ |

#### Q1 季度拆解
- **Q1-O1**: {季度目标}
  - Q1-KR1: {季度KR}
  - Q1-KR2: {季度KR}

**Q1 里程碑**:
- [ ] **M1 ({date})**: {milestone}
- [ ] **M2 ({date})**: {milestone}

### O2: {Objective 2 描述}
...（同上结构）

### O3: {Objective 3 描述}
...（同上结构）

---

## 📍 里程碑总览

| 季度 | 日期 | 里程碑 | 关联O/KR | 状态 |
|------|------|--------|----------|------|
| Q1 | ... | ... | ... | ⬜/✅ |
| Q2 | ... | ... | ... | ⬜/✅ |
| Q3 | ... | ... | ... | ⬜/✅ |
| Q4 | ... | ... | ... | ⬜/✅ |

---

## ⚠️ 风险与依赖

### Top 风险
| # | 风险 | 影响 | 概率 | 应对策略 | 负责人 |
|---|------|------|------|---------|--------|
| 1 | ... | H/M/L | H/M/L | ... | @who |
| 2 | ... | H/M/L | H/M/L | ... | @who |
| 3 | ... | H/M/L | H/M/L | ... | @who |

### 关键依赖
| 依赖项 | 类型 | 来源 | 状态 | 截止 |
|--------|------|------|------|------|
| ... | 外部/内部 | ... | 就绪/等待 | ... |

---

## 📊 进度仪表盘（可选）

### OKR 完成率
| 目标 | KR完成数 | 总KR数 | 完成率 | 健康度 |
|------|---------|--------|--------|--------|
| O1 | X/Y | Z% | 🟢健康/🟡警告/🔴危险 |
| O2 | X/Y | Z% | ... |
| O3 | X/Y | Z% | ... |
| **总计** | X/Y | Z% | ... |

---

## 📚 相关文档
- 本周期的详细TODO: [TODO.md](./TODO.md)
- 上季度复盘: [review-q{n}.md](./reviews/)
- 技术架构文档: [architecture.md](./docs/architecture.md)

---

## 📝 变更日志

| 日期 | 变更内容 | 原因 | 作者 |
|------|---------|------|------|
| {date} | 初始版本 | 新建 | {author} |
```

---

### Step 6: 质量验证

#### SMART 自检清单

对每个 OKR 执行以下检查：

```markdown
## OKR 质量检查表

### Objective 检查
- [ ] 是否定性？（不含数字）
- [ ] 是否有激励性？（能让人兴奋）
- [ ] 是否在周期内可实现？（非空想）
- [ ] 是否独立？（不依赖其他O）

### Key Results 检查
- [ ] **S**pecific: 指标清晰无歧义？
- [ ] **M**easurable: 有数值目标和基线？
- [ ] **A**chievable: 挑战性适中（30-100%增长）？
- [ ] **R**elevant: 直接支撑O？
- [ ] **T**ime-bound: 有截止日期？

### 整体检查
- [ ] O的数量: 1-3个 ✅
- [ ] 每个O的KR数: 2-5个 ✅
- [ ] 总KR数: 4-8个 ✅
- [ ] 里程碑分布均匀 ✅
- [ ] 至少3个风险已识别 ✅
- [ ] 所有KR都有负责人 ✅
```

#### 可行性快速评估

```bash
# 检查 ROADMAP 行数（应在合理范围内）
wc -l ROADMAP.md
# 推荐: 80-150行（根据复杂度）

# 检查关键元素
echo "=== 元素完整性 ==="
grep -c "^## " ROADMAP.md        # 一级章节数 (应≥6)
grep -ciE "(O[1-3]:|KR[0-9])" ROADMAP.md  # OKR数量
grep -c "|.*|.*|.*|" ROADMAP.md   # 表格数量
grep -c "⚠️\|🔴\|🟠" ROADMAP.md     # 风险标记数
```

## 快速路径（简化模式）

如果用户只需要**轻量级 OKR**（不需要完整的 Roadmap），可以使用简化模板：

```markdown
# {项目} OKR ({周期})

## O1: {目标1}
- **KR1**: {指标} {current} → {target} (@who)
- **KR2**: {指标} {current} → {target} (@who)
- **KR3**: {指标} {current} → {target} (@who)

## O2: {目标2}
...

---
*最后更新: {date} | 下次评审: {review_date}*
```

**适用场景**:
- 个人项目
- 快速迭代的小团队
- 作为更大规划的子集

## 常见问题

**Q: OKR 和 KPI 有什么区别？**

A: 
- **OKR**: 目标驱动，关注**结果**（Outcome），鼓励挑战性目标，允许部分达成（60-70%算成功）
- **KPI**: 指标驱动，关注**绩效**（Performance），通常要求100%达成，用于考核而非激励

**Q: KR 设多少合适？太容易还是太难？**

A: 推荐的完成率目标是 **70%**：
- 如果总是 100% → 目标太低，缺乏挑战性
- 如果总是 < 50% → 目标太高，容易挫败
- **最佳区间**: 60-80%（既有挑战又可实现）

**Q: 多久更新一次 ROADMAP？**

A: 建议：
- **KR 数据跟踪**: 月度或双周
- **整体评审**: 季度末（配合 OKR 复盘）
- **重大调整**: 仅当出现不可预见的变化时（如市场剧变、战略调整）

**Q: 个人项目需要这么复杂的规划吗？**

A: 不需要。个人项目推荐使用**简化模式**：
- 1个 O + 3个 KR（季度）
- 或直接用 SMART TODO（见 [2-todo-planner](../skills/2-todo-planner/SKILL.md)）

## 注意事项

⚠️ **规划 ≠ 计划**: ROADMAP 是"做什么+为什么"，不是"怎么做+谁什么时候做"。后者是 TODO/Gantt 的范畴。

⚠️ **保持动态**: ROADMAP 是活文档！建议每季度回顾一次，根据实际情况调整。

⚠️ **避免过度规划**: 远期（>6个月）的内容应保持粗粒度，细节随时间推移逐步细化。

⚠️ **对齐意识**: 团队项目的 OKR 必须与上级/公司目标对齐，避免各自为战。