Il rilascio di una grande funzionalità non consiste solo nel distribuire codice, ma nel guidarne l'adozione. Con Trupeer, puoi risparmiare ore sulla pianificazione del lancio iniziando con un modello di rilascio gratuito, personalizzandolo con le tue linee guida del brand e trasformando i piani di lancio in aggiornamenti video che allineano i team dietro a ogni rilascio.

I rilasci delle funzionalità vanno storti in un ordine prevedibile. La build finisce in ritardo, quindi il briefing di supporto viene saltato, quindi la documentazione di aiuto non viene aggiornata, quindi le note di rilascio vengono scritte da un ingegnere venti minuti prima del deploy e il supporto scopre cosa è stato rilasciato dal primo ticket.

Niente di tutto questo è un problema di build. È un problema di coordinamento e si risolve con un conto alla rovescia piuttosto che con una checklist.

Scarica i modelli di rilascio delle funzionalità

Gratuito, modificabile, senza filigrana.

Come personalizzare questo modello in Trupeer

Passaggio 1: Apri la sezione Modelli

Vai alla sezione Modelli dal menu di navigazione principale.

Passaggio 2: Seleziona e apri un modello

Fai clic su qualsiasi modello con cui desideri lavorare per aprirlo.

Passaggio 3: Espandi la visualizzazione del modello

Se necessario, espandi la visualizzazione del modello per vedere chiaramente il layout completo e i dettagli.

Passaggio 4: Modifica il modello

Fai clic su Modifica per iniziare a modificare il modello selezionato.

All'interno dell'editor, puoi:

• Aggiungere nuove sezioni

• Definire o aggiornare le regole di formattazione

• Aggiungere un logo e regolarne la posizione e le relative impostazioni

Passaggio 5: Salva il tuo modello personalizzato

Dopo aver apportato tutte le modifiche necessarie, fai clic su Salva per memorizzare il modello aggiornato come tuo.

Passaggio 6: Visualizza l'anteprima e perfeziona il modello

Quando desideri vedere l'aspetto del tuo modello personalizzato, apri l'Anteprima.

Dalla schermata di anteprima, puoi continuare ad apportare modifiche direttamente se necessario, assicurandoti che il modello appaia esattamente come desideri.

Con un modello di rilascio delle funzionalità puoi:

• Risparmiare ore sulla pianificazione del lancio: Salta la pagina bianca con una struttura creata per i lanci di prodotto.

• Allineare i team interfunzionali: Sezioni integrate per prodotto, marketing, vendite e supporto.

• Rimanere in linea con il brand: Applica il tuo logo, i caratteri e i colori utilizzando il kit del brand di Trupeer.

• Guidare l'adozione: I campi integrati per messaggistica e formazione assicurano che i clienti utilizzino effettivamente la funzionalità.

• Standardizzare i rilasci: Utilizza lo stesso modello per ogni rilascio di funzionalità.

• Raggiungere team globali: Traduci i materiali di lancio in oltre 65 lingue con un solo clic.

Cosa serve davvero per il rilascio di una funzionalità

Sei elementi, cinque destinatari. La maggior parte dei team ne produce due.

I due elementi che vengono saltati sono proprio quelli che determinano l'andamento della settimana successiva al rilascio. Inseriscili nel conto alla rovescia invece di trattarli come attività successive.

Il conto alla rovescia per il rilascio

Date relative al giorno di distribuzione. Regola gli intervalli in base alla tua cadenza, ma mantieni l'ordine.

T-14: congelamento dell'ambito

Ciò che è incluso in questo rilascio viene deciso e messo per iscritto. Qualsiasi cosa arrivi dopo questo momento va nel rilascio successivo, a meno che non si tratti della correzione di un difetto.

La variazione dell'ambito (scope creep) dopo il congelamento è la singola causa più comune del ritardo di tutto ciò che segue. Il congelamento non è burocrazia, è ciò che consente di scrivere il briefing, le note e la documentazione basandosi su qualcosa di stabile.

Output: il piano di rilascio, con ambito confermato e ogni voce assegnata.

T-7: prontezza interna

Bozza della documentazione redatta, bozza delle note di rilascio redatta, briefing di supporto scritto. Non pubblicati, in bozza.

Questa è la settimana che viene compressa quando la build è in ritardo, e comprimerla è ciò che causa il problema di supporto. Se la build slitta, la data di rilascio slitta con essa. Distribuire in tempo senza briefing non significa distribuire in tempo.

Output: bozze delle note, bozze degli articoli di aiuto, briefing di supporto pronto per la revisione.

