Back to Details

technical-roadmaps

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Technical Roadmaps

技术路线图

Scope

范围

Covers
  • Turning “technical work” (architecture, platform, reliability, tech debt) into a written strategy + roadmap that stakeholders can critique and improve.
  • Applying Richard Rumelt’s strategy frame (Diagnosis → Guiding policy → Coherent actions) to engineering planning.
  • Producing a roadmap that is executable (owners, milestones, dependencies, risks, metrics), not a vague wishlist.
  • Aligning a technical roadmap with product/business constraints (quarters, launches, compliance/security, capacity).
When to use
  • “Create a technical/engineering/architecture roadmap for the next 2–4 quarters.”
  • “We need a written technical strategy and a roadmap we can review with leadership.”
  • “We have many tech-debt/platform initiatives; turn them into a prioritized plan with dependencies and milestones.”
  • “Our tech roadmap keeps being misunderstood—write it down so we can debug alignment.”
When NOT to use
  • The problem/outcome is unclear (use 
    problem-definition
    first).
  • You need to choose which product bets matter most (use 
    prioritizing-roadmap
    or 
    ai-product-strategy
    ).
  • You only need delivery dates, milestone tracking, and RAG governance (use 
    managing-timelines
    ).
  • You need a deep platform strategy / ecosystem design (use 
    platform-strategy
    ).
涵盖
  • 将“技术工作”（架构、平台、可靠性、技术债务）转化为利益相关者可以评审和改进的书面策略+路线图。
  • 将Richard Rumelt的策略框架（诊断→指导方针→连贯行动）应用于工程规划。
  • 生成可执行的路线图（包含负责人、里程碑、依赖项、风险、指标），而非模糊的愿望清单。
  • 使技术路线图与产品/业务约束（季度周期、发布计划、合规/安全要求、资源容量）保持一致。
适用场景
  • “为未来2-4个季度创建技术/工程/架构路线图。”
  • “我们需要一份可与领导层评审的书面技术策略和路线图。”
  • “我们有许多技术债务/平台举措；将它们转化为包含依赖项和里程碑的优先级计划。”
  • “我们的技术路线图一直被误解——把它写下来，以便我们梳理对齐问题。”
不适用场景
  • 问题/成果不明确（请先使用
    problem-definition
    ）。
  • 需要选择最重要的产品赌注（请使用
    prioritizing-roadmap
    或
    ai-product-strategy
    ）。
  • 仅需要交付日期、里程碑跟踪和RAG治理（请使用
    managing-timelines
    ）。
  • 需要深度平台策略/生态系统设计（请使用
    platform-strategy
    ）。

Inputs

输入

Minimum required
  • Audience + decision: who this roadmap is for (Eng leadership, Execs, Product) and what decisions it must enable.
  • Time horizon + format: e.g., 6 months / 12 months; Now-Next-Later vs quarterly.
  • Current-state diagnosis inputs: top pain points, reliability/latency/cost signals, incident themes, scaling constraints, key architectural bottlenecks.
  • Constraints: capacity assumptions, compliance/security requirements, platform constraints, non-negotiables.
  • Candidate initiatives: known platform/architecture/tech-debt items (even a rough list).
Missing-info strategy
  • Ask up to 5 questions from references/INTAKE.md.
  • If answers aren’t available, proceed with explicit assumptions and list them under Open questions.
最低要求
  • 受众+决策：该路线图的受众（工程领导层、高管、产品团队）以及它需要支持的决策。
  • 时间范围+格式：例如，6个月/12个月；“当前-下一步-未来” vs 季度格式。
  • 当前状态诊断输入：核心痛点、可靠性/延迟/成本信号、事件主题、扩展约束、关键架构瓶颈。
  • 约束条件：资源容量假设、合规/安全要求、平台限制、不可协商事项。
  • 候选举措：已知的平台/架构/技术债务事项（即使是粗略列表）。
缺失信息处理策略
  • 从references/INTAKE.md中提出最多5个问题。
  • 如果无法获得答案，则基于明确的假设继续推进，并将这些假设列在未解决问题下。

Outputs (deliverables)

输出（交付物）

Produce a Technical Roadmap Pack in Markdown (in-chat; or as files if the user requests):
  1. Technical Strategy (Rumelt): Diagnosis → Guiding policy → Coherent actions (template: references/TEMPLATES.md)
  2. Roadmap table (Now/Next/Later or quarters) with owners, dependencies, milestones, confidence, and metrics
  3. Initiative briefs for the top 3–6 roadmap items (1 page each)
  4. Dependency + risk register (top cross-team deps, key risks, mitigations)
  5. Alignment + governance plan (review cadence, update rules, decision owners, comms template)
  6. Risks / Open questions / Next steps (always included)
