路线图更新

---
name: 路线图更新
description: >
  汇总迭代状态、评估里程碑进度、记录优先级变更，输出路线图更新报告和下一步规划建议。
  支持从~~项目管理（Linear）自动拉取项目状态。
  当用户说"路线图"、"Roadmap"、"版本规划"、"迭代计划"、"里程碑"、
  "迭代状态"、"版本进度"、"Sprint回顾"、"迭代周报"、"延期分析"时触发。
argument-hint: "输入当前迭代状态或需要更新的内容，如：本Sprint进度汇总"
name_en: "roadmap-update"
description_en: >
  Aggregate iteration status, assess milestone progress, log priority changes, and output a roadmap
  update report with forward-looking planning recommendations. Supports automatic status pull from
  ~~Project Management (Linear). Trigger when the user says "roadmap", "roadmap update", "release
  plan", "iteration plan", "milestone", "sprint status", "version progress", "sprint retro", "sprint
  report", "delay analysis", "update roadmap", "roadmap review".
---

# 路线图更新

汇总当前迭代状态、评估里程碑进度、追踪优先级变更和依赖关系，输出路线图状态总览和未来规划建议。帮助产品经理保持路线图的时效性和可执行性。

## 工作方式

**独立能力（无需连接器）**

- 迭代状态汇总（进行中/已完成/延期）
- 里程碑进度评估（按时/延迟/风险）
- 优先级变更记录和原因追踪
- 依赖关系识别和风险预警
- 未来2-3个迭代规划建议
- Now/Next/Later 路线图视图生成

**增强能力（连接器加持）**

- ~~Notion → 路线图报告写入团队知识库
- ~~项目管理（Linear） → 拉取项目/Cycle状态，自动同步进度

## 连接器（可选增强）

| 连接器 | 增强能力 |
|--------|---------|
| **Notion** | 路线图报告写入团队知识库 |
| **Linear** | 拉取Project/Cycle状态和Issue进度 |

> 没有连接器也完全可以使用。

## 输入要求

| 字段 | 必填 | 说明 |
|------|------|------|
| 迭代状态 | 是 | 当前迭代的任务完成情况（手动输入或从 Linear 自动拉取） |
| 路线图范围 | 否 | 本季度/本半年/本年，默认"本季度" |
| 变更事项 | 否 | 需要调整优先级或时间线的事项及原因 |
| 依赖信息 | 否 | 跨团队依赖、技术依赖的当前状态 |

## 执行流程

### 第一步：获取当前状态

**如果连接了~~项目管理（Linear）：**
1. 自动拉取当前Sprint/迭代的任务列表
2. 按状态分类：已完成/进行中/未开始/阻塞
3. 计算完成率和燃尽进度

**如果未连接：**
1. 请用户提供当前迭代的任务列表和状态
2. 接受任何格式：列表、表格、截图、口头描述

### 第二步：迭代状态汇总

**当前迭代总览**：

| 维度 | 数据 |
|------|------|
| 迭代名称/周期 | {Sprint X / 日期范围} |
| 计划任务数 | {N}个 |
| 已完成 | {X}个（{X/N%}） |
| 进行中 | {Y}个 |
| 未开始 | {Z}个 |
| 阻塞/延期 | {W}个 |
| 预计按时交付率 | {估算%} |

**延期任务分析**（如有）：

| 任务 | 原计划完成 | 预计完成 | 延期原因 | 影响评估 |
|------|----------|---------|---------|---------|
| {任务名} | {日期} | {日期} | {原因} | 是否影响里程碑 |

**延期根因分类（五类归因法）**：

| 根因类别 | 典型表现 | 改进方向 |
|---------|---------|---------|
| **需求变更** | 开发中途改需求、增加scope | 加强需求冻结机制，变更走审批 |
| **估算偏差** | 实际工作量远超预估 | 引入历史数据校准，增加Buffer |
| **技术风险** | 方案不可行、性能瓶颈、技术债阻碍 | 前置技术调研Spike |
| **依赖阻塞** | 等其他团队/第三方/审批 | 依赖前置2周预警机制 |
| **人力变动** | 请假、离职、临时抽调 | 容量规划留20%缓冲 |

> 如果同类延期原因连续出现3次以上，应升级为流程改进项。

### 第三步：里程碑进度评估

| 里程碑 | 目标日期 | 关键交付物 | 当前进度 | 状态 | 风险项 |
|--------|---------|----------|---------|------|--------|
| {里程碑1} | {日期} | {交付物} | {X%} | 按时/有风险/延迟 | {风险描述} |

**里程碑状态判断标准**：
- **按时**：进度>=时间进度，无阻塞依赖
- **有风险**：进度略落后或有未解决的依赖
- **延迟**：进度严重落后或关键依赖阻塞

### 第四步：优先级变更记录

| 变更项 | 变更类型 | 原优先级 | 新优先级 | 变更原因 | 影响范围 |
|--------|---------|---------|---------|---------|---------|
| {需求/任务} | 提升/降低/新增/移除 | {P0/P1/P2} | {P0/P1/P2} | {原因} | {影响了什么} |

**变更原因分类**：
- 用户反馈驱动（从 `/用户反馈分析` 获得新信息）
- 竞品动态驱动（从 `/竞品分析` 发现紧迫性变化）
- 数据驱动（从 `/产品指标复盘` 发现指标问题）
- 资源变化（团队人力变动、技术方案变更）
- 外部因素（政策合规要求、合作方需求）

### 第五步：依赖关系追踪

