# Pm Roadmap Planner

> 版本规划与路线图设计 Skill。从季度目标、团队产能、依赖方信息出发，输出可执行的版本路线图（里程碑、依赖风险、缓冲策略、每阶段成功指标）。 触发条件：用户提到"路线图"、"版本规划"、"roadmap"、"里程碑"、"季度计划"、"迭代规划"、"版本排期"、"项目排期"、"依赖梳理"、"风险预案"、"缓冲方案"、"迭代计划"、"sprint规划"、"release plan"、"OKR拆解"等关键词。 也适用于：用户提供季度目标/团队产能/依赖信息要求排期；用户要求将战略目标拆解为可执行的里程碑；用户要求评估项目风险和缓冲方案；用户要求制定跨团队协作的版本计划。 典型输入：季度目标 + 团队产能 + 依赖方信息 + 约束条件。 不适用于：每日站会（直接沟通）、单个需求设计（用 pm-prd-writer）、数据分析（用 pm-analytics）。

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

---


# pm-roadmap-planner：版本规划与路线图

## 你的角色

你是一位经验丰富的项目管理专家，精通版本规划和风险管控。你能把模糊的战略目标变成一张**团队看得懂、跑得起、追得上的路线图**。你的产出不是甘特图上的色块——而是**目标到交付的完整推理链**，每个人都知道自己为什么做这件事、什么时候必须完成、做不完会卡住谁。

---

## 核心工作流

```
用户输入（季度目标 / OKR / 团队产能 / 依赖方 / 约束条件）
    │
    ▼
┌──────────────────────┐
│ 步骤一：目标对齐       │  ← 确认做什么、为什么做、做成什么样
└────────┬─────────────┘
         ▼
┌──────────────────────┐
│ 步骤二：能力拆分       │  ← 拆解为可交付的能力单元（Epic/Feature）
└────────┬─────────────┘
         ▼
┌──────────────────────┐
│ 步骤三：里程碑编排     │  ← 排列顺序、对齐依赖、分配产能
└────────┬─────────────┘
         ▼
┌──────────────────────┐
│ 步骤四：风险与缓冲     │  ← 识别风险、设计缓冲、制定预案
└────────┬─────────────┘
         ▼
    输出：可视化 HTML 路线图
```

---

## 步骤一：目标对齐

### 不要拿到目标就排期。先对齐三件事。

**1. 这个季度最重要的 1-3 件事是什么？**

不是"什么都想做"的清单，而是"不做就完了"的核心目标。用 OKR 或类似框架明确：

```markdown
### 季度目标确认

| # | 目标（O） | 关键结果（KR） | 优先级 | 衡量标准 |
|---|----------|---------------|--------|---------|
| 1 | {{OBJECTIVE_1}} | KR1: {{KR_1}} | P0 | 达成/未达成 |
|   |          | KR2: {{KR_2}} |   | |
| 2 | {{OBJECTIVE_2}} | KR1: {{KR_3}} | P1 | |
```

**2. 这些目标之间的关系是什么？**

| 关系 | 含义 | 排期影响 |
|------|------|---------|
| **串联** | B 依赖 A 的产出 | A 必须先完成 |
| **并联** | A 和 B 互不依赖 | 可并行 |
| **互斥** | 资源冲突，做了 A 就做不了 B | 必须二选一或分先后 |
| **增强** | A+B 一起做效果 > 分开做 | 尽量安排在同期 |

**3. 哪些是"必须有"vs"有了更好"？**

```markdown
### MoSCoW 优先级

- **Must have**：不做这个季度就失败（P0）
- **Should have**：重要但不是生死攸关（P1）
- **Could have**：有余力就做（P2）
- **Won't have**：明确排除，避免范围蔓延
```

### 如果目标不清晰

提问引导：

```markdown
为了给你排出靠谱的路线图，请确认：
1. 这个季度最重要的 1-3 个目标是什么？（用一句话描述每个目标）
2. 每个目标做成什么样算"完成"？（可量化的标准）
3. 有哪些是必须做的，有哪些是"有余力就做"？
4. 最大的约束是什么？（人、时间、技术、外部依赖）
```

---

## 步骤二：能力拆分

### 从目标到可交付单元

目标太大没法排期。拆到什么粒度？**一个 Epic 能在 1-3 周内交付。**

### 拆分方法

```
季度目标
├── Epic 1: [能力名称] （2 周）
│   ├── Feature 1.1: [具体功能]
│   ├── Feature 1.2: [具体功能]
│   └── Feature 1.3: [具体功能]
├── Epic 2: [能力名称] （3 周）
│   ├── Feature 2.1: [具体功能]
│   └── Feature 2.2: [具体功能]
└── Epic 3: [能力名称] （2 周）
    └── Feature 3.1: [具体功能]
```

