用 issue 追踪系统打造三列式公开路线图
阅读约 1 分钟
公开路线图，是一份你打算构建的东西的清单，发布在客户能够看到的地方。真正在起作用的那个词是打算：路线图是一系列关于未来的承诺，上面的每一项，要么会被你兑现，要么会被人看出来你没有兑现。这正是发布它的理由，也正是大多数公开路线图会在一个季度之内就变得陈旧过时的原因。能够存活下来的版本很精简，源自你已经在维护的数据，并且在另一端连接到体验日志上，这样一份承诺就能在没有人重新录入它的情况下变成一个事实。
公开路线图是用来做什么的
公开路线图会告诉一个提出请求的客户，他的请求在上线之前就已经被听到了。这是闭合循环的前半部分：“计划中”回答的是”有没有人读到过这个”，而”构建中”回答的是”这件事是不是真的在发生”。这两者都不能替代最后一步——在上线时告诉请求者——但两者都能减少在此期间不断询问进度的人数。
它还为团队做了一件事：它强制形成一种公开的承诺，这是已知最廉价的一种疗法，用来对付那种悄悄囤积着四百个没人会去做的项目的积压清单。
| 列 | 它做出的承诺 | 什么会把一个项目移进这一列 |
|---|---|---|
| 计划中 | 我们打算构建这个 | 一个决定，以 issue 上的一个标签形式被记录下来 |
| 构建中 | 现在有人正在做这件事 | issue 上的 roadmap:building 标签 |
| 已发布 | 它已经上线了 | 一个 roadmap:shipped 标签，或者在带着这个标签时关闭 issue |
固定顺序的三列就足够了。第四列（“考虑中”、“审核中”、“积压清单”）正是好意最终变成一座博物馆的地方，也是客户最先学会忽略的那一列。
应该把路线图公开吗
如果能让它保持精简和诚实，就公开它；如果替代方案是一份很长的、都是”也许会做”的清单，那就把它保持私有。一份公开路线图的代价，和发布它这个动作本身无关：它上面的每一项，现在都成了一个会有人在支持团队、销售电话和续约谈话里问起的问题。你确实会构建的十个项目是一份资产。你也许会构建的六十个项目，则是六十场关于”为什么没做”的未来对话。
有两个诚实的、不公开路线图的理由：你的计划变化得比一个季度还快，或者你的竞争对手比你的客户还更仔细地读你的路线图。这两个理由都是真实的，而两者的应对方式都是公开得更少一点，而不是完全不公开：只公开”构建中”，把”计划中”留在内部，依然能告诉请求者他们的 issue 正在推进。
如何从 GitHub issue 构建一份公开路线图
在你已经在追踪的那些 issue 上，为每一列贴一个标签，然后把带标签的 issue 渲染成路线图。什么都不需要重新录入，路线图也不可能与实际工作脱节，而那个最初作为客户请求出现的 issue，会在各列之间移动，却不需要改变身份。
我们运行的这套机制是这样的：
- 每一列一个标签，带一个固定前缀：
roadmap:planned、roadmap:building、roadmap:shipped。在一个已连接的仓库里，任何带有其中一个标签的 issue 都会出现在那一列。三个标签都没有的 issue，就不在路线图上，而这正是大多数 issue 的情况，这样也是对的。 - 列是一个有顺序的数组，永远保持同样的顺序。 计划中、构建中、已发布。不是一个按名字作为键的映射，所以读者（或者一个小组件）永远不需要去猜测这个顺序。
- 当一个 issue 同时带有两个标签时，更靠后的那个胜出。 有人会在移除
roadmap:planned之前，先添加roadmap:shipped；一个由”哪个 webhook 最后到达”来驱动的状态机，会因为事件到达顺序的不同，把这个项目放进不同的列里。仅仅根据标签集合本身来判断，能保证无论事件以什么顺序到达，答案都是一样的。 - 已发布和其他列一样，是一种标签状态。 当 issue 被打上
roadmap:shipped，或者在带着这个标签时被关闭，卡片就会移动。卡片本身不会链接到体验日志条目；细节写在那条条目里，它是从关闭这个 issue 的 pull request 起草而来的。 - 把它作为数据来提供。 路线图是一份带有这三列的 JSON 文档，和体验日志信息流一起、带着相同的缓存标头发布出来，这样一个文档网站、一个小组件，或者一个状态页面，都可以在不需要第二次集成的情况下渲染它。信息流文档里有确切的格式。
对维护者来说，贴一个标签是一件很小的事，而它就是整个集成方案的全部。不需要一个要保持同步的看板，不需要登录一个独立的工具，客户提交的那个请求，就是路线图上的那个项目；等它上线时，还是同一个项目。
公开路线图不应该包含什么
它不应该包含日期、估算，或者任何九个月后被问起时会让你尴尬的东西。日期是最经典的错误：路线图上的一个季度，会变成销售资料里的一份承诺，再变成一张标题为”你说过是 Q3”的工单。列本身已经说得够清楚了。“构建中”本身就已经意味着”快到已经有人在做了”。
它也不应该包含内部的积压清单。一份有三百个项目的路线图是一个搜索问题，而不是一份承诺，而那个在第 212 个位置找到自己请求的客户，也了解到了一件你原本并不打算告诉他的事情。
路线图是怎样和体验日志连接起来的
路线图和体验日志从两个侧面描述同一批 issue，一种面向未来，一种面向过去。没有人在一个单独的看板上移动卡片。维护者在自己本来就在处理的那个 issue 上改一下标签，条目会从 pull request 起草，而当一个人批准了这条条目，其小组件反馈变成了这个 issue 的请求者，会在这个 issue 上收到通知。把卡片移到已发布仍然是单独的一步，也就是 roadmap:shipped 标签，所以要把它纳入同一次审核；批准条目并不会替你完成这一步。
这正是反馈循环那篇文章从体验日志一侧所描述的同一个循环；路线图则是客户在这个过程中间所看到的东西。体验日志工具的汇总介绍了哪些产品提供了路线图视图，哪些把它当作一个独立的看板来对待，而这正是决定它能否保持准确的关键差异。
一份好的公开路线图应该是什么样的
它看起来很简短，上面的每一项都是一个任何人都可以打开的 issue。检验标准是：客户能不能从一个项目找到它背后的讨论，能不能从一个已发布的项目找到那条真正描述了实际变化的条目。一份只有功能名称、却没有任何入口的路线图，只不过是一份宣传册。
以下是一个具体的示例，作为一个小组件会去获取的 JSON：
{
"columns": [
{ "column": "planned", "hasMore": false, "items": [
{ "id": "6b0c1f...", "column": "planned",
"publicTitle": "Saved views on the inbox",
"publicDescription": "Keep a filter you use often and come back to it.",
"publishedAt": "2026-09-16T10:04:11.000Z" }
]},
{ "column": "building", "hasMore": false, "items": [
{ "id": "71a4e2...", "column": "building",
"publicTitle": "Roadmap column in the widget",
"publicDescription": "See what is coming without leaving the page.",
"publishedAt": "2026-09-12T08:20:02.000Z" }
]},
{ "column": "shipped", "hasMore": false, "items": [
{ "id": "5c9d70...", "column": "shipped",
"publicTitle": "Feedback filed as labelled issues",
"publicDescription": "Widget submissions arrive as issues your triage already handles.",
"publishedAt": "2026-09-02T15:41:37.000Z" }
]}
],
"enabled": true,
"language": "en"
}三列共三个项目，就是一份完全合格的公开路线图。它说明了什么即将到来、什么正在发生、什么已经发生，而且每一行都是可以核实的。从 Now/Next/Later 到结果式，另外五种版式及其示例条目，见产品路线图示例。
FAQ
一份公开路线图应该有多少个项目? 能站得住脚的、越少越好。对一个小产品来说，所有列加起来不到十个是正常的；“计划中”超过三十个，就是一份披着路线图外衣的积压清单。
公开路线图应该带日期吗? 不应该。列能在不设定截止日期的情况下传达先后顺序。如果客户需要一个日期，那应该是一次对话，而不是路线图上的一个项目。
客户应该给路线图项目投票吗? 投票衡量的是谁出现了，而不是什么才重要。一条评论，说明他们今天正在使用的那个变通方案，比五十张投票更有价值，而且它需要投票者付出一点代价，这正是关键所在。
一个被取消的路线图项目会怎样? 移除标签，并在 issue 上说明原因。一句公开的”我们不会做这件事”是这个循环的一部分，也是大多数团队从来不会去发送的那条消息。
本文的技术内容未经独立审核。如有错误，请告诉我们，我们会更正。