| 依赖项 | 类型 | 依赖方/提供方 | 需要日期 | 当前状态 | 风险等级 |
|--------|------|------------|---------|---------|---------|
| {依赖描述} | 技术/团队/外部 | {谁依赖谁} | {日期} | 已解决/进行中/阻塞 | 高/中/低 |

**依赖类型**：
- **技术依赖**：底层服务、API接口、基础设施
- **跨团队依赖**：其他业务线、设计团队、数据团队
- **外部依赖**：第三方服务、合作伙伴、审批流程

### 第六步：未来规划建议

基于当前状态，对未来2-3个迭代给出规划建议：

**路线图视图（Now / Next / Later）**：

| 时间段 | 事项 | 优先级 | 信心度 | 依赖 |
|--------|------|--------|--------|------|
| **Now**（当前迭代） | {进行中的工作} | 确定 | 高 | {已解决} |
| **Next**（下1-2个迭代） | {已规划的工作} | 确定/待定 | 中-高 | {需跟进} |
| **Later**（3+迭代后） | {方向性规划} | 方向性 | 低-中 | {待评估} |

**容量评估**：
- 下个迭代可用人力：{X}人天
- 建议分配：70%计划功能 + 20%技术债务 + 10%缓冲
- 结合当前延期项，建议下期优先处理：{列表}

**路线图健康度评分**（每次更新时计算）：

| 维度 | 权重 | 评分标准 | 得分 |
|------|------|---------|------|
| 按时交付率 | 30% | >80%=5分, 60-80%=3分, <60%=1分 | {X} |
| Scope稳定度 | 20% | 变更<10%=5分, 10-30%=3分, >30%=1分 | {X} |
| 依赖解决率 | 20% | >90%=5分, 70-90%=3分, <70%=1分 | {X} |
| OKR对齐度 | 15% | 所有工作可追溯到OKR=5分 | {X} |
| 团队信心 | 15% | 团队认为能按时交付=5分 | {X} |

**综合健康度**：加权总分 >=4分健康 / 3-4分有风险 / <3分需紧急调整

**Feature Cut决策框架**（当容量不足时的砍需求原则）：

| 优先砍的 | 原因 | 条件 |
|---------|------|------|
| Nice-to-have 功能 | 不影响核心价值 | 直接砍 |
| 可拆分功能的后半段 | 先交付MVP | 确认MVP独立可用 |
| 技术完美度 | 先能用再优化 | 不引入不可逆技术债 |
| 低置信度需求 | 未被验证的假设 | 标注"移入下期验证" |

> 原则：砍scope优于延期，延期优于加人（Brook's Law：向延期项目增加人手只会让它更延期）。

### 第七步：输出报告

**如果连接了~~Notion：**
1. 将路线图更新报告写入团队知识库

**如果未连接：**
1. 以Markdown格式输出完整报告

## 输出格式

```markdown
# 路线图更新报告

**更新日期**：{日期}
**覆盖周期**：{本季度/本半年}
**当前迭代**：{Sprint名称/日期}

## 一、当前迭代状态
完成率：{X%}（{已完成}/{总数}）
阻塞项：{N}个

## 二、里程碑进度
| 里程碑 | 目标日期 | 进度 | 状态 |
|--------|---------|------|------|

## 三、优先级变更
| 变更项 | 变更说明 | 原因 |
|--------|---------|------|

## 四、依赖与风险
- 高风险依赖：{描述}
- 需协调事项：{描述}

## 五、路线图视图（Now/Next/Later）
（表格）

## 六、下一步建议
1. {建议1}
2. {建议2}
3. {建议3}
```

## 质量标准

1. 状态信息准确——延期任务标明具体原因和预计完成时间
2. 里程碑评估有据——不用"差不多""快了"等模糊表述
3. 变更有追溯——每次优先级调整记录原因和决策人
4. 风险提前预警——不等问题发生才报告
5. 建议具体可行——下一步行动明确到人
6. 健康度评分持续追踪——可观察改善趋势

## 路线图沟通指南

不同受众需要不同粒度和视角的路线图信息：

| 受众 | 关注点 | 呈现方式 | 更新频率 |
|------|--------|---------|---------|
| **CEO/VP** | 战略方向、里程碑、风险 | Now/Next/Later高层视图 | 月度 |
| **研发团队** | Sprint任务、依赖、技术细节 | 详细任务列表+依赖图 | 每日/每周 |
| **销售/客户成功** | 客户承诺的功能、ETA | 功能上线时间线 | 月度 |
| **外部客户** | 即将推出的能力 | 季度主题（不承诺具体日期） | 季度 |

**路线图沟通三不原则**：
1. 不对外承诺具体日期——只承诺"Q2"不承诺"4月15日"
2. 不隐藏延期信息——早报比晚报好
3. 不把路线图当承诺——路线图是计划，计划会变

## 红线规则

1. **不隐瞒延期**：有延期如实报告，不报喜不报忧
2. **不做虚假承诺**：对未来时间线不过度乐观
3. **不忽略依赖**：跨团队依赖必须显式追踪

## 输入不足处理

- **无具体任务列表**：请用户至少提供里程碑和关键交付物的状态
- **不清楚优先级变更**：仅输出当前状态汇总，标注"建议补充变更记录"
- **首次使用无历史数据**：帮助建立路线图基线框架

## 相关技能

- `/需求优先级排序`：路线图中的需求重新排序
- `/产品指标复盘`：指标复盘结果影响路线图调整
- `/产品脑暴`：路线图中的创新方向探索