Roadmap pubblica dal vostro issue tracker, tre colonne

Una roadmap pubblica è una lista di ciò che intendete costruire, pubblicata dove i clienti possono vederla. La parola che fa il lavoro è intendete: una roadmap è un insieme di promesse sul futuro, e ogni elemento su di essa è uno che manterrete o si vedrà che non mantenete. Questa è la ragione per pubblicarne una, ed è anche la ragione per cui la maggior parte delle roadmap pubbliche diventano obsolete entro un trimestre. La versione che sopravvive è piccola, derivata da dati che già mantenete, e collegata all’altro capo al changelog, così che una promessa diventi un fatto senza che nessuno la reinserisca.

A cosa serve una roadmap pubblica?

Una roadmap pubblica dice a una cliente con una richiesta che la richiesta è stata ascoltata, prima che venga rilasciata. È la metà anticipata della chiusura del ciclo: “pianificato” risponde alla domanda “qualcuno lo ha letto”, e “in costruzione” risponde a “sta davvero succedendo”. Nessuno dei due sostituisce l’ultimo passo, avvisare chi ha chiesto quando viene rilasciato, ma entrambi riducono il numero di persone che chiedono nel frattempo.

Fa anche una cosa per il team: forza un impegno pubblico, che è la cura più economica conosciuta per un backlog che nasconde silenziosamente quattrocento elementi che nessuno costruirà.

Tre colonne, in ordine fisso, sono sufficienti. Una quarta colonna (“in considerazione”, “in revisione”, “backlog”) è dove le buone intenzioni diventano un museo, ed è la prima che i clienti imparano a ignorare.

La vostra roadmap dovrebbe essere pubblica?

Rendetela pubblica se potete mantenerla piccola e onesta; tenetela privata se l’alternativa è una lunga lista di forse. Il costo di una roadmap pubblica non ha nulla a che fare col pubblicarla: ogni elemento su di essa è ora una domanda che qualcuno farà, nel supporto, nelle chiamate di vendita e nelle conversazioni di rinnovo. Dieci elementi che costruirete sono un asset. Sessanta elementi che potreste costruire sono sessanta conversazioni future sul perché no.

Due ragioni oneste per non pubblicare: i vostri piani cambiano più veloce di un trimestre, o la vostra concorrenza legge la vostra roadmap più attentamente dei vostri clienti. Entrambe sono reali, ed entrambe si risolvono pubblicando meno piuttosto che niente: solo “in costruzione”, con “pianificato” tenuto interno, dice comunque a chi ha chiesto che il suo issue si sta muovendo.

Come si costruisce una roadmap pubblica dagli issue di GitHub?

Mettete un’etichetta per colonna sugli issue che già tracciate, e rendete gli issue etichettati come la roadmap. Niente viene reinserito, la roadmap non può divergere dal lavoro, e lo stesso issue che è iniziato come richiesta di un cliente si muove attraverso le colonne senza cambiare identità.

Il meccanismo, così come lo eseguiamo:

1. Un’etichetta per colonna, con prefisso fisso: roadmap:planned, roadmap:building, roadmap:shipped. Qualsiasi issue in un repository collegato che ne porti una appare in quella colonna. Un issue senza nessuna di esse non è sulla roadmap, che è la maggior parte degli issue, il che è corretto.
2. Le colonne sono un array ordinato, sempre nello stesso ordine. Pianificato, in costruzione, rilasciato. Non una mappa indicizzata per nome, così che una lettrice (o un widget) non debba mai indovinare la sequenza.
3. Se un issue porta due etichette, vince la più avanzata. Qualcuno aggiungerà roadmap:shipped prima di rimuovere roadmap:planned; una macchina a stati guidata da “quale webhook è arrivato per ultimo” metterebbe l’elemento in colonne diverse a seconda dell’ordine di consegna. Decidere solo dall’insieme di etichette rende la risposta uguale indipendentemente da come arrivano gli eventi.
4. Rilasciato è uno stato di etichetta come gli altri. La carta si sposta quando l’issue riceve roadmap:shipped, o viene chiuso mentre ce l’ha. La carta in sé non collega alla voce di changelog; la voce, redatta dalla pull request che ha chiuso l’issue, è dove vivono i dettagli.
5. Servitela come dati. La roadmap è un documento JSON con quelle tre colonne, pubblicato accanto al feed di changelog con gli stessi header di cache, così che un sito docs, un widget o una pagina di stato possano renderla senza una seconda integrazione. La documentazione del feed ha la forma esatta.

