Una funzione nuova serve a poco se nessuno si accorge che esiste. Le note di rilascio hanno proprio questo compito: spiegare che cosa è cambiato, con parole semplici, nel momento in cui quella novità può essere utile. Non devono sembrare il diario del reparto tecnico. Devono parlare a chi apre il software per lavorare.
Con i software in abbonamento gli aggiornamenti arrivano quasi sempre senza che nessuno debba fare niente. Non c’è un programma da installare, non compare un CD nuovo sulla scrivania e spesso non c’è nemmeno un momento preciso in cui l’utente capisce che qualcosa è cambiato. La mattina apre l’app e trova una voce in più, un pulsante diverso o una schermata che il giorno prima non c’era.
Lunedì mattina, poco dopo le otto. Chiara ha l’app aperta sul telefono prima della prima visita. In fondo alla schermata vede un comando che venerdì non ricordava. Non sa bene cosa faccia, non ha tempo di provarlo e passa oltre. L’azienda aveva già mandato una mail venerdì sera: «Rilasciata la versione 4.2, migliorie e correzioni varie». È finita insieme ai preventivi, alle conferme d’ordine e agli altri messaggi del fine settimana. Tre settimane dopo qualcuno si chiede perché la nuova funzione non venga usata.
Il problema non è necessariamente la funzione. Può essere semplicemente che nessuno l’abbia davvero vista. Con il software che si aggiorna da solo manca quel piccolo momento di attenzione che una volta accompagnava una nuova versione. Per questo un elemento nuovo che compare senza spiegazione rischia di diventare invisibile proprio perché è già lì.
Anche l’esperienza di altri prodotti digitali mostra quanto sia delicato cambiare un’interfaccia che le persone usano tutti i giorni. Quando qualcosa si sposta o compare all’improvviso, la prima reazione non è sempre curiosità. Spesso è più semplice continuare a fare quello che si faceva prima. Una buona comunicazione serve soprattutto a evitare questo.
Chi sviluppa software ha bisogno di sapere esattamente che cosa è stato modificato: versione, ticket, modulo, correzione, intervento tecnico. È normale. Serve per lavorare, controllare e tornare indietro quando qualcosa non funziona.
Chi usa il software ha bisogno di altro.
Vuole capire che cosa può fare da oggi e che cosa non dovrebbe più dare problemi.
La differenza sembra piccola, ma cambia completamente il modo di scrivere. Una frase come «Fix calcolo totale modulo spese, ticket 1432» ha senso per chi conosce quel ticket. Per chi sta compilando una nota spese è molto più utile leggere: «Nella nota spese il totale considera correttamente solo le righe del modulo».
La seconda frase dice dove guardare e cosa è cambiato nella pratica. Non obbliga chi legge a tradurre un linguaggio tecnico in un’azione.
È anche il motivo per cui un changelog tecnico non dovrebbe diventare automaticamente la pagina degli aggiornamenti. Può essere perfetto per il team che sviluppa e completamente inutile per chi apre l’app tra due appuntamenti.
Per un commerciale una nota di rilascio non viene letta con calma davanti a una scrivania. Più facilmente viene vista sul telefono, in macchina prima di partire, al bar o mentre si aspetta di entrare da un cliente. Questo cambia molto il modo in cui va scritta.
La prima regola è usare i nomi che la persona vede davvero nell’app. Se la schermata si chiama «Oggi», nella nota deve chiamarsi «Oggi». Il nome interno del progetto, il codice del modulo o la sigla usata dagli sviluppatori non interessano.
Poi va descritto il gesto. Non «migliorata la gestione delle tappe», ma qualcosa come: «Ora puoi spostare una visita in un altro giorno direttamente da Oggi». Un verbo concreto fa capire subito cosa si può fare.
Per i problemi corretti vale lo stesso criterio. Chi usa il prodotto non ha bisogno di conoscere la causa tecnica. Gli interessa sapere che cosa vedeva di sbagliato e che cosa adesso funziona meglio. «Corretto errore di sincronizzazione stato visita» dice poco. «Una visita già conclusa non torna più tra quelle da fare dopo la sincronizzazione» dice molto di più.
Anche la lunghezza conta. Se per spiegare una modifica servono dieci righe, quella non è più una nota di rilascio: è una guida. Le note devono permettere di capire subito se la novità riguarda il proprio lavoro oppure no.
Una versione può essere raccontata in modo molto semplice: prima quello che è stato aggiunto o cambiato, poi quello che è stato corretto.
Tenere sempre lo stesso ordine aiuta perché, dopo un po’, le persone sanno già dove guardare. Chi vuole vedere le funzioni nuove parte dall’inizio. Chi ha avuto un problema nelle settimane precedenti scorre direttamente le correzioni.
Le correzioni meritano la stessa attenzione delle novità. Per chi usa un software tutti i giorni, sapere che una cosa fastidiosa finalmente non succede più può essere molto più importante di avere un pulsante in più. Un difetto corretto è una novità a tutti gli effetti, se quel difetto faceva perdere tempo ogni giorno.
Mandare una mail per ogni aggiornamento è semplice, ma non sempre è il posto migliore. La mail compete con tutto il resto: clienti, offerte, richieste interne, solleciti, appuntamenti. Un aggiornamento del prodotto funziona meglio quando compare proprio nel prodotto.
L’avviso, però, non deve restare lì per sempre. Dopo qualche giorno diventa parte dell’arredamento e smette di essere visto. Meglio lasciarlo in evidenza per il tempo necessario e poi spostarlo in un archivio dove le versioni restano consultabili.
In questo modo si ottengono due cose diverse: l’avviso serve a far capire che è cambiato qualcosa, mentre l’archivio serve a ritrovare quella modifica anche mesi dopo.
Sapere che una funzione esiste non significa sapere dove trovarla.
Se una nota dice «Ora puoi anticipare una tappa del giro», chi legge potrebbe capirne subito il senso ma non sapere da dove partire. Per questo le novità importanti funzionano meglio se, la prima volta che si entra nella schermata giusta, il prodotto le indica direttamente.
Non serve un tutorial lungo. Spesso basta un piccolo richiamo nel posto corretto, una sola volta.
Questo evita anche un problema molto comune nei software: continuare ad aggiungere funzioni che restano praticamente sconosciute a buona parte degli utenti. Una funzione pubblicata è disponibile. Diventa davvero utile solo quando qualcuno capisce che esiste e sa dove usarla.
Per chi gestisce un’azienda con una rete vendita, ogni cambiamento del software può diventare facilmente un’altra cosa da spiegare alla squadra.
Se invece gli aggiornamenti vengono raccontati bene dentro il prodotto, il responsabile non deve fare da manuale vivente ogni volta che compare una funzione nuova. Può limitarsi a capire se quella funzione è stata utile, se crea qualche dubbio oppure se cambia davvero un modo di lavorare e merita un confronto con tutta la rete.
Le riunioni restano utili per le modifiche importanti. Non dovrebbero servire per spiegare dove è comparso un pulsante.
È lo stesso principio di cui parliamo quando raccontiamo perché i commerciali non usano il CRM: uno strumento entra nelle abitudini quando restituisce qualcosa nel momento in cui serve, senza chiedere continuamente attenzione in più.
In myPedro, quando arriva un aggiornamento, la campanella mostra per sette giorni un messaggio semplice: «myPedro si è aggiornato». Sotto compare un riepilogo, per esempio «5 funzioni nuove · 5 difetti corretti». Toccando il messaggio si apre direttamente quella versione. Lo stesso sistema è disponibile per tutti i ruoli, sia sul telefono sia sul computer.
Nel Profilo, dentro «Aggiornamenti», restano poi tutte le versioni pubblicate, dalla più recente alle precedenti, con la loro data. Ogni versione segue sempre la stessa struttura: prima le funzioni nuove, poi i problemi corretti.
Anche i testi seguono la stessa regola. Una funzione del 24 settembre 2026, per esempio, si chiama «Anticipa una tappa». La spiegazione è: «Se ti avanza tempo, Oggi ti propone una tappa del giro da fare subito». Non racconta come è stata sviluppata. Dice semplicemente cosa succede quando serve.
Per le funzioni nuove c’è poi un secondo passaggio. La prima volta che una persona entra nella schermata interessata, un piccolo indicatore mostra dove si trova la novità. La campanella avvisa che qualcosa è cambiato; il richiamo dentro la schermata mostra dove guardare. Chi non vuole questi suggerimenti può disattivarli da «Come funziona myPedro».
Abbiamo anche imposto una regola a noi stessi: se una modifica cambia qualcosa che l’utente può vedere o usare, non viene pubblicata senza una voce nel registro degli aggiornamenti. Le modifiche puramente interne, che non cambiano nulla nell’esperienza, possono invece restare fuori.
Ci sono anche dei limiti. Il registro è uguale per tutti, quindi un commerciale può leggere anche una novità pensata soprattutto per il titolare. E le note spiegano che cosa è cambiato nel prodotto, non come ogni azienda decide di organizzare il proprio lavoro intorno a quella funzione. Quella parte resta nelle mani di chi coordina la rete.
L’obiettivo non è trasformare ogni aggiornamento in un evento. È quasi il contrario: fare in modo che una persona capisca in pochi secondi che cosa è cambiato e possa tornare a lavorare.
Le funzioni più importanti, quelle che meritano più spazio di una singola riga, le raccontiamo anche negli aggiornamenti di prodotto.
La squadra che costruisce myPedro
Raccontiamo i cambiamenti di myPedro con le parole di chi lo usa, e accanto a ogni funzione scriviamo anche che cosa non fa.
Sono l’elenco di che cosa cambia in una versione nuova di un software: funzioni aggiunte o modificate e difetti corretti. Per chi usa lo strumento devono dire che cosa si può fare da oggi e dove.
Spesso i due nomi si usano come sinonimi. Nella pratica il changelog è il registro completo delle modifiche, a volte tecnico; le note di rilascio scelgono ciò che conta per chi usa il software e lo scrivono con le sue parole.
Usa il nome che si vede sullo schermo, descrivi il gesto nuovo in una frase e i difetti dal sintomo. Mettila dentro lo strumento per qualche giorno e poi in un archivio, e chiedi a un commerciale se l’ha capita.
Prova gratis 14 giorni al livello Assistente Pro. Poi decidi tu.