T-2: briefing per supporto e vendite

Il briefing avviene tramite una sessione, non via email. Il supporto pone le domande che rivelano ciò che le note non hanno spiegato, e quelle domande migliorano le note prima che i clienti le vedano.

Output: supporto istruito e relative domande chiarite. Note revisionate. Abilitazione vendite inviata dove pertinente.

T-1: go o no-go

Una decisione definita con criteri definiti, presa da persone designate. Non una sensazione sulla prontezza delle cose.

Output: una decisione registrata e, in caso di no-go, una nuova data.

T-0: distribuzione

Deploy, monitoraggio, pubblicazione delle note, abilitazione dell'annuncio in-app. In questo ordine, poiché pubblicare le note per un rilascio di cui è fallito il deploy porta a una brutta mezz'ora.

Output: rilasciato, note online, supporto in osservazione.

T+1: monitoraggio

Qualcuno è responsabile del monitoraggio per il primo giorno: tassi di errore, volume di supporto per argomento, adozione della nuova funzionalità. Non l'intero team che dà un'occhiata ogni tanto, ma una persona designata.

Output: una breve nota sullo stato al team, anche se è tutto a posto.

T+7: revisione

Cosa è stato distribuito, cosa si è rotto, cosa ha segnalato il supporto, se qualcuno lo sta usando. Trenta minuti, ed è ciò che rende migliore il rilascio successivo.

Output: note della revisione ed eventuali modifiche al processo.

Il modello del piano di rilascio

Il campo fuori ambito merita il suo posto. Scrivere ciò che non è incluso in questo rilascio è il modo in cui eviti che la stessa conversazione si ripeta tre volte.

Criteri go e no-go

Decidili in fase di pianificazione, non durante la riunione, altrimenti la riunione diventa una trattativa sotto pressione.

Criteri tipici di go. Tutti gli elementi dell'ambito completati o esplicitamente rimandati. Suite di test superata. Nessun difetto critico o ad alta gravità aperto. Rollback testato in un ambiente simile a quello di produzione. Supporto informato e confermato pronto. Documentazione pubblicata o pronta per la pubblicazione. Monitoraggio e avvisi confermati attivi. Proprietario designato disponibile per la finestra di monitoraggio.

No-go automatico. Qualsiasi rollback non testato. Qualsiasi difetto critico aperto. Supporto non informato. Responsabile del rilascio non disponibile per le successive 24 ore.

Quello del rollback è l'aspetto che conta di più. Un rollback documentato che nessuno ha mai eseguito è solo un'ipotesi. Testalo e registra quando lo hai fatto l'ultima volta.

Scrivere le note di rilascio

Quattro delle otto pagine in questo risultato di ricerca trattano delle note di rilascio, il che ti fa capire che è l'elemento con cui le persone fanno più fatica.

L'errore fondamentale è scriverle partendo dal changelog. Un elenco di commit riorganizzato in punti elenco non è una nota di rilascio, perché descrive ciò che hai modificato piuttosto che ciò che il lettore può fare ora.

• Inizia con ciò che ora possono fare, non con quello che hai creato.

• Raggruppa per risultato utente, non per componente o team.

• Scrivi in seconda persona. "Ora puoi esportare in CSV" è meglio di "È stata implementata l'esportazione CSV".

• Spiega il perché per tutto ciò che non è ovvio, in una sola frase.

• Includi le correzioni, specialmente quelle segnalate dai clienti. Chiude un cerchio che loro ricordano.

• Sii onesto riguardo ai limiti. "Attualmente supporta fino a 10.000 righe" previene l'apertura di un ticket.

• Inserisci link ai dettagli. Le note annunciano, la documentazione spiega.

• Limita ogni voce a due o tre frasi.

• Salta le modifiche interne impercettibili per chi è all'esterno, a meno che non influiscano sulle prestazioni o sulla sicurezza.

Inefficace e migliore

Inefficace: Implementata la funzionalità di esportazione CSV per il modulo di reportistica.

Migliore: Ora puoi esportare qualsiasi report in formato CSV. Cerca il pulsante di esportazione in alto a destra in qualsiasi vista del report. Attualmente limitato a 50.000 righe per esportazione.

Inefficace: Risolti vari bug e migliorate le prestazioni.

Migliore: I report con più di 10.000 righe ora si caricano in circa 3 secondi anziché andare in timeout. Abbiamo anche risolto il problema segnalato da diversi utenti per cui i filtri della data si reimpostavano cambiando scheda.