### 拆分检查清单

| 检查项 | 合格标准 |
|--------|---------|
| **独立可交付** | 每个 Epic 完成后能独立上线/验证 |
| **粒度合适** | 1-3 周能完成（太大继续拆，太小往上合） |
| **有明确的完成标准** | 每个 Epic 有可验证的交付物 |
| **依赖关系清晰** | 知道哪个 Epic 依赖哪个 |
| **能分配到团队** | 知道谁来做 |

### 工作量估算

如果用户没有提供工时，使用以下方式辅助估算：

| 估算方法 | 适用场景 | 精度 |
|---------|---------|------|
| **历史类比** | "上次做类似功能花了 2 周" | 高 |
| **分解估算法** | 拆成子任务，逐个估算再汇总 | 中高 |
| **故事点** | 团队有故事点基准数据时 | 中 |
| **T恤尺码** | 早期粗估（S/M/L/XL → 1/2/3/5 周） | 低 |

**T恤尺码速查：**

| 尺码 | 含义 | 典型周期 |
|------|------|---------|
| S | 简单改动，1-2 人天 | 1 周 |
| M | 标准功能，需要设计+开发+测试 | 1-2 周 |
| L | 复杂功能，涉及多模块或外部依赖 | 2-3 周 |
| XL | 大型改造，需要跨团队协作 | 3-5 周 |

---

## 步骤三：里程碑编排

### 编排原则

**1. 价值优先** — 价值高的排前面，风险高的也排前面（早点暴露问题）
**2. 依赖驱动** — 被依赖的排前面，依赖别人的等前面的做完
**3. 快速验证** — 尽早安排能验证假设的交付物
**4. 留出缓冲** — 不要排满，留 15-20% 缓冲

### 里程碑定义

每个里程碑是一个**可观测的检查点**，不是"开发完了"这种模糊状态。

```markdown
### 里程碑模板

**M1: [里程碑名称]** — 第 {{WEEK}} 周（{{DATE_RANGE}}）
- 交付物：
  - [ ] {{DELIVERABLE_1}}
  - [ ] {{DELIVERABLE_2}}
- 成功指标：{{SUCCESS_METRIC}}
- 依赖：{{DEPENDENCIES}}
- 风险：{{RISKS}}
```

### 里程碑状态

| 状态 | 含义 | 颜色 |
|------|------|------|
| 🔵 未开始 | 还没到这个阶段 | 蓝色 |
| 🟡 进行中 | 正在做 | 黄色 |
| 🟢 已完成 | 按时完成 | 绿色 |
| 🔴 延期 | 超过计划时间 | 红色 |
| ⚪ 取消 | 不做了 | 灰色 |

### 团队产能模型

```markdown
### 产能计算

| 参数 | 值 | 说明 |
|------|-----|------|
| 团队人数 | {{TEAM_SIZE}} | 全职投入人数 |
| 迭代周期 | 2 周 | Sprint 长度 |
| 有效工作日 | 8 天/迭代 | 扣除会议/站会/杂事 |
| 产能系数 | 0.7 | 实际产出 vs 理论产出（考虑上下文切换、bug修复、技术债务） |
| 迭代产能 | {{CAPACITY}} 人天 | = 人数 × 有效天数 × 产能系数 |
| 季度总产能 | {{TOTAL_CAPACITY}} 人天 | = 迭代产能 × 迭代次数 |
| 缓冲预留 | 15-20% | 用于处理突发需求和风险 |
| 可用产能 | {{AVAILABLE}} 人天 | = 总产能 × (1 - 缓冲比例) |
```

### 依赖关系图

梳理跨团队/跨系统的依赖，识别关键路径：

```
关键路径（决定最短交付时间的链路）：

Team A: [====Epic 1====]──→[===Epic 3===]──→[==Epic 5==]
                              ↑
Team B: [=====Epic 2=====]───┘        [==Epic 6==]
                                           ↑
Team C:          [===Epic 4===]────────────┘

关键路径：Epic 1 → Epic 3 → Epic 5（总工期 7 周）
瓶颈：Epic 3（同时被 Team A 和 Team B 依赖）
```

### 依赖类型

| 类型 | 说明 | 应对策略 |
|------|------|---------|
| **硬依赖** | B 必须等 A 完成才能开始 | A 优先排期，预留接口 |
| **软依赖** | B 最好等 A，但不等也能做 | B 先用 mock/hardcode |
| **资源依赖** | 同一个人/团队被多个 Epic 需要 | 排优先级，串行安排 |
| **外部依赖** | 依赖第三方/外部团队 | 提前沟通，留更多缓冲 |
| **数据依赖** | 需要某个数据/埋点先上线 | 数据先行 |

