mcpField
R
roadmap-backcast

roadmap-backcast

github.com/nicepkg生产力28847 次安装40 周前更新
代码仓库

关于 roadmap-backcast

该技能帮助团队从明确的目标或截止日期倒推路线图,拆解里程碑、依赖关系与关键路径,并评估计划是否可行。适用于产品发布、合规期限和跨团队项目。

主要功能

  1. 01从目标倒推里程碑
  2. 02梳理任务依赖与并行关系
  3. 03识别关键路径
  4. 04评估时间与资源可行性
  5. 05根据风险调整计划

适用场景

  1. 01制定固定日期的产品发布计划
  2. 02规划合规整改工作
  3. 03协调跨职能团队的里程碑
  4. 04安排多阶段转型计划

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/nicepkg/ai-workflow --skill roadmap-backcast

安装后在 Claude Code 中输入/roadmap-backcast确认已加载。

包含的文件

除 SKILL.md 外,安装时一起下载的参考资料和脚本。

resources/
methodology.md
template.md
resources/evaluators/
rubric_roadmap_backcast.json

详细介绍

路线图倒推

目录

  1. 目的
  2. 适用场景
  3. 这是什么
  4. 工作流
  5. 依赖关系映射
  6. 关键路径分析
  7. 常见模式
  8. 防护措施
  9. 快速参考

目的

路线图倒推可帮助你从固定目标或截止日期向前倒推至当前,找出所需的里程碑、依赖关系、关键路径和可行性约束。它将理想化的目标转化为可执行、有序的计划。

适用场景

在以下情况下调用此技能:

  • 规划固定截止日期前的工作(产品发布、活动、合规日期)
  • 从战略目标倒推至当前阶段的步骤
  • 梳理复杂项目的依赖关系和执行顺序
  • 找出关键路径(决定时间线的最长任务序列)
  • 评估雄心勃勃的时间线是否可行
  • 协调跨职能团队,共同达成里程碑
  • 规划包含阶段性检查点的多年转型
  • 安排相互依赖的项目的执行顺序
  • 为相互依赖的工作流分配资源

可能触发此技能的用户说法:

  • “我们需要在 [date] 前发布”
  • “从目标开始倒推”
  • “要实现 [outcome],需要完成哪些工作?”
  • “从目标倒推计划”
  • “截止日期固定,哪些事情可行?”
  • “从 [future state] 倒推”
  • “交付的关键路径”

这是什么

一种倒推式路线图,它:

  1. 定义最终状态(具体、可衡量的目标结果和日期)
  2. 向前倒推(在这之前一步必须满足什么条件?再之前呢?)
  3. 确定里程碑(包含明确交付成果的关键检查点)
  4. 梳理依赖关系(哪些事项相互依赖,哪些可以并行)
  5. 找出关键路径(决定最短时间线的最长链条)
  6. 评估可行性(我们能否在目标日期前切实达成目标?)

快速示例(于 2025 年第一季度前发布产品):

  • 目标:产品于 2025 年 1 月 31 日前上线生产环境,服务 1000 名客户
  • T-4 周(1 月 3 日):完成 50 名客户的 Beta 测试,修复关键 Bug
  • T-8 周(12 月 6 日):功能完成,通过内部 QA
  • T-12 周(11 月 8 日):构建 MVP,核心功能正常运行
  • T-16 周(10 月 11 日):完成设计,定义 API 合同
  • T-20 周(9 月 13 日):锁定需求,团队人员到位
  • 今天(9 月 1 日):若没有范围蔓延,且预留 20% 的时间缓冲,则可行

工作流

复制此清单并跟踪进度:

Roadmap Backcast Progress:
- [ ] Step 1: Define target outcome precisely
- [ ] Step 2: Work backward to identify milestones
- [ ] Step 3: Map dependencies and sequencing
- [ ] Step 4: Identify critical path
- [ ] Step 5: Assess feasibility and adjust

步骤 1:精确定义目标结果

说明具体结果(而非模糊目标)、目标日期和成功标准。结果定义示例请参阅常见模式。对于简单的倒推计划 → 使用 resources/template.md。

步骤 2:向前倒推并确定里程碑

从终点开始,反复询问“在此之前必须满足什么条件?”。制定 5-10 个主要里程碑。对于复杂的多年路线图 → 阅读 resources/methodology.md。

步骤 3:梳理依赖关系和执行顺序

确定哪些事项相互依赖,哪些可以并行。技术请参阅依赖关系映射。

步骤 4:确定关键路径

找出依赖任务中最长的序列(它决定最短时间线)。请参阅关键路径分析。

步骤 5:评估可行性并进行调整

将所需时间线与可用时间进行比较。增加缓冲时间(20-30%),找出风险,并在必要时调整范围或日期。定稿前,使用 resources/evaluators/rubric_roadmap_backcast.json 进行自检。最低标准:平均分数 ≥ 3.5。

依赖关系映射

依赖类型:

顺序依赖(A → B):A 完成后,B 才能开始

  • 示例:必须先完成设计,工程工作才能开始
  • 对关键路径的影响:延长时间线
  • 缓解措施:尽早启动 A,并在安全的情况下并行推进

并行依赖(A ∥ B):A 和 B 可以同时进行

  • 示例:后端和前端开发
  • 对关键路径的影响:无(资源充足时)
  • 优势:缩短整体时间线

