Veřejná roadmap z vašeho issue trackeru, tři sloupce

Veřejná roadmap je seznam toho, co plánujete postavit, zveřejněný tam, kde ho zákazníci mohou vidět. Slovo, které odvádí práci, je plánujete: roadmap je sada slibů o budoucnosti, a každá položka na ní je taková, kterou buď dodržíte, nebo se ukáže, že jste ji nedodrželi. To je důvod ji zveřejnit, a je to také důvod, proč většina veřejných roadmap zastarává během čtvrtletí. Verze, která přežije, je malá, odvozená z dat, která už udržujete, a propojená na druhém konci s changelogem, aby se slib stal faktem, aniž by ho kdokoli znovu zadával.

K čemu je veřejná roadmap?

Veřejná roadmap říká zákaznici s požadavkem, že její požadavek byl vyslyšen, ještě než je vydán. Je to raná polovina uzavírání smyčky: «Plánováno» odpovídá na otázku «přečetl si to někdo», a «Ve vývoji» odpovídá na «děje se to skutečně». Ani jedno nenahrazuje poslední krok, informování žadatelky při vydání, ale oba snižují počet lidí, kteří se mezitím ptají.

Dělá také něco pro tým: vynucuje veřejný závazek, což je nejlevnější známý lék proti backlogu, který tiše uchovává čtyři sta položek, které nikdo nepostaví.

Tři sloupce, v pevném pořadí, stačí. Čtvrtý sloupec («zvažováno», «na revizi», «backlog») je místo, kde se dobré úmysly stávají muzeem, a je to první, který se zákazníci naučí ignorovat.

Měla by být vaše roadmap veřejná?

Udělejte ji veřejnou, pokud ji dokážete udržet malou a upřímnou; udržujte ji soukromou, pokud je alternativou dlouhý seznam možná. Cena veřejné roadmapy nemá nic společného s jejím zveřejněním: každá položka na ní je teď otázka, kterou někdo položí, v podpoře, v prodejních hovorech a v rozhovorech o obnovení. Deset položek, které postavíte, je aktivum. Šedesát položek, které možná postavíte, je šedesát budoucích rozhovorů o tom, proč ne.

Dva upřímné důvody nezveřejňovat: vaše plány se mění rychleji než čtvrtletí, nebo vaše konkurence čte vaši roadmapu pozorněji než vaši zákazníci. Oba jsou skutečné, a oba jsou zodpovězeny zveřejněním méně místo ničeho: jen «ve vývoji», s «plánováno» drženým interně, stále říká žadatelce, že se její issue hýbe.

Jak se buduje veřejná roadmap z issue GitHubu?

Umístěte jeden štítek na sloupec na issue, které už sledujete, a vykreslete označené issue jako roadmapu. Nic se znovu nezadává, roadmap se nemůže odchýlit od práce, a stejné issue, které začalo jako požadavek zákazníka, se pohybuje sloupci, aniž by měnilo identitu.

Mechanismus, jak ho provádíme:

1. Jeden štítek na sloupec, s pevnou předponou: roadmap:planned, roadmap:building, roadmap:shipped. Jakékoli issue v připojeném repozitáři, které nese jeden z nich, se objeví v tom sloupci. Issue bez žádného z nich není na roadmapě, což platí pro většinu issue, což je správné.
2. Sloupce jsou uspořádané pole, vždy ve stejném pořadí. Plánováno, ve vývoji, vydáno. Ne mapa indexovaná podle jména, aby čtenářka (nebo widget) nikdy nemusela hádat pořadí.
3. Pokud issue nese dva štítky, vyhrává ten pokročilejší. Někdo přidá roadmap:shipped dřív, než odstraní roadmap:planned; stavový automat řízený «kterým webhookem přišel poslední» by umístil položku do různých sloupců v závislosti na pořadí doručení. Rozhodování jen ze sady štítků činí odpověď stejnou bez ohledu na to, jak události přicházejí.
4. Vydáno je stav štítku jako ostatní. Karta se posune, když issue dostane roadmap:shipped, nebo je uzavřeno, zatímco ho nese. Samotná karta na záznam changelogu neodkazuje; podrobnosti jsou v záznamu, sestaveném z pull requestu, který issue uzavřel.
5. Poskytujte ji jako data. Roadmap je dokument JSON s těmito třemi sloupci, zveřejněný vedle kanálu changelogu se stejnými hlavičkami cache, aby web dokumentace, widget nebo stránka stavu ji mohly vykreslit bez druhé integrace. Dokumentace kanálu má přesný tvar.