Inefficace: Aggiunta nuova granularità dei permessi utente nel pannello di amministrazione.

Migliore: Gli amministratori possono ora concedere l'accesso ai report senza dare accesso alla fatturazione. Imposta questa opzione per ogni utente in Impostazioni, Team, Permessi. Gli utenti esistenti mantengono i permessi attuali, quindi non cambia nulla a meno che tu non decida di modificarli.

Lo schema: cosa si può fare, dove si trova, quali sono i limiti e cosa succede alle configurazioni esistenti. Quest'ultimo punto previene la maggior parte dei ticket ansiosi generati da un rilascio.

Cosa includere nelle note di rilascio

Le modifiche di rottura e le azioni richieste vanno inserite in alto con risalto visivo. Una modifica di rottura scoperta a metà di un elenco di miglioramenti è una modifica di rottura scoperta da un cliente arrabbiato.

Il briefing di supporto

L'elemento più saltato e il più economico da produrre.

Forniscilo come sessione due giorni prima. Le domande che il supporto pone sono la migliore revisione gratuita che le tue note di rilascio possano ricevere, perché il supporto sa cosa chiedono effettivamente i clienti, a differenza del team di prodotto.

Tipi di rilascio

Gli hotfix bypassano il conto alla rovescia per definizione, motivo per cui richiedono un processo leggero e separato piuttosto che presumere che venga seguito quello normale. Documenta in cosa consiste prima di averne bisogno.

I rilasci major necessitano di un preavviso, non solo di note il giorno stesso. Qualsiasi modifica di rottura dovrebbe essere annunciata con almeno un ciclo di rilascio di anticipo, e per le funzionalità deprecate è necessario indicare una data di rimozione quando vengono annunciate, non quando avviene la rimozione effettiva.

Feature flag e rollout graduale

Se puoi effettuare il rilascio a una percentuale di utenti, la maggior parte dei rischi descritti in questa pagina scompare.

Rilascia in modalità "dark", abilita per gli utenti interni, poi per un piccolo gruppo, quindi progressivamente. Monitora a ogni passaggio ed effettua il rollback tramite flag anziché tramite deploy. Il flag diventa il tuo rollback, che è più veloce e meno allarmante di un nuovo deploy.

Due regole evitano che questo diventi un caos. Ogni flag necessita di un proprietario e di una data di rimozione, altrimenti ne accumulerai a centinaia e nessuno saprà quali percorsi sono attivi. Inoltre, le note di rilascio devono specificare chi ha accesso alla funzionalità, perché "ora puoi esportare in CSV" è fonte di confusione per l'80% di utenti che non possono ancora farlo.

Misurare il rilascio

• Adozione. Percentuale di utenti idonei che hanno utilizzato la funzionalità nei primi 7, 30 e 90 giorni. Il numero che indica se valeva la pena svilupparla.

• Volume di supporto per argomento. Dovrebbe registrare un picco e poi scendere. Un plateau significa che la documentazione o il design non sono chiari.

• Tasso di errore. Rispetto al valore di riferimento, durante la finestra di monitoraggio.

• Tasso di rollback, tra i vari rilasci. Un aumento significa che i criteri di go sono troppo blandi.

• Tempo dal congelamento alla distribuzione. Se slitta costantemente, significa che il congelamento avviene troppo tardi.

• Interazione con le note di rilascio, dove è possibile misurarla. Sapere che c'è un basso numero di lettori è utile prima di investirvi ulteriore impegno.

Stabilisci il target di adozione prima del rilascio, nel piano. Adattare a posteriori la definizione di successo dopo aver visto i numeri è il modo in cui le funzionalità vengono dichiarate di successo a prescindere.

Come gestire il rilascio di una funzionalità

1. Congela l'ambito a T-14 e scrivi chiaramente cosa è escluso.

2. Redigi le bozze di note, documentazione e briefing a T-7, prima che la build sia terminata.

3. Istruisci il supporto a T-2 in una sessione e correggi le note in base alle loro domande.

4. Svolgi una vera riunione go/no-go a T-1 sulla base di criteri stabiliti in anticipo.

5. Testa il rollback prima, non durante.

6. Esegui il deploy, poi pubblica le note, in questo ordine.

7. Designa una persona per il monitoraggio per 24 ore.

8. Effettua una revisione a T+7, di trenta minuti, in modo onesto.

9. Traccia l'adozione a 7, 30 e 90 giorni rispetto al target del piano.

10. Correggi il processo, non solo la funzionalità, quando qualcosa va storto.

Best practice

• Ambito congelato con l'elenco delle attività fuori ambito messo per iscritto.

