Roadmap publică din tracker-ul de issue-uri, trei coloane

O roadmap publică e o listă a ce intenționați să construiți, publicată acolo unde clienții o pot vedea. Cuvântul care face treaba e intenționați: o roadmap e un set de promisiuni despre viitor, iar fiecare element de pe ea e unul pe care fie îl veți respecta, fie va deveni vizibil că n-ați făcut-o. Ăsta e motivul pentru a publica una, și e de asemenea motivul pentru care majoritatea roadmap-urilor publice îmbătrânesc într-un trimestru. Versiunea care supraviețuiește e mică, derivată din date pe care le mențineți deja, și conectată la celălalt capăt la changelog, ca o promisiune să devină un fapt fără ca cineva s-o reintroducă.

Pentru ce e o roadmap publică?

O roadmap publică îi spune unei cliente cu o cerere că cererea ei a fost auzită, înainte de a fi lansată. E jumătatea timpurie a închiderii buclei: “Planificat” răspunde la întrebarea “a citit cineva asta”, iar “În construcție” răspunde la “chiar se întâmplă asta”. Niciunul dintre ele nu înlocuiește ultimul pas, anunțarea solicitantei când e lansat, dar ambele reduc numărul oamenilor care întreabă între timp.

Face de asemenea ceva pentru echipă: forțează un angajament public, care e cel mai ieftin remediu cunoscut împotriva unui backlog care păstrează liniștit patru sute de elemente pe care nimeni nu le va construi.

Trei coloane, într-o ordine fixă, sunt suficiente. O a patra coloană (“în considerare”, “în revizuire”, “backlog”) e locul unde bunele intenții devin un muzeu, și e prima pe care clienții o învață s-o ignore.

Ar trebui roadmap-ul vostru să fie public?

Faceți-l public dacă puteți să-l mențineți mic și onest; păstrați-l privat dacă alternativa e o listă lungă de poate. Costul unei roadmap publice n-are nimic de-a face cu publicarea ei: fiecare element de pe ea e acum o întrebare pe care cineva o va pune, în suport, în apeluri de vânzări și în conversații de reînnoire. Zece elemente pe care le veți construi sunt un activ. Șaizeci de elemente pe care poate le veți construi sunt șaizeci de conversații viitoare despre de ce nu.

Două motive oneste pentru a nu publica: planurile voastre se schimbă mai repede decât un trimestru, sau concurența voastră citește roadmap-ul vostru mai atent decât clienții voștri. Ambele sunt reale, și ambele sunt rezolvate publicând mai puțin în loc de nimic: doar “în construcție”, cu “planificat” ținut intern, încă îi spune unei solicitante că issue-ul ei se mișcă.

Cum se construiește o roadmap publică din issue-uri GitHub?

Puneți o etichetă pe coloană pe issue-urile pe care le urmăriți deja, și randați issue-urile etichetate ca roadmap. Nimic nu e reintrodus, roadmap-ul nu poate devia de la muncă, iar același issue care a început ca o cerere de client se mișcă prin coloane fără să-și schimbe identitatea.

Mecanismul, așa cum îl rulăm:

1. O etichetă pe coloană, cu prefix fix: roadmap:planned, roadmap:building, roadmap:shipped. Orice issue dintr-un repository conectat care poartă una apare în acea coloană. Un issue fără niciuna dintre ele nu e pe roadmap, ceea ce e majoritatea issue-urilor, ceea ce e corect.
2. Coloanele sunt un array ordonat, mereu în aceeași ordine. Planificat, în construcție, lansat. Nu o mapă indexată după nume, ca o cititoare (sau un widget) să nu trebuiască niciodată să ghicească secvența.
3. Dacă un issue poartă două etichete, câștigă cea mai avansată. Cineva va adăuga roadmap:shipped înainte de a elimina roadmap:planned; o mașină de stări ghidată de “care webhook a sosit ultimul” ar pune elementul în coloane diferite în funcție de ordinea de livrare. Decizia doar din setul de etichete face răspunsul același indiferent de cum sosesc evenimentele.
4. Lansat e o stare de etichetă ca celelalte. Cartea se mută când issue-ul primește roadmap:shipped, sau e închis în timp ce o poartă. Cartea în sine nu leagă la intrarea de changelog; detaliile stau în intrare, redactată din pull request-ul care a închis issue-ul.
5. Serviți-o ca date. Roadmap-ul e un document JSON cu aceste trei coloane, publicat lângă fluxul de changelog cu aceleași header-e de cache, ca un site de documentație, un widget sau o pagină de status s-o poată randa fără o a doua integrare. Documentația fluxului are forma exactă.

