Rilasciare una modifica senza rovinarsi la serata
La domanda prima di ogni rilascio non è se funziona. È cosa farai nei venti minuti dopo che non funziona.
Gran parte dei rilasci va bene. Quelli che non vanno bene falliscono di solito per ragioni che nessuno poteva prevedere: proprio per questo la preparazione riguarda il recupero e non la previsione.
Scrivi prima la via del ritorno
Prima di rilasciare, rispondi per iscritto a una domanda: come lo annulliamo e quanto ci vuole? Se la risposta supera i dieci minuti, o è “bisognerebbe pensarci”, non sei pronto — non perché la modifica sia sbagliata, ma perché ci penserai mentre qualcosa è rotto e le persone chiedono.
Alcune modifiche davvero non si annullano: una migrazione di dati, una mail già partita. Quelle richiedono un altro tipo di cura — un primo lotto piccolo, una prova sul proprio account — proprio perché la via di fuga non esiste.
Rilascia quando è sveglio chi può sistemarlo
Il venerdì pomeriggio è la fascia peggiore e resta popolare perché sembra sgombrare la scrivania prima del fine settimana. In realtà sposta la scoperta di qualsiasi problema al sabato, quando chi conosce la modifica è irraggiungibile e chi è raggiungibile non la conosce.
Le fasce buone sono le mattine di martedì e mercoledì. Ottieni una giornata lavorativa piena di uso reale con tutte le persone coinvolte alla scrivania. Un rilascio che aspetta quattro giorni non è quasi mai peggiore di uno che nessuno può seguire.
Osserva ciò che hai cambiato, non la dashboard
Dopo un rilascio si dà un’occhiata a una vista generale, si vede verde e si va avanti. Le viste generali si accorgono tardi di una rottura specifica: un modulo che fallisce su un browser, un passaggio che viene saltato in silenzio.
Passa i primi quindici minuti a usare la cosa che hai cambiato come farebbe un cliente. Sembra troppo semplice per contare e trova più del monitoraggio, perché il monitoraggio segnala solo i guasti che qualcuno ha pensato di strumentare.
Dillo al supporto prima che al mondo
Chi risponde ai messaggi dovrebbe sapere di una modifica prima che un cliente gliela descriva. Altrimenti il loro primo contatto con il tuo lavoro è una persona confusa, e devono indovinare se sia un bug o una scelta.
Bastano due frasi: cosa è cambiato e cosa qualcuno potrebbe notare. Mandale la mattina stessa. È l’azione meno costosa possibile ed è quella più spesso saltata, perché chi rilascia pensa al codice e non a chi dovrà risponderne alle quattro.
Domande frequenti
Cosa preparare prima di un rilascio?
La via del ritorno. Scrivi come si annulla la modifica e quanto ci vuole; se supera i dieci minuti o va pensata, non sei pronto: ci penserai mentre qualcosa è rotto.
Qual è il momento migliore per rilasciare?
Martedì o mercoledì mattina, così hai una giornata lavorativa piena di uso reale con tutti i coinvolti alla scrivania. Il venerdì pomeriggio sposta la scoperta del problema al sabato.
Come si annuncia una modifica?
A chi risponde ai clienti prima che ai clienti: due frasi, cosa è cambiato e cosa si potrebbe notare. Altrimenti il primo contatto con il tuo lavoro è una persona confusa e un’ipotesi.
