ahang1598 路线图更新
汇总当前迭代状态、评估里程碑进度、追踪优先级变更和依赖关系，输出路线图状态总览和未来规划建议。帮助产品经理保持路线图的时效性和可执行性。
工作方式
独立能力（无需连接器）
- 迭代状态汇总（进行中/已完成/延期）
- 里程碑进度评估（按时/延迟/风险）
- 优先级变更记录和原因追踪
- 依赖关系识别和风险预警
- 未来2-3个迭代规划建议
- Now/Next/Later 路线图视图生成
增强能力（连接器加持）
- ~~Notion → 路线图报告写入团队知识库
- ~~项目管理（Linear） → 拉取项目/Cycle状态，自动同步进度
连接器（可选增强）
| 连接器 | 增强能力 |
|---|---|
| Notion | 路线图报告写入团队知识库 |
| Linear | 拉取Project/Cycle状态和Issue进度 |
没有连接器也完全可以使用。
输入要求
| 字段 | 必填 | 说明 |
|---|---|---|
| 迭代状态 | 是 | 当前迭代的任务完成情况（手动输入或从 Linear 自动拉取） |
| 路线图范围 | 否 | 本季度/本半年/本年，默认"本季度" |
| 变更事项 | 否 | 需要调整优先级或时间线的事项及原因 |
| 依赖信息 | 否 | 跨团队依赖、技术依赖的当前状态 |
执行流程
第一步：获取当前状态
如果连接了~~项目管理（Linear）：
- 自动拉取当前Sprint/迭代的任务列表
- 按状态分类：已完成/进行中/未开始/阻塞
- 计算完成率和燃尽进度
如果未连接：
- 请用户提供当前迭代的任务列表和状态
- 接受任何格式：列表、表格、截图、口头描述
第二步：迭代状态汇总
当前迭代总览：
| 维度 | 数据 |
|---|---|
| 迭代名称/周期 | {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：
- 将路线图更新报告写入团队知识库
如果未连接：
- 以Markdown格式输出完整报告
输出格式
# 路线图更新报告
**更新日期**：{日期}
**覆盖周期**：{本季度/本半年}
**当前迭代**：{Sprint名称/日期}
## 一、当前迭代状态
完成率：{X%}（{已完成}/{总数}）
阻塞项：{N}个
## 二、里程碑进度
| 里程碑 | 目标日期 | 进度 | 状态 |
|--------|---------|------|------|
## 三、优先级变更
| 变更项 | 变更说明 | 原因 |
|--------|---------|------|
## 四、依赖与风险
- 高风险依赖：{描述}
- 需协调事项：{描述}
## 五、路线图视图（Now/Next/Later）
（表格）
## 六、下一步建议
1. {建议1}
2. {建议2}
3. {建议3}
质量标准
- 状态信息准确——延期任务标明具体原因和预计完成时间
- 里程碑评估有据——不用"差不多""快了"等模糊表述
- 变更有追溯——每次优先级调整记录原因和决策人
- 风险提前预警——不等问题发生才报告
- 建议具体可行——下一步行动明确到人
- 健康度评分持续追踪——可观察改善趋势
路线图沟通指南
不同受众需要不同粒度和视角的路线图信息：
| 受众 | 关注点 | 呈现方式 | 更新频率 |
|---|---|---|---|
| CEO/VP | 战略方向、里程碑、风险 | Now/Next/Later高层视图 | 月度 |
| 研发团队 | Sprint任务、依赖、技术细节 | 详细任务列表+依赖图 | 每日/每周 |
| 销售/客户成功 | 客户承诺的功能、ETA | 功能上线时间线 | 月度 |
| 外部客户 | 即将推出的能力 | 季度主题（不承诺具体日期） | 季度 |
路线图沟通三不原则：
- 不对外承诺具体日期——只承诺"Q2"不承诺"4月15日"
- 不隐藏延期信息——早报比晚报好
- 不把路线图当承诺——路线图是计划，计划会变
红线规则
- 不隐瞒延期：有延期如实报告，不报喜不报忧
- 不做虚假承诺：对未来时间线不过度乐观
- 不忽略依赖：跨团队依赖必须显式追踪
输入不足处理
- 无具体任务列表：请用户至少提供里程碑和关键交付物的状态
- 不清楚优先级变更：仅输出当前状态汇总，标注"建议补充变更记录"
- 首次使用无历史数据：帮助建立路线图基线框架
相关技能
/需求优先级排序：路线图中的需求重新排序/产品指标复盘：指标复盘结果影响路线图调整/产品脑暴：路线图中的创新方向探索