Štítek je maličkost, o kterou žádat správce, a je to celá integrace. Žádná deska k udržování v synchronizaci, žádný samostatný nástroj pro přihlašování, a požadavek, který zákaznice podala, je položka na roadmapě; při vydání je to stejná položka.

Co by veřejná roadmap neměla obsahovat?

Neměla by obsahovat data, odhady, nebo cokoli, za co byste se styděli, kdyby se vás na to zeptali za devět měsíců. Data jsou klasická chyba: čtvrtletí na roadmapě se stane závazkem v prodejní prezentaci se stane ticketem s názvem «řekli jste Q3». Sloupce říkají dost. «Ve vývoji» už znamená «dost brzy na to, aby na tom někdo pracoval».

Neměla by také obsahovat interní backlog. Roadmap s tři sty položkami je problém hledání, ne slib, a zákaznice, která najde svůj požadavek na pozici 212, se dozvěděla něco, co jste jí říct nechtěli.

Jak se roadmap propojuje s changelogem?

Roadmap a changelog popisují stejná issue ze dvou stran, jeden pro budoucnost a jeden pro minulost. Nikdo neposouvá kartu na samostatné desce. Správkyně změní štítek na issue, na kterém už pracovala, záznam se sestaví z pull requestu, a když člověk záznam schválí, žadatelka, jejíž zpětná vazba z widgetu se stala tímto issue, je na něm informována. Přesun karty do vydaného je pořád samostatný krok, štítek roadmap:shipped, takže ho udělejte v rámci stejné revize; schválení záznamu to za vás neudělá.

Je to stejná smyčka, kterou článek o smyčce zpětné vazby popisuje ze strany changelogu; roadmap je to, co zákaznice vidí uprostřed toho. Přehled nástroje pro changelog pokrývá, které produkty nabízejí pohled roadmapy a které s ní zacházejí jako se samostatnou deskou, což je rozdíl, který rozhoduje, zda zůstane přesná.

Jak vypadá dobrá veřejná roadmap?

Vypadá krátce, a každá položka na ní je issue, které může kdokoli otevřít. Test je, zda se zákaznice dostane z položky k diskusi za ní, a z vydané položky k záznamu, který popisuje, co se skutečně změnilo. Roadmap, která je seznamem názvů funkcí bez vstupu, je brožura.

Propracovaný příklad, jako JSON, který by widget stáhl:

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

Tři položky ve třech sloupcích jsou zcela dobrá veřejná roadmap. Říká, co přichází, co se děje, a co se stalo, a každý řádek je ověřitelný. Pět dalších rozvržení, od Now/Next/Later po výsledkové, je ukázáno s ukázkovými položkami v článku příklady produktové roadmapy.

FAQ

Kolik položek by měla mít veřejná roadmap? Tak málo, kolik můžete obhájit. Méně než deset celkem je normální pro malý produkt; víc než třicet v «plánováno» je obvykle backlog přestrojený za roadmapu.

Měla by mít veřejná roadmap data? Ne. Sloupce sdělují pořadí, aniž by vytvářely termín. Pokud zákaznice potřebuje datum, je to rozhovor, ne položka roadmapy.

Měli by zákazníci hlasovat o položkách roadmapy? Hlasy měří, kdo se ukázal, ne co záleží. Komentář na issue vysvětlující náhradní řešení, které dnes používají, má větší hodnotu než padesát hlasů, a stojí hlasujícího něco, což je ta podstata.

Co se stane se zrušenou položkou roadmapy? Odstraňte štítek a řekněte proč na issue. Veřejné «tohle neuděláme» je součástí smyčky, a je to zpráva, kterou většina týmů nikdy neposílá.

Technická tvrzení v tomto článku nikdo nezávisle neověřil. Pokud tu něco nesedí, dej nám vědět a opravíme to.

Související na changeloop: Dokumentace pro vývojáře, Srovnání nástrojů pro changelog