• Documentazione e note redatte prima del completamento della build.

• Supporto istruito in una sessione dedicata, con due giorni di anticipo.

• Criteri di go concordati prima della riunione.

• Rollback testato, con data registrata.

• Modifiche di rottura inserite all'inizio delle note.

• Note scritte a partire dai risultati utente, non dal changelog.

• Un addetto designato al monitoraggio per le prime 24 ore.

• Target di adozione stabilito prima del rilascio.

• Una revisione eseguita ogni volta, anche per i rilasci senza intoppi.

Errori comuni

• Ambito che cambia dopo il congelamento, comprimendo tutto ciò che segue.

• Note di rilascio scritte a partire dai messaggi di commit.

• Utilizzo della voce "Risoluzione di vari bug e miglioramenti".

• Modifiche di rottura nascoste a metà di un elenco.

• Il supporto che viene a conoscenza del rilascio da un cliente.

• Documentazione aggiornata la settimana successiva.

• Go/no-go basato su una sensazione piuttosto che su criteri oggettivi.

• Rollback documentato ma mai testato.

• Note pubblicate prima che il deployment sia confermato.

• Nessuno che monitori dopo la distribuzione.

• Feature flag senza proprietario o data di rimozione.

• Successo dichiarato senza un target di adozione stabilito in precedenza.

• Assenza di un processo di hotfix, per cui le correzioni urgenti bypassano tutto, compreso il buon senso.

Distribuisci la documentazione insieme alla funzionalità, non dopo

Apri i modelli in Trupeer AI, applica il tuo kit del brand in modo che i materiali di rilascio corrispondano al tuo prodotto e modifica direttamente qualsiasi sezione. La configurazione è descritta nella guida ai modelli.

La documentazione e il briefing di supporto vengono saltati ogni volta per lo stesso motivo: scriverli richiede ore che la settimana di rilascio non ha, e descrivere una nuova interfaccia a parole è un lavoro lento e ambiguo.

Registra la funzionalità una volta sola, non appena è testabile, e Trupeer AI produrrà l'articolo di aiuto e una video panoramica narrata a partire dallo stesso passaggio. In questo modo avrai la documentazione, il materiale per il briefing di supporto e una clip dimostrativa per le note di rilascio da un'unica registrazione effettuata a T-7, anziché dover gestire tre attività per le quali nessuno ha tempo.

Traducila in oltre 65 lingue in modo che i clienti internazionali ricevano il rilascio contemporaneamente a tutti gli altri, e conserva il set nella tua knowledge base in modo che sia pronto all'arrivo del primo ticket. Utilizza la stessa registrazione per l'abilitazione del supporto.

Registra. Personalizza con il brand. Traduci. Usa Trupeer.

Domande frequenti

Esiste un modello gratuito di rilascio delle funzionalità in Word?

Sì. La versione Word contiene il modello delle note di rilascio, il briefing di supporto e l'annuncio interno, ovvero i documenti in cui le persone scrivono effettivamente, piuttosto che limitarsi a tracciare le attività. Download gratuito, nessuna registrazione richiesta, senza filigrana.

Esiste un modello gratuito di rilascio delle funzionalità in Excel?

Sì, ed Excel è il luogo in cui risiede il piano di rilascio: tracciatore dell'ambito con proprietari e stato, la checklist go/no-go, le dipendenze, i rischi e il calendario dei rilasci. È il file di lavoro durante la settimana di rilascio.

Esiste un modello di piano di rilascio in Excel?

Sì, è il file Excel presente in questa pagina. Copre l'ambito, gli elementi fuori ambito, le dipendenze, i rischi, il rollback, i criteri go/no-go, il piano di comunicazione e le misure di successo, con una scheda per rilascio in modo da creare uno storico.

Esiste un modello di piano di rilascio del software in Word?

Sì. La versione Word del piano di rilascio è adatta per un piano descrittivo destinato agli stakeholder o per un processo formale di modifica, mentre la versione Excel è adatta al tracciamento. La maggior parte dei team usa Excel per la gestione e Word per tutto ciò che richiede approvazione.

Posso scaricare un modello gratuito di rilascio delle funzionalità?

Sì, ogni formato è scaricabile gratuitamente senza necessità di creare un account e senza obbligo di attribuzione.

Esiste un modello gratuito di rilascio delle funzionalità in PDF?

Sì, per il piano approvato e le versioni stampabili della checklist go/no-go e del briefing di supporto.

Esiste un modello gratuito di rilascio delle funzionalità in PowerPoint?