Expanded guidance: references/WORKFLOW.md
生成Markdown格式的技术路线图包（在对话中；或根据用户请求以文件形式提供）：
  1. 技术策略（Rumelt式）：诊断→指导方针→连贯行动（模板：references/TEMPLATES.md）
  2. 路线图表格（“当前-下一步-未来”或季度格式），包含负责人、依赖项、里程碑、置信度和指标
  3. 举措简报：针对路线图中排名前3-6的事项（每项1页）
  4. 依赖项+风险登记册（核心跨团队依赖项、关键风险、缓解措施）
  5. 对齐+治理计划（评审节奏、更新规则、决策负责人、沟通模板）
  6. 风险/未解决问题/后续步骤（始终包含）
扩展指南：references/WORKFLOW.md

Workflow (7 steps)

工作流程（7个步骤）

1) Intake + audience alignment

1) 需求收集+受众对齐

  • Inputs: User request; references/INTAKE.md.
  • Actions: Confirm the audience, horizon, and roadmap “shape” (quarters vs Now/Next/Later). Identify the decision the roadmap must enable (funding, sequencing, headcount, trade-offs).
  • Outputs: Intake summary + explicit assumptions + open questions list (if any).
  • Checks: You can state: “This roadmap is for <audience> to decide <decision> over <horizon> using <format>.”
  • 输入：用户请求；references/INTAKE.md。
  • 行动：确认受众、时间范围和路线图“形态”（季度 vs “当前-下一步-未来”）。明确路线图需要支持的决策（资金、排序、人员编制、权衡）。
  • 输出：需求收集摘要+明确假设+未解决问题列表（如有）。
  • 检查：你可以表述为：“本路线图面向<受众>，用于在<时间范围>内通过<格式>支持<决策>。”

2) Write the strategy (Rumelt: Diagnosis → Guiding policy → Coherent actions)

2) 撰写策略（Rumelt式：诊断→指导方针→连贯行动）

  • Inputs: Current-state signals; constraints; product/business context.
  • Actions: Draft a written strategy using the Rumelt structure. Keep it concrete: name the constraints and trade-offs.
  • Outputs: Technical Strategy section using references/TEMPLATES.md.
  • Checks: A reader can answer: “What’s the problem?”, “What’s our approach?”, “What actions are we taking (and not taking)?”
  • 输入：当前状态信号；约束条件；产品/业务背景。
  • 行动：使用Rumelt结构撰写书面策略。确保内容具体：明确约束条件和权衡。
  • 输出：使用references/TEMPLATES.md的技术策略部分。
  • 检查：读者可以回答：“问题是什么？”、“我们的方法是什么？”、“我们将采取（及不采取）哪些行动？”

3) Build the initiative inventory (candidate “coherent actions”)

3) 构建举措清单（候选“连贯行动”）

  • Inputs: Candidate initiative list; strategy; incidents/metrics; architecture notes.
  • Actions: Normalize initiatives into a table (theme, outcome, why now, dependencies, effort, risk). Merge duplicates; split overly broad items.
  • Outputs: Initiative inventory (draft roadmap backlog).
  • Checks: Each item has an outcome + a “why now” tied back to the Diagnosis/Guiding policy.
  • 输入：候选举措列表；策略；事件/指标；架构说明。
  • 行动：将举措标准化为表格（主题、成果、为何现在推进、依赖项、工作量、风险）。合并重复项；拆分过于宽泛的事项。
  • 输出：举措清单（路线图待办事项草稿）。
  • 检查：每个事项都有成果，且“为何现在推进”与诊断/指导方针相关联。

4) Prioritize + sequence (make trade-offs explicit)

4) 优先级排序+排期（明确权衡）

  • Inputs: Inventory; constraints; dependencies; capacity assumptions.
  • Actions: Prioritize based on: (a) alignment to strategy, (b) risk reduction, (c) enabling product work, (d) cost/effort, (e) dependency criticality. Sequence via dependencies and “first unlocks.”
  • Outputs: Ranked list + sequencing rationale + explicit non-goals/cut list.
  • Checks: You can justify the top 3 items in 1–2 sentences each, including what you deprioritized.
  • 输入：举措清单；约束条件；依赖项；资源容量假设。
  • 行动：基于以下因素排序：(a) 与策略的对齐度，(b) 风险降低程度，(c) 对产品工作的支持能力，(d) 成本/工作量，(e) 依赖项关键程度。根据依赖项和“前置解锁项”进行排期。
  • 输出：排名列表+排期理由+明确的非目标/裁剪列表。
  • 检查：你可以用1-2句话为排名前3的事项提供理由，包括你优先排除的内容。