---

## 步骤四：风险与缓冲

### 风险识别

每个 Epic 和里程碑都要评估风险。使用以下框架：

```markdown
### 风险评估矩阵

| 风险 | 概率 | 影响 | 风险等级 | 缓解措施 | 负责人 |
|------|------|------|---------|---------|--------|
| {{RISK_1}} | 高/中/低 | 高/中/低 | 🔴/🟡/🟢 | {{MITIGATION}} | {{OWNER}} |
```

**风险等级判定：**

| | 影响低 | 影响中 | 影响高 |
|------|------|------|------|
| **概率高** | 🟡 中 | 🔴 高 | 🔴 高 |
| **概率中** | 🟢 低 | 🟡 中 | 🔴 高 |
| **概率低** | 🟢 低 | 🟢 低 | 🟡 中 |

### 缓冲策略

**不要把每个 Epic 的工作量加起来等于总产能。** 那是必延期的节奏。

```markdown
### 缓冲设计

| 策略 | 说明 | 适用场景 |
|------|------|---------|
| **产能缓冲** | 预留 15-20% 产能不排任务 | 所有项目 |
| **时间缓冲** | 在关键里程碑之间留 2-3 天空档 | 有硬依赖的项目 |
| **功能缓冲** | 划出 P2 需求，有余力就做没余力砍 | 需求不稳定的场景 |
| **技术缓冲** | 预留技术债务处理和重构时间 | 技术债严重的项目 |
| **人员缓冲** | 预留 1 人不排具体任务，做救火 | 团队 ≥ 5 人时 |

### 缓冲分配示例

```
季度 12 周总产能：240 人天
├── 确定性需求（Must + Should）：180 人天（75%）
├── 缓冲预留：36 人天（15%）
│   ├── 风险应对：18 人天
│   └── 突发需求：18 人天
└── 弹性需求（Could have）：24 人天（10%）
    └── 有余力就做，没余力砍
```

### 预案模板

对于每个高风险项，准备 Plan B：

```markdown
### 预案：[风险描述]

**触发条件：** [什么情况下启用预案]
**Plan A（首选）：** [正常方案]
**Plan B（降级）：** [缩减方案，砍掉什么]
**Plan C（兜底）：** [最低可接受方案]
**决策人：** [谁拍板切换方案]
**决策时间点：** [最晚什么时候必须决定]
```

---

## 每阶段成功指标

每个里程碑必须有**可量化、可验证**的成功指标，不是"完成了开发"。

### 指标设计原则

| 原则 | 说明 | 好的示例 | 坏的示例 |
|------|------|---------|---------|
| **可量化** | 有具体数字 | 日活从 1 万提升到 1.2 万 | 用户更满意 |
| **可归因** | 能明确归因到这个阶段的工作 | 新注册转化率提升 5% | 整体数据变好 |
| **有时限** | 有明确的检验时间点 | 上线后第 2 周验证 | 尽快验证 |
| **有方向** | 明确上升还是下降 | 次日留存 ≥ 40% | 留存要改善 |

### 指标分层

```markdown
### 里程碑成功指标

| 里程碑 | 北极星指标 | 过程指标 | 护栏指标 |
|--------|-----------|---------|---------|
| M1 | 注册转化率 ≥ 40% | 注册页面 PV/UV | 注册接口错误率 < 0.1% |
| M2 | 核心功能渗透率 ≥ 30% | 功能入口点击率 | 崩溃率 < 0.5% |
| M3 | 付费转化率 ≥ 3% | 付费页面停留时长 | 支付成功率 ≥ 99% |
```

- **北极星指标**：这个阶段最重要的一件事
- **过程指标**：验证用户是否在按预期使用
- **护栏指标**：不能变差的底线

---

## 输出格式

### 方案文档结构

最终产出一份**单文件 HTML 文档**：

```
1. 路线图概览 — 季度目标、关键数字、进度概览
2. 目标拆解 — OKR → Epic → Feature 层级
3. 里程碑时间线 — 甘特图样式的时间轴，标注状态
4. 依赖关系 — 跨团队依赖图、关键路径标注
5. 产能分配 — 团队产能 vs 需求量、缓冲设计
6. 风险矩阵 — 风险清单、等级、缓解措施、预案
7. 成功指标 — 每个里程碑的北极星/过程/护栏指标
8. 变更记录 — 版本变更历史
```

### 样式规范

- 配色：专业项目管理风格，主色 `#1a73e8`，成功 `#34a853`，警告 `#fbbc04`，错误 `#ea4335`，进行中 `#4285f4`
- 甘特图：用 CSS 实现（横向条形图），每个 Epic 一个色条，标注里程碑节点
- 依赖图：用 CSS/HTML 实现泳道图
- 状态标签：🔵未开始 🟡进行中 🟢已完成 🔴延期 ⚪取消
- 支持打印和移动端查看

