roadmap-backcast

反向规划路线图

目录

1. 工作流
2. 依赖关系映射
3. 关键路径分析
4. 常见模式
5. 防护措施
6. 快速参考

工作流

复制此清单并跟踪进度：

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”）
• 明确梳理依赖关系（而非想当然）
• 确定关键路径（了解哪些工作决定时间线）
• 诚实评估可行性（而非一厢情愿）
• 记录风险（哪些因素可能延长时间线？）
• 为每个里程碑指定负责人（明确责任）

快速参考

资源：

• 快速倒推计划：resources/template.md
• 复杂路线图：resources/methodology.md
• 质量评估标准：resources/evaluators/rubric_roadmap_backcast.json

5 步流程：定义目标 → 倒推计划 → 梳理依赖关系 → 找出关键路径 → 评估可行性

依赖类型：顺序执行（A→B）| 并行（A∥B）| 汇聚（A,B→C）| 分支（A→B,C）

关键路径：最长的依赖序列 = 项目最短工期

缓冲规则：在估算时间上增加 20-30%；高不确定性工作增加 40% 以上

可行性测试：所需时间 ≤ 可用时间（含缓冲）