汇合依赖(A、B → C):A 和 B 都完成后,C 才能开始

  • 示例:测试需要代码完成且测试环境就绪
  • 对关键路径的影响:C 必须等待 A 或 B 中较慢的一项
  • 缓解措施:监控两条路径,加快较慢的一条

分支依赖(A → B、C):A 为 B 和 C 提供条件

  • 示例:定义 API 契约后,前端和后端工作都可以开始
  • 对关键路径的影响:A 的延迟会导致其后所有工作延迟
  • 缓解措施:优先处理 A,确保质量过关以避免返工

关键路径分析

关键路径:依赖任务中最长的序列(决定项目的最短工期)

确定关键路径:

  1. 列出所有里程碑及其持续时间
  2. 绘制依赖关系图(箭头从前置任务指向依赖任务)
  3. 计算每个里程碑的最早开始和最早完成时间(正向推算)
  4. 计算每个里程碑的最晚开始和最晚完成时间(反向推算)
  5. 时差为零(最早时间 = 最晚时间)的里程碑位于关键路径上

示例:

Milestone A (4 weeks) → Milestone B (6 weeks) → Milestone D (2 weeks) = 12 weeks (critical path)
Milestone A (4 weeks) → Milestone C (3 weeks) → Milestone D (2 weeks) = 9 weeks (non-critical, 3 weeks slack)

关键路径为 12 周(A→B→D 路径)

管理关键路径:

  • 密切监控:关键路径上的延迟会直接导致项目延迟
  • 增加缓冲时间:为关键路径任务增加 20-30% 的缓冲(墨菲定律)
  • 资源优先级:优先为关键路径配备人员
  • 快速跟进:能否推迟非关键工作来支持关键路径?
  • 赶工:增加资源以缩短关键路径(收益递减,且布鲁克斯定律适用)

常见模式

模式 1:有固定日期的产品发布

  • 目标:在指定日期上线产品并为客户提供服务
  • 关键里程碑(倒推):正式发布、Beta 测试、功能冻结、Alpha 测试、MVP、完成设计、锁定需求
  • 关键路径:通常是设计 → 工程 → 测试(顺序依赖)
  • 缓冲时间:工程阶段增加 20-30%(应对未知因素),测试阶段增加 20%(应对缺陷)

模式 2:合规截止期限(监管)

  • 目标:在监管截止期限前实现合规(不能延期)
  • 关键里程碑:通过审计、实施控制措施、更新政策、完成差距分析
  • 关键路径:差距分析 → 补救 → 验证
  • 缓冲时间:增加 40% 以上(监管风险不容忽视,应预留额外时间)

模式 3:战略转型(多年期)

  • 目标:实现未来愿景(例如,“到 2027 年实现云原生架构”)
  • 关键里程碑(按年):第 3 年(完成全面迁移)、第 2 年(完成 50% 迁移)、第 1 年(完成试点)、第 0 年(批准战略)
  • 关键路径:基础工作(试点、经验总结)为规模化扩展提供条件
  • 缓冲时间:每个阶段增加 30% 以上(未知因素会随着时间推移而累积)

模式 4:活动规划(会议、发布活动)

  • 目标:活动按期举行,参会者获得良好体验
  • 关键里程碑:活动日、彩排、内容就绪、确认演讲者、预订场地、公布日期
  • 关键路径:场地预订(准备周期长)通常位于关键路径上
  • 缓冲时间:增加 10-20%(活动有严格的截止日期,灵活性较低)

护栏

可行性检查:

  • 可用时间 ≥ 所需时间:如果倒推时间线回溯到今天之前,目标就不可行
  • 包含缓冲时间:在估算基础上增加 20-30%(霍夫施塔特定律:“即使你考虑到了霍夫施塔特定律,事情所花的时间仍然总会比预期更长。”)
  • 依赖关系切合实际:依赖项是否真的能按顺序完成(交接时间、返工)?
  • 资源限制:我们是否有足够的人力和预算,在需要时并行推进?

常见陷阱:

  • 乐观地安排顺序:假设交接完美、无需返工、没有阻碍
  • 忽视依赖关系:“我们可以同时开始所有工作” → 实际上高度依赖顺序
  • 没有缓冲时间:没有任何余量的计划会在遇到第一个小问题时就失败
  • 范围蔓延:执行期间目标成果不断扩大,导致反向规划失效
  • 沉没成本谬误:反向规划显示不可行时,应调整范围或日期(不要一味推进)

质量标准:

  • 里程碑有明确的交付成果(而非“正在处理 X”)
  • 明确梳理依赖关系(而非想当然)
  • 确定关键路径(明确哪些因素决定时间线)
  • 诚实评估可行性(而非一厢情愿)
  • 记录风险(哪些因素可能延长时间线?)
  • 为每个里程碑指派负责人(明确责任)

快速参考

资源:

5 步流程:定义目标 → 反向规划 → 梳理依赖关系 → 找出关键路径 → 评估可行性

依赖关系类型:顺序(A→B)| 并行(A∥B)| 汇聚(A,B→C)| 分叉(A→B,C)

关键路径:最长的依赖序列 = 项目最短持续时间

缓冲规则:在估算基础上增加 20-30%,不确定性较高的工作增加 40% 以上

可行性检验:所需时间 ≤ 可用时间(包含缓冲时间)

评论

支持 Markdown