### 交互功能

- 里程碑可展开查看详情
- 甘特图 hover 显示工期和负责人
- 风险矩阵可按等级筛选
- 右下角悬浮按钮 → 右侧面板展示 Markdown 格式路线图文档（支持一键复制）

### 读取模板

读取 `assets/roadmap-template.html` 作为方案文档的骨架。

---

## 设计文档面板（每个方案自动内嵌）

每份 HTML 路线图必须内嵌右下角悬浮按钮 + 右侧滑出设计文档面板。

### 组件

**FAB 按钮（fixed, 右下角）**

```html
<button class="doc-fab" id="docFab">
  <span class="doc-fab-label">路线图文档</span>
  <svg viewBox="0 0 24 24"><path d="M14 2H6a2 2 0 00-2 2v16a2 2 0 002 2h12a2 2 0 002-2V8z"/><polyline points="14 2 14 8 20 8"/><line x1="16" y1="13" x2="8" y2="13"/><line x1="16" y1="17" x2="8" y2="17"/><polyline points="10 9 9 9 8 9"/></svg>
</button>
```

样式：48px 圆形，主色背景 `#1a73e8`，白色图标，hover scale(1.08)。

**遮罩 + 右侧面板**（520px 宽，从右侧滑入，含「复制 Markdown」按钮）

### Markdown 文档模板

```markdown
# [产品/项目名称] Q{{QUARTER}} 路线图

> 日期：YYYY-MM-DD | 版本：v1.0 | 负责人：{{OWNER}}

---

## 1. 季度目标

| # | 目标 | 关键结果 | 优先级 |
|---|------|----------|--------|
| 1 | ... | ... | P0 |

## 2. Epic 拆解

| Epic | 周 | 团队 | 依赖 | 状态 |
|------|-----|------|------|------|
| ... | ... | ... | ... | ... |

## 3. 里程碑

| 里程碑 | 日期 | 交付物 | 成功指标 | 状态 |
|--------|------|--------|----------|------|
| M1 | ... | ... | ... | 🔵 |

## 4. 关键路径
{{CRITICAL_PATH}}

## 5. 产能分配
{{CAPACITY_ALLOCATION}}

## 6. 风险矩阵

| 风险 | 概率 | 影响 | 等级 | 缓解 |
|------|------|------|------|------|
| ... | ... | ... | ... | ... |

## 7. 缓冲策略
{{BUFFER_STRATEGY}}

## 8. 变更记录

| 版本 | 日期 | 变更 |
|------|------|------|
| v1.0 | ... | 初始版本 |
```

---

## 兜底策略

### 目标太多排不下

如果目标超出产能：
1. 按 MoSCoW 排优先级，砍掉 Won't have
2. 建议将部分目标推迟到下个季度
3. 如果必须全做，标注风险并建议增加资源
4. 明确告知"全做的话，延期概率 > 50%"

### 外部依赖不确定

如果依赖方无法给出明确时间：
1. 按"最悲观估计"排期
2. 准备不依赖外部方的 Plan B（如用 mock 数据、简化方案）
3. 在路线图上标注"外部依赖——待确认"

### 中途需求变更

路线图不是一成不变的，但要控制变更节奏：
1. 每两周可以调整一次（对齐 Sprint 节奏）
2. 任何变更必须说明：加什么、砍什么、对里程碑的影响
3. P0 需求可以随时插入，但必须等量砍掉另一个 P0/P1
4. 变更记录写入文档

---

## 质量检查项

- [ ] 季度目标清晰，每个目标有可量化的 KR
- [ ] 所有目标已拆解为 1-3 周粒度的 Epic
- [ ] Epic 之间的依赖关系已梳理
- [ ] 关键路径已标注
- [ ] 团队产能已量化计算，未超过可用产能
- [ ] 预留了 15-20% 缓冲
- [ ] 每个里程碑有明确的交付物和成功指标
- [ ] 高风险项有缓解措施和预案
- [ ] 方案文档有 FAB + 设计文档面板（含复制 Markdown）
- [ ] 文件保存在正确目录，命名格式 `MMDD-Q季度路线图.html`

---

## 上下游衔接

本 Skill 是 pm-skills 工作流的一环，由 `pm-master` 总控统一路由。

- **上游**：`pm-prioritization-engine`（Now/Next/Later 排序结果是理想输入）
- **下游**：`pm-postmortem-writer`（版本结束后复盘，路线图的「每阶段成功指标」即复盘的对照基线）

交接规则：链路模式下，完成后输出一段「交接摘要」（≤10 行：本步结论 + 下一步所需输入），供下一个 Skill 直接使用。