Publiczna roadmapa z waszego trackera issue, trzy kolumny

Publiczna roadmapa to lista tego, co zamierzacie zbudować, opublikowana tam, gdzie klienci mogą ją zobaczyć. Słowo, które wykonuje pracę, to zamierzacie: roadmapa to zbiór obietnic na przyszłość, a każdy element na niej jest tym, którego dotrzymacie albo widoczne stanie się, że nie dotrzymaliście. To powód, by ją opublikować, i to też powód, dla którego większość publicznych roadmap starzeje się w ciągu kwartału. Wersja, która przetrwa, jest mała, wyprowadzona z danych, które już utrzymujecie, i połączona na drugim końcu z changelogiem, żeby obietnica stała się faktem bez ponownego jej wprowadzania przez kogokolwiek.

Do czego służy publiczna roadmapa?

Publiczna roadmapa mówi klientce z prośbą, że jej prośba została wysłuchana, zanim zostanie wydana. To wczesna połowa zamykania pętli: “Zaplanowane” odpowiada na pytanie “czy ktoś to przeczytał”, a “W budowie” odpowiada na “czy to naprawdę się dzieje”. Żadne z nich nie zastępuje ostatniego kroku, poinformowania proszącej osoby, gdy zostanie wydane, ale oba zmniejszają liczbę ludzi pytających w międzyczasie.

Robi też coś dla zespołu: wymusza publiczne zobowiązanie, co jest najtańszym znanym lekarstwem na backlog, który cicho przechowuje czterysta elementów, których nikt nie zbuduje.

Trzy kolumny, w stałej kolejności, wystarczą. Czwarta kolumna (“rozważane”, “w przeglądzie”, “backlog”) to miejsce, gdzie dobre intencje stają się muzeum, i to ta, którą klienci uczą się ignorować jako pierwszą.

Czy wasza roadmapa powinna być publiczna?

Zróbcie ją publiczną, jeśli możecie utrzymać ją małą i uczciwą; trzymajcie ją prywatną, jeśli alternatywą jest długa lista może-może. Koszt publicznej roadmapy nie ma nic wspólnego z jej publikacją: każdy element na niej to teraz pytanie, które ktoś zada, we wsparciu, w rozmowach sprzedażowych i w rozmowach o odnowieniu. Dziesięć elementów, które zbudujecie, to aktywo. Sześćdziesiąt elementów, które być może zbudujecie, to sześćdziesiąt przyszłych rozmów o tym, dlaczego nie.

Dwa uczciwe powody, by nie publikować: wasze plany zmieniają się szybciej niż kwartał, albo konkurencja czyta waszą roadmapę uważniej niż wasi klienci. Oba są prawdziwe, i oba są rozwiązywane przez publikowanie mniej zamiast niczego: tylko “w budowie”, z “zaplanowane” trzymanym wewnętrznie, wciąż mówi proszącej osobie, że jej issue się porusza.

Jak zbudować publiczną roadmapę z issue GitHuba?

Umieśćcie jedną etykietę na kolumnę na issue, które już śledzicie, i renderujcie oznakowane issue jako roadmapę. Nic nie jest ponownie wprowadzane, roadmapa nie może odbiec od pracy, a to samo issue, które zaczęło jako prośba klienta, porusza się przez kolumny bez zmiany tożsamości.

Mechanizm, tak jak go prowadzimy:

1. Jedna etykieta na kolumnę, ze stałym prefiksem: roadmap:planned, roadmap:building, roadmap:shipped. Każde issue w połączonym repozytorium, które niesie jedną z nich, pojawia się w tej kolumnie. Issue bez żadnej z nich nie jest na roadmapie, co dotyczy większości issue, co jest poprawne.
2. Kolumny to uporządkowana tablica, zawsze w tej samej kolejności. Zaplanowane, w budowie, wydane. Nie mapa indeksowana nazwą, żeby czytelniczka (lub widget) nigdy nie musiała zgadywać kolejności.
3. Jeśli issue niesie dwie etykiety, wygrywa dalej posunięta. Ktoś doda roadmap:shipped przed usunięciem roadmap:planned; maszyna stanów kierowana przez “który webhook przybył ostatni” umieściłaby element w różnych kolumnach w zależności od kolejności dostarczania. Decydowanie tylko na podstawie zbioru etykiet sprawia, że odpowiedź jest taka sama niezależnie od tego, jak przychodzą zdarzenia.
4. Wydane to stan etykiety jak każdy inny. Karta przesuwa się, gdy issue dostaje roadmap:shipped albo zostaje zamknięte, mając tę etykietę. Sama karta nie linkuje do wpisu changelogu; szczegóły są we wpisie, przygotowanym z pull requesta, który zamknął issue.
5. Serwujcie ją jako dane. Roadmapa to dokument JSON z tymi trzema kolumnami, publikowany obok kanału changelogu z tymi samymi nagłówkami cache, żeby strona dokumentacji, widget lub strona statusu mogły ją wyrenderować bez drugiej integracji. Dokumentacja kanału ma dokładny kształt.