O etichetă e puțin de cerut de la o menținătoare, și e toată integrarea. Niciun tablou de sincronizat, nicio unealtă separată în care să vă autentificați, iar cererea pe care a depus-o clienta e elementul de pe roadmap; când e lansat, e același element.

Ce n-ar trebui să conțină o roadmap publică?

N-ar trebui să conțină date, estimări, sau orice v-ar face rușine dacă ați fi întrebați despre asta peste nouă luni. Datele sunt greșeala clasică: un trimestru pe o roadmap devine un angajament într-o prezentare de vânzări devine un tichet numit “ați spus Q3”. Coloanele spun suficient. “În construcție” înseamnă deja “suficient de curând încât cineva lucrează la asta”.

De asemenea n-ar trebui să conțină backlog-ul intern. O roadmap cu trei sute de elemente e o problemă de căutare, nu o promisiune, iar clienta care-și găsește cererea pe poziția 212 a învățat ceva ce nu voiați să-i spuneți.

Cum se conectează roadmap-ul cu changelog-ul?

Roadmap-ul și changelog-ul descriu aceleași issue-uri din două părți, unul pentru viitor și celălalt pentru trecut. Nimeni nu mută o carte pe un tablou separat. O menținătoare schimbă eticheta pe issue-ul la care lucra deja, intrarea e redactată din pull request, iar când o persoană aprobă intrarea, o solicitantă al cărei feedback din widget a devenit acel issue e anunțată pe el. Mutarea cărții la lansat e tot un pas separat, eticheta roadmap:shipped, deci faceți-l parte din aceeași revizuire; aprobarea intrării nu-l face în locul vostru.

Asta e aceeași buclă pe care articolul despre bucla de feedback o descrie din partea changelog-ului; roadmap-ul e ce vede clienta la mijlocul ei. Rezumatul unelte pentru changelog acoperă care produse oferă o vizualizare de roadmap și care o tratează ca un tablou separat, ceea ce e diferența care decide dacă rămâne exactă.

Cum arată o roadmap publică bună?

Arată scurt, iar fiecare element de pe ea e un issue pe care oricine îl poate deschide. Testul e dacă o clientă poate merge de la un element la discuția din spatele lui, și de la un element lansat la intrarea care descrie ce s-a schimbat de fapt. O roadmap care e o listă de nume de funcții fără intrare e o broșură.

Un exemplu lucrat, ca JSON-ul pe care l-ar prelua un 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"
}

Trei elemente în trei coloane sunt o roadmap publică perfect bună. Spune ce urmează, ce se întâmplă, și ce s-a întâmplat, iar fiecare linie e verificabilă. Alte cinci aranjări, de la Now/Next/Later la cele pe rezultate, sunt arătate cu elemente-exemplu în exemple de roadmap de produs.

FAQ

Câte elemente ar trebui să aibă o roadmap publică? Cât mai puține pe care le puteți apăra. Sub zece în total e normal pentru un produs mic; peste treizeci în “planificat” e de obicei un backlog deghizat în roadmap.

Ar trebui o roadmap publică să aibă date? Nu. Coloanele comunică secvență fără a crea un termen limită. Dacă o clientă are nevoie de o dată, asta e o conversație, nu un element de roadmap.

Ar trebui clienții să voteze elementele de roadmap? Voturile măsoară cine s-a prezentat, nu ce contează. Un comentariu pe issue explicând soluția temporară pe care o folosesc azi valorează mai mult decât cincizeci de voturi, și costă ceva persoana care votează, ceea ce e esența.

Ce se întâmplă cu un element de roadmap anulat? Eliminați eticheta și spuneți de ce pe issue. Un public “nu vom face asta” e parte din buclă, și e mesajul pe care majoritatea echipelor nu-l trimit niciodată.

Afirmațiile tehnice din acest articol nu au fost verificate independent. Dacă ceva nu e corect, spune-ne și vom corecta.

Pe changeloop: Documentație pentru dezvoltatori, Comparație instrumente changelog