Публичная roadmap из вашего issue-трекера, три колонки

Публичная roadmap — это список того, что вы намерены построить, опубликованный там, где клиенты могут его увидеть. Слово, выполняющее работу, — намерены: roadmap — это набор обещаний о будущем, и каждый элемент в ней — тот, который вы либо сдержите, либо станет видно, что не сдержали. Это причина публиковать её, и это также причина, по которой большинство публичных roadmap устаревают за квартал. Версия, которая выживает, маленькая, выведена из данных, которые вы уже поддерживаете, и связана на другом конце с changelog, чтобы обещание становилось фактом без того, чтобы кто-то его повторно вводил.

Для чего нужна публичная roadmap?

Публичная roadmap говорит клиентке с запросом, что её запрос услышан, до его выпуска. Это ранняя половина замыкания петли: «Запланировано» отвечает на вопрос «прочитал ли это кто-то», а «В разработке» отвечает на «действительно ли это происходит». Ни одно из них не заменяет последний шаг, уведомление запросившей при выпуске, но оба уменьшают число людей, спрашивающих тем временем.

Это также делает кое-что для команды: заставляет публичное обязательство, что является самым дешёвым известным лекарством против backlog, тихо хранящего четыреста элементов, которые никто не построит.

Трёх колонок в фиксированном порядке достаточно. Четвёртая колонка («рассматривается», «на рецензии», «backlog») — место, где благие намерения становятся музеем, и это первая, которую клиенты учатся игнорировать.

Должна ли ваша roadmap быть публичной?

Сделайте её публичной, если вы можете держать её маленькой и честной; держите её приватной, если альтернатива — длинный список возможно. Цена публичной roadmap не имеет ничего общего с её публикацией: каждый элемент на ней теперь вопрос, который кто-то задаст, в поддержке, в звонках продаж и в разговорах о продлении. Десять элементов, которые вы построите, — это актив. Шестьдесят элементов, которые вы, возможно, построите, — это шестьдесят будущих разговоров о том, почему нет.

Две честные причины не публиковать: ваши планы меняются быстрее квартала, или ваши конкуренты читают вашу roadmap внимательнее ваших клиентов. Обе реальны, и обе решаются публикацией меньшего вместо ничего: только «в разработке», с «запланировано», держимым внутренним, всё равно говорит запросившей, что её issue движется.

Как построить публичную roadmap из issue GitHub?

Поместите одну метку на колонку на issue, которые вы уже отслеживаете, и отрендерите помеченные issue как roadmap. Ничто не вводится повторно, roadmap не может отклониться от работы, и один и тот же issue, начавшийся как запрос клиента, движется через колонки, не меняя идентичность.

Механизм, как мы его выполняем:

1. Одна метка на колонку, с фиксированным префиксом: roadmap:planned, roadmap:building, roadmap:shipped. Любой issue в подключённом репозитории, несущий одну из них, появляется в этой колонке. Issue без ни одной из них не на roadmap, что верно для большинства issue, что правильно.
2. Колонки — это упорядоченный массив, всегда в одном порядке. Запланировано, в разработке, выпущено. Не карта, индексированная по имени, чтобы читательнице (или виджету) никогда не пришлось угадывать последовательность.
3. Если issue несёт две метки, побеждает наиболее продвинутая. Кто-то добавит roadmap:shipped до удаления roadmap:planned; конечный автомат, руководимый «какой webhook пришёл последним», поместил бы элемент в разные колонки в зависимости от порядка доставки. Решение только из набора меток делает ответ одинаковым независимо от того, как приходят события.
4. Выпущено это такое же состояние метки, как и остальные. Карточка перемещается, когда issue получает roadmap:shipped или закрывается, пока эта метка на нём стоит. Сама карточка не ссылается на запись changelog; подробности живут в записи, составленной из pull request, закрывшего issue.
5. Подавайте её как данные. Roadmap — это документ JSON с этими тремя колонками, опубликованный рядом с лентой changelog с теми же заголовками кэша, чтобы сайт документации, виджет или страница статуса могли отрендерить её без второй интеграции. Документация ленты имеет точную форму.

Метка — это немного, о чём просить мейнтейнера, и это вся интеграция. Никакой доски для поддержания синхронизации, никакого отдельного инструмента для входа, и запрос, поданный клиенткой, является элементом на roadmap; при выпуске это тот же элемент.

Что публичная roadmap не должна содержать?

Она не должна содержать даты, оценки, или что-либо, о чём вам было бы стыдно, если бы спросили через девять месяцев. Даты — классическая ошибка: квартал на roadmap становится обязательством в презентации продаж становится тикетом под названием «вы сказали Q3». Колонки говорят достаточно. «В разработке» уже означает «достаточно скоро, что кто-то этим занимается».

Она также не должна содержать внутренний backlog. Roadmap с тремястами элементов — это проблема поиска, не обещание, и клиентка, находящая свой запрос на позиции 212, узнала кое-что, что вы не хотели ей говорить.

Как roadmap связывается с changelog?

Roadmap и changelog описывают одни и те же issue с двух сторон, одна для будущего, другая для прошлого. Никто не двигает карточку на отдельной доске. Мейнтейнер меняет метку на issue, с которым уже работал, запись составляется из pull request, а когда человек одобряет запись, запросившая, чей отзыв из виджета стал этим issue, уведомляется на нём. Перевод карточки в выпущено остаётся отдельным шагом, меткой roadmap:shipped, так что сделайте его частью того же ревью; одобрение записи не делает этого за вас.

Это та же петля, которую статья о петле обратной связи описывает со стороны changelog; roadmap — это то, что клиентка видит посередине этого. Обзор инструменты для changelog охватывает, какие продукты предлагают представление roadmap, а какие относятся к ней как к отдельной доске, что и есть разница, решающая, остаётся ли она точной.

Как выглядит хорошая публичная roadmap?

Она выглядит короткой, и каждый элемент на ней — это issue, который может открыть любой. Тест — может ли клиентка перейти от элемента к обсуждению за ним, и от выпущенного элемента к записи, описывающей, что на самом деле изменилось. Roadmap, являющаяся списком названий функций без входа, — это брошюра.

Проработанный пример, как 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"
}

Три элемента в трёх колонках — это вполне достаточная публичная roadmap. Она говорит, что грядёт, что происходит, и что произошло, и каждая строка проверяема. Ещё пять форматов, от Now/Next/Later до roadmap по результатам, показаны на примерах пунктов в статье примеры product roadmap.

FAQ

Сколько элементов должна иметь публичная roadmap? Настолько мало, насколько вы можете защитить. Меньше десяти в общей сложности нормально для маленького продукта; больше тридцати в «запланировано» обычно backlog, замаскированный под roadmap.

Должна ли публичная roadmap иметь даты? Нет. Колонки сообщают последовательность, не создавая дедлайн. Если клиентке нужна дата, это разговор, а не элемент roadmap.

Должны ли клиенты голосовать за элементы roadmap? Голоса измеряют, кто пришёл, а не что важно. Комментарий на issue, объясняющий обходной путь, который они используют сегодня, стоит больше пятидесяти голосов, и стоит что-то голосующему, что и есть суть.

Что происходит с отменённым элементом roadmap? Удалите метку и скажите почему на issue. Публичное «мы не будем это делать» — часть петли, и это сообщение, которое большинство команд никогда не отправляют.

Технические утверждения в этой статье не проходили независимую проверку. Если здесь что-то не так, сообщите нам, и мы исправим.

По теме на changeloop: Документация для разработчиков, Сравнение инструментов changelog