Etykieta to niewiele, o co prosić maintainerkę, i to cała integracja. Żadnej tablicy do utrzymywania w synchronizacji, żadnego oddzielnego narzędzia do logowania się, a prośba, którą zgłosiła klientka, jest elementem na roadmapie; gdy zostanie wydana, to ten sam element.

Czego publiczna roadmapa nie powinna zawierać?

Nie powinna zawierać dat, szacunków, ani niczego, czego zapytanie o to za dziewięć miesięcy by was zawstydziło. Daty to klasyczny błąd: kwartał na roadmapie staje się zobowiązaniem w prezentacji sprzedażowej staje się ticketem nazwanym “powiedzieliście Q3”. Kolumny mówią wystarczająco. “W budowie” już oznacza “wystarczająco szybko, żeby ktoś nad tym siedział”.

Nie powinna też zawierać wewnętrznego backlogu. Roadmapa z trzystoma elementami to problem wyszukiwania, nie obietnica, a klientka, która znajduje swoją prośbę na pozycji 212, dowiedziała się czegoś, czego nie chcieliście jej powiedzieć.

Jak roadmapa łączy się z changelogiem?

Roadmapa i changelog opisują te same issue z dwóch stron: roadmapa przyszłość, changelog przeszłość. Nikt nie przesuwa karty na osobnej tablicy. Maintainerka zmienia etykietę na issue, nad którym już pracowała, wpis jest przygotowywany z pull requesta, a gdy osoba zatwierdza wpis, proszący, którego feedback z widgetu stał się tym issue, jest na nim informowany. Przesunięcie karty do wydanych to wciąż osobny krok, etykieta roadmap:shipped, więc zróbcie go w ramach tej samej recenzji; zatwierdzenie wpisu nie zrobi tego za was.

To ta sama pętla, którą opisuje artykuł o pętli feedbacku od strony changelogu; roadmapa to to, co klientka widzi pośrodku tego. Zestawienie narzędzia do changelogu obejmuje, które produkty oferują widok roadmapy, a które traktują ją jako oddzielną tablicę, co jest różnicą decydującą, czy pozostaje dokładna.

Jak wygląda dobra publiczna roadmapa?

Wygląda krótko, a każdy element na niej to issue, które każdy może otworzyć. Test polega na tym, czy klientka może przejść od elementu do dyskusji za nim, i od wydanego elementu do wpisu, który opisuje, co faktycznie się zmieniło. Roadmapa będąca listą nazw funkcji bez wejścia to broszura.

Rozwinięty przykład, jako JSON, który pobrałby widget:

{
  "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"
}

Trzy elementy w trzech kolumnach to doskonale dobra publiczna roadmapa. Mówi, co nadchodzi, co się dzieje, i co się stało, a każda linia jest sprawdzalna. Pięć innych układów, od Now/Next/Later po wynikowy, pokazano z przykładowymi pozycjami w przykładach roadmapy produktu.

FAQ

Ile elementów powinna mieć publiczna roadmapa? Tak mało, jak możecie obronić. Poniżej dziesięciu łącznie jest normalne dla małego produktu; ponad trzydzieści w “zaplanowane” to zwykle backlog przebrany za roadmapę.

Czy publiczna roadmapa powinna mieć daty? Nie. Kolumny komunikują kolejność bez tworzenia terminu. Jeśli klientka potrzebuje daty, to rozmowa, nie element roadmapy.

Czy klienci powinni głosować na elementy roadmapy? Głosy mierzą, kto się pojawił, nie co ma znaczenie. Komentarz na issue wyjaśniający obejście, którego używają dzisiaj, jest wart więcej niż pięćdziesiąt głosów, i kosztuje głosującego coś, co jest sedno sprawy.

Co się dzieje z anulowanym elementem roadmapy? Usuńcie etykietę i powiedzcie dlaczego na issue. Publiczne “nie zrobimy tego” jest częścią pętli, i to wiadomość, której większość zespołów nigdy nie wysyła.

Twierdzenia techniczne w tym artykule nie zostały niezależnie zweryfikowane. Jeśli coś się nie zgadza, daj nam znać, a poprawimy to.

Powiązane w changeloop: Dokumentacja dla deweloperów, Porównanie narzędzi do changeloga