Questo è sicuramente un argomento interessante e uno che mi appassiona molto. Negli ultimi dieci anni, mentre servivo in una varietà di diversi ruoli di Product Management e Product Marketing, mi è stata posta la domanda "qual è il miglior strumento di changelog?" facilmente oltre 100 volte. Una cosa che ho sempre trovato interessante è che non sono sempre i team tecnici che mi hanno fatto questa domanda. Sono spesso persone nel Customer Success, Product Marketing, o anche Project e Program Manager. E ho ricevuto questa domanda da aziende di ogni forma e dimensione e in quasi ogni settore, anche.
In primo luogo, direi che penso che molto di ciò che User-11323811798076317325 ha detto qui è esatto. Ci sono una serie di fattori diversi che dovrebbero entrare nel processo decisionale per determinare quale strumento di changelog è più adatto al vostro team e al vostro business. Vorrei anche rinforzare che nessuno strumento aggiusterà un processo rotto, quindi assicuratevi di non cercare una pallottola d'argento in uno strumento, perché posso assicurarvi che non esiste.
Detto questo, ecco alcune regole generali e linee guida che ho sempre fornito ai team che mi hanno chiesto consigli su come trovare uno strumento di changelog:
- Utilizzate uno strumento di changelog che sia facilmente accessibile a qualsiasi membro del vostro team. Ho visto un certo numero di team che hanno impostato il loro changelog in uno strumento per sviluppatori come il loro sistema di repository del codice (e/o semplicemente usano il loro sistema di repository del codice come changelog). Questo potrebbe funzionare all'inizio, quando la vostra azienda è composta solo da sviluppatori, ma nel momento in cui si inizia a costruire un team più completo questo sistema si rompe completamente. E poi è super dispendioso in termini di tempo cercare di spostare tutto quel contesto in un altro strumento.
- Utilizzare uno strumento di changelog che abbia funzionalità di ricerca integrate. Potrebbe sembrare sciocco, ma ho visto un sacco di persone che finiscono per tracciare tutte le loro modifiche in un posto che non può essere cercato. Quando la quantità di cose che il tuo team spedisce e cambia nel prodotto cresce, questo diventa immediatamente un problema enorme e rende il changelog quasi inutilizzabile.
- Non usare il tuo strumento di gestione del progetto (o excel) come changelog. Questa è un'altra cattiva abitudine in cui ho visto molti team cadere, semplicemente per convenienza o perché non sanno che ci sono soluzioni migliori là fuori. Simile al tentativo di costruire un changelog nel tuo sistema di controllo di versione distribuito (DVCS), uno strumento di gestione del progetto è progettato per gestire progetti, non per raccogliere e catalogare ogni cambiamento che avviene nel tuo prodotto. E ancora, se metti il tuo changelog nel tuo strumento di gestione del progetto, finisce chiuso in uno strumento a cui la maggior parte del tuo team non può accedere. Ho guidato il Product Marketing per Jira per molti anni e sono sempre stato sorpreso da quanti team hanno cercato di adattare Jira come un changelog. Sono un grande fan di Jira, ma posso dirti che è un terribile changelog. Specialmente quando il vostro team si ingrandisce.
- Utilizzate uno strumento di changelog che vi permetta di categorizzare facilmente le modifiche. Sempre di più, specialmente nel software B2B, gli utenti vogliono essere in cima, e anche in anticipo, sui cambiamenti a cui il vostro team sta lavorando e che verranno spediti. Soprattutto qualsiasi cambiamento o aggiornamento che potrebbe avere un impatto sul loro uso quotidiano dello strumento. Ma non tutti i cambiamenti sono rilevanti per ogni persona, e se aspettate la fine del trimestre per fare un riepilogo trimestrale, qualsiasi cosa sia cambiata probabilmente è già arrivata mesi fa. Un changelog che vi permette di categorizzare diversi cambiamenti che avranno un impatto su diverse parti (o utenti) del prodotto è l'ideale. In questo modo non tutti vengono spammati con ogni aggiornamento postato nel vostro changelog, ma le persone giuste vengono a conoscenza dei cambiamenti che avranno un impatto su di loro. Più segnale, meno rumore.
- Assicuratevi che il vostro changelog non sia solo seduto da qualche parte a prendere polvere. Potete davvero tracciare i cambiamenti del prodotto ovunque, e ho visto team pubblicarli in post di blog, postarli in qualche area del loro strumento di supporto clienti, o anche catalogarli su un documento Notion pubblico. Tutte queste soluzioni funzionano, ma il problema è che nessun utente è mai in grado di trovare il vostro changelog se fate così. Non solo è un peccato spendere tempo per tracciare correttamente i cambiamenti se nessuno dei vostri utenti sarà mai in grado di trovarli o leggerli, ma state tagliando fuori voi stessi e i vostri utenti, poiché ci sono strumenti di changelog là fuori che comunicheranno i cambiamenti e gli aggiornamenti che fate al vostro changelog ai vostri utenti.
- Infine, qualunque cosa facciate, non costruite un changelog su misura. Ci sono un certo numero di ottimi strumenti là fuori che ospiteranno il vostro changelog per voi, e cercare di costruirne e gestirne uno da soli è un completo spreco di tempo, energia e risorse del vostro team. Sono ancora scioccato dalla quantità di team che spendono tempo prezioso per costruire un sito web o qualche strumento su misura da usare come changelog. Il più grande consiglio che ho dato ai team che mi hanno chiesto degli strumenti di changelog è di assicurarsi che non finiscano per costruire qualcosa da soli.
Uno strumento in cui mi sono imbattuto qualche tempo fa (e che sembra essere ovunque in questi giorni) è LaunchNotes. È uno strumento di changelog che non solo soddisfa tutte le cose che ho menzionato sopra, ma permette anche ai PMM di lanciare più facilmente nuovi prodotti e caratteristiche, dà ai PM la possibilità di prendere in giro i prossimi cambiamenti e iscrivere gli early adopter nei programmi beta, e un mucchio di altre cose interessanti. Lo vedo spuntare sempre più spesso e so che centinaia di team lo stanno usando come strumento di changelog, dato che è perfettamente adatto a questo. In ogni caso, vale la pena controllare.
Spero che quanto sopra vi aiuti a prendere una decisione. Buona fortuna!
Discrezione completa: sto consigliando attivamente LaunchNotes. È di gran lunga la migliore soluzione che ho visto per risolvere questo problema e volevo essere coinvolto 🙂