5) Convert into a roadmap (quarters or Now/Next/Later) with execution detail

5) 转化为带执行细节的路线图（季度或“当前-下一步-未来”格式）

  • Inputs: Ranked list; sequencing; calendar constraints.
  • Actions: Create the roadmap table with owners, milestones, dependencies, confidence, and success metrics. Add “decision gates” where uncertainty is high.
  • Outputs: Roadmap table + milestone highlights.
  • Checks: A team could start execution without guessing owners/dependencies; high-uncertainty items have a gate (spike/RFC/prototype).
  • 输入：排名列表；排期；日历约束。
  • 行动：创建包含负责人、里程碑、依赖项、置信度和成功指标的路线图表格。在不确定性高的地方添加“决策节点”。
  • 输出：路线图表格+里程碑重点。
  • 检查：团队无需猜测负责人/依赖项即可启动执行；高不确定性事项设有节点（探索性研究/RFC/原型）。

6) Draft initiative briefs + alignment plan

6) 起草举措简报+对齐计划

  • Inputs: Roadmap; top items; stakeholder map.
  • Actions: Write 1-page briefs for the top 3–6 items and a comms/governance plan (review cadence, update rules, decision owners).
  • Outputs: Initiative briefs + alignment/governance section (templates in references/TEMPLATES.md).
  • Checks: Stakeholders know when/how the roadmap will change and what inputs trigger a refresh.
  • 输入：路线图；核心事项；利益相关者图谱。
  • 行动：为排名前3-6的事项撰写1页简报，并制定沟通/治理计划（评审节奏、更新规则、决策负责人）。
  • 输出：举措简报+对齐/治理部分（模板在references/TEMPLATES.md中）。
  • 检查：利益相关者知道路线图何时及如何变更，以及哪些输入会触发更新。

7) Quality gate + finalize

7) 质量校验+最终定稿

  • Inputs: Full draft pack.
  • Actions: Run references/CHECKLISTS.md and score with references/RUBRIC.md. Ensure Risks / Open questions / Next steps are present with owners and dates where possible.
  • Outputs: Final Technical Roadmap Pack.
  • Checks: The pack is “debuggable”: written, coherent, measurable, and reviewable.
  • 输入：完整的路线图包草稿。
  • 行动：运行references/CHECKLISTS.md并使用references/RUBRIC.md评分。确保风险/未解决问题/后续步骤已包含，尽可能附上负责人和日期。
  • 输出：最终技术路线图包。
  • 检查：该包是“可调试的”：书面化、连贯、可衡量且可评审。

Quality gate (required)

质量校验（必填）

  • Use references/CHECKLISTS.md and references/RUBRIC.md.
  • Always include: Risks, Open questions, Next steps.
  • 使用references/CHECKLISTS.md和references/RUBRIC.md。
  • 始终包含：风险、未解决问题、后续步骤。

Examples

示例

Example 1 (platform scaling): “We’re seeing reliability issues and slow delivery. Create a 2-quarter technical roadmap and strategy we can review with leadership.”
Expected: a Rumelt-structured strategy plus a sequenced roadmap with owners, dependencies, milestones, and metrics.
Example 2 (architecture modernization): “We need an architecture roadmap to migrate off a legacy monolith while still shipping product features.”
Expected: explicit trade-offs, dependency-aware sequencing, decision gates, and a governance cadence to keep alignment.
Boundary example: “Write a detailed project plan with dates for every task for the next 6 months.”
Response: use 
managing-timelines
for delivery planning; this skill is for strategy → roadmap (themes/initiatives/milestones), not task-level scheduling.
示例1（平台扩展）：“我们遇到了可靠性问题和交付缓慢的情况。创建一份可与领导层评审的2季度技术路线图和策略。”
预期输出：采用Rumelt结构的策略，加上包含负责人、依赖项、里程碑和指标的排期路线图。
示例2（架构现代化）：“我们需要一份架构路线图，在持续交付产品功能的同时迁移出遗留单体系统。”
预期输出：明确的权衡、考虑依赖项的排期、决策节点，以及用于保持对齐的治理节奏。
边界示例：“为未来6个月的每个任务撰写详细的项目计划和日期。”
回应：使用
managing-timelines
进行交付规划；本技能适用于从策略到路线图（主题/举措/里程碑）的工作，而非任务级别的调度。