Un’etichetta è poco da chiedere a una mantenitrice, ed è tutta l’integrazione. Nessuna board da mantenere sincronizzata, nessuno strumento separato in cui accedere, e la richiesta che la cliente ha archiviato è l’elemento sulla roadmap; quando viene rilasciato, è lo stesso elemento.

Cosa non dovrebbe contenere una roadmap pubblica?

Non dovrebbe contenere date, stime, o nulla di cui vi vergognereste se vi venisse chiesto tra nove mesi. Le date sono l’errore classico: un trimestre su una roadmap diventa un impegno in una presentazione di vendita diventa un ticket chiamato “avete detto Q3”. Le colonne dicono abbastanza. “In costruzione” significa già “abbastanza presto che qualcuno ci sta lavorando”.

Non dovrebbe nemmeno contenere il backlog interno. Una roadmap con trecento elementi è un problema di ricerca, non una promessa, e la cliente che trova la sua richiesta in posizione 212 ha imparato qualcosa che non volevate dirle.

Come si collega la roadmap al changelog?

La roadmap e il changelog descrivono gli stessi issue da due lati, uno per il futuro e uno per il passato. Nessuno sposta una carta su una board separata. Una mantenitrice cambia l’etichetta sull’issue su cui stava già lavorando, la voce viene redatta dalla pull request, e quando una persona approva quella voce chi ha chiesto, se il suo feedback dal widget è diventato quell’issue, viene informato lì. Spostare la carta in rilasciato resta un passo a sé, l’etichetta roadmap:shipped, quindi fatelo parte della stessa revisione; approvare la voce non lo fa per voi.

Questo è lo stesso ciclo che descrive l’articolo sul ciclo di feedback dal lato del changelog; la roadmap è ciò che la cliente vede nel mezzo di esso. La rassegna strumenti per il changelog copre quali prodotti offrono una vista roadmap e quali la trattano come una board separata, che è la differenza che decide se resta accurata.

Come appare una buona roadmap pubblica?

Sembra corta, e ogni elemento su di essa è un issue che qualcuno può aprire. Il test è se una cliente può andare da un elemento alla discussione dietro di esso, e da un elemento rilasciato alla voce che descrive cosa è effettivamente cambiato. Una roadmap che è una lista di nomi di funzionalità senza modo di entrare è una brochure.

Un esempio lavorato, come il JSON che un widget andrebbe a recuperare:

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

Tre elementi su tre colonne sono una roadmap pubblica perfettamente buona. Dice cosa sta arrivando, cosa sta succedendo, e cosa è successo, e ogni riga di essa è verificabile. Altri cinque layout, da Now/Next/Later a quello per risultati, sono mostrati con voci di esempio negli esempi di roadmap di prodotto.

FAQ

Quanti elementi dovrebbe avere una roadmap pubblica? Il meno possibile che potete difendere. Meno di dieci in totale è normale per un prodotto piccolo; più di trenta in “pianificato” è un backlog travestito da roadmap.

Una roadmap pubblica dovrebbe avere date? No. Le colonne comunicano sequenza senza creare una scadenza. Se una cliente ha bisogno di una data, quella è una conversazione, non un elemento di roadmap.

I clienti dovrebbero votare sugli elementi della roadmap? I voti misurano chi si è presentato, non cosa conta. Un commento sull’issue che spiega la soluzione alternativa che usano oggi vale più di cinquanta voti, e costa qualcosa a chi vota, che è il punto.

Cosa succede a un elemento della roadmap che viene cancellato? Rimuovete l’etichetta e dite perché sull’issue. Un “non lo faremo” pubblico è parte del ciclo, ed è il messaggio che la maggior parte dei team non invia mai.

Le affermazioni tecniche di questo articolo non sono state verificate in modo indipendente. Se qualcosa non è corretto, faccelo sapere e lo correggeremo.

Correlati su changeloop: Documentazione per sviluppatori, Strumenti di changelog a confronto