Sì. La versione PowerPoint copre la presentazione di revisione del rilascio e l'abilitazione delle vendite, una slide per funzionalità con cosa fa, a chi è rivolta e l'obiezione a cui risponde.

Qual è il miglior modello gratuito di rilascio delle funzionalità?

Quello che include gli elementi che le persone tendono a saltare. Un piano di rilascio è facile da trovare e un modello di note di rilascio è facile da scrivere. Ciò che determina l'andamento della settimana di rilascio sono il briefing di supporto e i criteri go/no-go, motivo per cui entrambi sono inclusi qui anziché essere lasciati come un'aggiunta scontata.

Cos'è un modello di rilascio delle funzionalità?

Un insieme di documenti per la distribuzione di una funzionalità: il piano che copre ambito e date, la checklist go/no-go, le note di rilascio per i clienti, il briefing di supporto e l'aggiornamento della documentazione. Trattarlo come un unico documento è il motivo per cui gli elementi interni vengono saltati.

Cosa dovrebbero includere le note di rilascio?

Versione e data, nuove funzionalità raggruppate per risultato utente, miglioramenti percepibili, correzioni comprese quelle segnalate dai clienti, modifiche di rottura in evidenza, funzionalità deprecate con date di rimozione, problemi noti, eventuali azioni richieste e link alla documentazione.

Come si scrivono buone note di rilascio?

Scrivi a partire da ciò che l'utente può fare ora, piuttosto che dal changelog. Usa la seconda persona, raggruppa per risultato, limita a due o tre frasi per voce, sii onesto sui limiti e dichiara esplicitamente cosa succede alle configurazioni esistenti. Posiziona le modifiche di rottura e le azioni richieste in alto, dove non possono essere ignorate.

Qual è la differenza tra un piano di rilascio e le note di rilascio?

Un piano di rilascio è interno e orientato al futuro: cosa viene distribuito, quando, chi ne è responsabile, qual è il piano di rollback. Le note di rilascio sono esterne e orientate al passato: cosa è cambiato e cosa significa per il cliente. Sono necessari entrambi e di solito vengono scritti da persone diverse.

Cosa sono i criteri go e no-go?

Le condizioni che devono essere soddisfatte prima di procedere con un rilascio, concordate in anticipo in modo che la decisione sia un controllo e non una trattativa. Tipicamente: tutto l'ambito completato o rimandato, test superati, nessun difetto critico aperto, rollback testato, supporto informato, documentazione pronta e monitoraggio attivo.

Con quanto anticipo si dovrebbe istruire il supporto?

Due giorni prima, tramite una sessione dedicata piuttosto che un'email, e dopo che le note di rilascio sono state redatte in bozza in modo che il supporto possa analizzarle. Le loro domande sono la migliore revisione che le note riceveranno, poiché sanno cosa chiedono effettivamente i clienti.

Come si misura il rilascio di una funzionalità?

Adozione tra gli utenti idonei a 7, 30 e 90 giorni rispetto a un target stabilito prima del rilascio, volume di supporto per argomento, tasso di errore rispetto al valore di riferimento e, trasversalmente ai vari rilasci, il tasso di rollback e l'eventuale slittamento dell'intervallo tra congelamento e distribuzione.

Qual è la differenza tra un rilascio major, minor e una patch?

Un rilascio major contiene modifiche di rottura o nuove funzionalità significative e richiede un preavviso e una guida alla migrazione. Un rilascio minor aggiunge funzionalità mantenendo la retrocompatibilità. Una patch corregge solo difetti. Gli hotfix sono correzioni urgenti in produzione che bypassano il normale conto alla rovescia, motivo per cui necessitano di un proprio processo documentato e leggero.

Posso personalizzare questo modello di rilascio delle funzionalità?

Sì, tutte le versioni sono completamente modificabili. Regola gli intervalli del conto alla rovescia in base alla tua cadenza, poiché un ciclo di rilascio settimanale non può utilizzare un congelamento di quattordici giorni. L'ordine dei passaggi conta più delle tempistiche specifiche. In Trupeer AI puoi anche applicare il tuo kit del brand in modo che i materiali di rilascio si adattino al tuo prodotto.

Modelli correlati

• Modello di piano di progetto

• Modello di piano di gestione del progetto

• Modello di documentazione tecnica

• Modello di documentazione software

• Modello SOP di supporto al prodotto

• Modello di piano di formazione sul prodotto

• Modello di piano di comunicazione

• Modello di piano di gestione del cambiamento

• Modello di documento dei requisiti di business