技术路线图示例：平台团队的 Now、Next、Later 规划

技术路线图失败的方式通常有两种。一种是满是没人相信的日期、每个季度都要重画一遍的甘特图；另一种是在开头加了个标题的待办事项导出。两者都没有告诉依赖你的团队：现在在做什么、接下来做什么、哪些事还没决定。

平台团队的处境比大多数团队更难。它们的截止日期往往由别人决定，比如某个 Kubernetes 或 PostgreSQL 版本的支持终止。它们的客户是其他工程团队，每个团队都有自己的需求。而且它们的工作充满了长周期迁移，往往几个月都处于“快完成了”的状态。

本文以 Now、Next、Later（现在、接下来、以后）的形式为一个平台团队制定技术路线图，说明这种形式的来历、为什么适合技术工作，以及如何运作它，让它始终保持真实。

为什么用 Now、Next、Later

这种形式来自 ProdPad。联合创始人 Janna Bastow 在 The Birth of the Modern Roadmap 一文中讲述了 2012 年底前后，另一位联合创始人 Simon Cast 在一张餐巾纸上画出三列的经过：Current、Near term 和 Future。这些列是时间跨度，背后的理念是确定性：第一列的工作清晰而临近，最后一列的工作范围还很模糊。他们把它做进了 ProdPad，称为 Now-Next-Later 路线图。

这些列表示的是确定性，而不是日历上的季度。事项向左移动，是因为你已经知道足够多、可以做出承诺，而不是因为某个季度结束了。

技术路线图有何不同

外部截止日期。 你运行的软件都有支持窗口，而这个窗口决定了你的工作顺序。Kubernetes 项目维护最近的三个次要版本，每个版本大约有一年的补丁支持。因此升级是路线图上反复出现的事项，而不是一次性项目；而且 kubeadm 集群不支持跳过次要版本升级，所以从 1.35 升到 1.37 需要两次升级。PostgreSQL 为每个主要版本提供五年支持；之后会发布最后一个次要版本，该版本随即结束生命周期。

内部客户。 流对齐团队会根据平台将交付什么来做计划。他们需要知道哪些已经承诺、哪些没有，而这正是这些列要说明的。

长尾。 一次完成了 90% 的迁移，仍然会有数据库或服务停留在旧版本上。用剩下要迁移的内容来展示进度，而不是用日期。

依赖关系。 平台工作常常建立在其他平台工作之上。内置链路追踪的服务模板，在链路追踪能用之前无法发布。

写成果，而不是项目

把每个事项写成你想要的结果，让任何人都能判断它何时完成：

在事项描述中加上衡量指标：导出链路追踪数据的服务数、运行受支持版本的集群数、仍在 15 版本上的数据库数。

示例：一个平台团队的路线图

这个示例的时间是 2026 年 10 月，所以其中的截止日期都是 Kubernetes 和 PostgreSQL 版本页面上的真实日期。

• Now。 Traces everywhere，即 OpenTelemetry 的推广，大约完成了三分之一，而且因为团队还需要一名工程师而存在风险。Kubernetes 1.37 正在进行：Kubernetes 1.35 将在 2027 年 2 月 28 日结束生命周期，这个日期落在 Next 的时间窗口内，所以升级必须现在做。
• Next。 Golden path 是一个内置 CI/CD、链路追踪和仪表板的服务模板，它在等待链路追踪。Off PostgreSQL 15 是一次使用 pg_upgrade 升级到 18 版本的主要版本升级，要赶在 15 版本于 2027 年 11 月 11 日结束生命周期之前完成。
• Later。 两个有待探索的问题：让每个团队的云成本可见，以及让结账服务能扛过整个区域的故障。两者都还没有负责人或解决方案。

这张图的读法如下：

• 列表示确定性，而不是季度。 从左到右，工作从已承诺，到很可能做，再到尚未决定。
• 每张卡片都是一个成果， 带有负责人、状态和进度条。Later 中的事项还没有负责人；它们是问题，不是计划。
• 依赖标记表明链路追踪阻塞了 Golden path，因为模板默认开启链路追踪。
• 里程碑是外部截止日期， 放在它所落入的那一列。Kubernetes 1.35 的支持在 Next 期间结束，所以它的升级放在 Now。PostgreSQL 15 的支持在 Later 期间结束，所以它的升级从 Next 开始，为长尾留出时间。
• 状态标签说明了风险：链路追踪需要增派人手。

如何运作

• 按固定节奏评审， 例如每两周一次，与你所服务团队的负责人一起评审。只在评审时移动事项，这样路线图不会在大家脚下悄悄变化。
• 让 Now 保持精简。 只放团队有人手去做的事。有新事项进入 Now，就要有别的事项移出。
• 只有成形的事项才能从 Later 升到 Next： 要有问题描述、完成标准、负责人和大致规模。
• 日期只用于外部截止日期。 内部估算以区间的形式写在事项描述里，而不是作为承诺写在路线图上。
• 已完成的事项只展示一次， 在下一次评审时展示，然后归档。路线图关注的是前方的工作。
• 把事项链接到详细信息： 设计文档、迁移跟踪表、架构图。CI/CD 流水线图和 Kubernetes 架构图两篇文章展示了这些图可以是什么样子。

常见错误

• 带日期的功能清单。 它会把不确定性一直藏到某个日期延误，然后所有人同时知道。
• 所有事都放在 Now。 如果有十个事项同时进行，那就等于一个都没在进行。
• 没有负责人。 Now 或 Next 中没有负责人的事项只是愿望。
• 隐藏的依赖。 如果一个事项需要另一个事项，就把依赖画出来。否则第二个事项开工后就会卡住。
• 只在紧急时才出现的升级。 从采用某个版本的那天起，就把你所依赖的每个支持窗口作为里程碑放到路线图上。
• 没人看的路线图。 把它放在大家日常工作的地方，并嵌入到文档中，而不是粘贴一张会过时的截图。

在 Archboard 中构建

1. 使用 Google 或 GitHub 登录，并新建一张图，或者从 Now / Next / Later 路线图模板开始。
2. 添加路线图节点包中的三个 季度 框架，并分别命名为 Now、Next 和 Later。
3. 为每个成果添加一个 史诗，并设置标题、负责人、状态和进度。
4. 为每个外部截止日期添加一个带日期的 里程碑，放在它所落入的那一列。
5. 在一个阻塞另一个的两个史诗之间添加一个 依赖 标记，并用虚线连线把它们连起来。
6. 为风险添加一个 状态标签，并添加基础节点包中的一个 便签，写明每一列的规则。

这个示例共用 13 个图表节点，在 Free 套餐的限制之内。

常见问题

技术路线图和产品路线图有什么区别？ 产品路线图关注客户能得到什么。技术路线图关注让这一切成为可能的能力、升级和迁移，它的客户通常是其他工程团队。两者可以使用相同的形式。

技术路线图应该有日期吗？ 只在日期真实存在的地方使用：支持终止、合同或法规。其他一切都放进按确定性划分的列中。

Later 应该覆盖多远的未来？ 没有固定的时间跨度。Later 存放的是问题，所以要让它足够精简，确保每个事项在下一次评审时仍然值得讨论。

如何展示长周期迁移的进度？ 统计剩下要迁移的内容，比如集群、服务或数据库，并在每次评审时更新这个数字。没有数量的百分比会掩盖长尾。

谁应该看到平台路线图？ 所有依赖平台的人。把它分享给你所服务的团队，并与他们的负责人一起评审，让他们可以围绕已承诺的内容做计划。

免费开始 — 1 个席位，无需信用卡。