Chiudere il ciclo di feedback dal changelog

Un ciclo di feedback del cliente si chiude quando alla persona che ha dato il feedback viene detto cosa ne è stato fatto. Non quando viene archiviato. Non quando viene prioritizzato. Nemmeno quando viene rilasciato. Quando le viene detto. La maggior parte dei team fa bene i primi tre passi e per niente l’ultimo, e poi si chiede perché le persone che mandano feedback smettono di mandarlo.

Questo articolo riguarda quell’ultimo passo, e un’affermazione concreta: il changelog è il posto giusto da cui chiudere il ciclo, perché è l’unico artefatto che già esiste esattamente nel momento in cui il ciclo può essere chiuso.

Cos’è un ciclo di feedback del cliente?

Un ciclo di feedback del cliente è il percorso da un’utente che vi dice qualcosa a quell’utente che scopre cosa avete fatto al riguardo. Ha quattro passi: raccogliere il feedback, decidere cosa farne, rilasciare il risultato, e avvisare chi ha chiesto. Il ciclo è aperto finché non avviene il quarto passo. Un team che raccoglie feedback e rilascia correzioni ma non avvisa mai nessuno ha una casella di posta, non un ciclo.

L’ultima riga è quella di cui parla questo articolo. Si rompe per una ragione strutturale, non culturale: quando una funzionalità viene rilasciata, la richiesta che l’ha causata vive in un sistema diverso dalla cosa rilasciata, e non è compito di nessuno collegarle. Il ciclo comincia prima, da come si chiede la richiesta fin dall’inizio; come chiedere feedback ai clienti tratta formulazione e tempistica.

Perché i cicli di feedback restano aperti?

I cicli di feedback restano aperti perché la richiesta e il cambiamento rilasciato vivono in posti diversi e il collegamento tra i due viene fatto a mano, quando va bene. La richiesta è in uno strumento di feedback, una casella di supporto o un foglio di calcolo. Il cambiamento è in una pull request. L’annuncio è in un changelog o un’email. Tre sistemi, tre proprietari, e il collegamento dal terzo indietro al primo è una persona che si ricorda, mesi dopo, chi ha chiesto.

C’è una seconda ragione. Il passo dell’avviso viene solitamente inquadrato come un compito di marketing (“annunciare la funzionalità”) piuttosto che un compito di supporto (“rispondere alla persona”). Gli annunci vanno a tutti e non raggiungono nessuno in particolare. La persona che ha chiesto la funzionalità a marzo legge l’annuncio a giugno, se lo legge, come notizia, non come risposta. Il ciclo si chiude solo se il messaggio è indirizzato a lei.

Perché chiudere il ciclo dal changelog?

Perché la voce di changelog è l’unico artefatto che esiste esattamente al momento giusto, contiene esattamente le parole giuste, ed è scritta esattamente dalla persona giusta. Esiste quando il cambiamento è live e non prima. Dice cosa è cambiato nei termini della lettrice, che è il messaggio di cui ha bisogno chi ha chiesto. Ed è scritta da qualcuno che ha appena letto la pull request, che è l’unico momento in cui il link alla richiesta originale è ancora visibile.

Confrontate le alternative. Chiudere il ciclo dallo strumento di feedback significa che lo strumento di feedback deve sapere quando la funzionalità è stata rilasciata, il che significa che qualcuno aggiorna uno stato a mano. Chiuderlo dalla pull request significa avvisare la cliente al merge, prima che il cambiamento sia live, una promessa rotta con timestamp appena il rilascio slitta. Chiuderlo dall’annuncio marketing significa aspettarne uno, e la maggior parte dei cambiamenti rilasciati non ne ha mai uno.

Il changelog sta nel mezzo: dopo il merge, al momento del rilascio, con la formulazione pronta.

Come si chiude il ciclo, passo per passo

Questo è il meccanismo che eseguiamo. È descritto qui come specifica piuttosto che tour di prodotto, perché ogni passo può essere fatto a mano o con altri strumenti; quello che conta è l’ordine.

1. Il feedback diventa un issue nel repository che lo risolverà. Un invio da widget viene archiviato come issue etichettato su GitHub (feature-request o bug, una priorità, e from-widget), con l’indirizzo email di chi lo ha inviato tenuto fuori dal corpo dell’issue. L’issue vive accanto al codice, così il passo tre può trovarlo. Un issue aperto a mano, per esempio da una template di richiesta funzionalità, è fuori da questo percorso: il passo cinque non lo commenta, quindi quel ciclo chiudetelo voi.
2. La correzione referenzia l’issue. La pull request dice Fixes #142, la parola chiave di chiusura di GitHub stessa. Niente di nuovo da imparare, ed è la stessa frase che le sviluppatrici scrivono già.
3. La voce di changelog viene redatta dalla pull request mergiata e porta il link. Al merge, la bozza viene creata e #142 viene letto dal corpo della PR e allegato alla bozza. Il link viene creato mentre è ancora economico, da una macchina, da dati che sono già lì.
4. Una persona revisiona la voce. Formulazione, pubblico, se dovrebbe essere pubblicata affatto. Una bozza scartata non chiude nulla, il che è corretto: un refactor interno che per caso ha referenziato un issue non è notizia.
5. All’approvazione, chi ha chiesto viene informato. Un commento viene pubblicato sull’issue nato dal suo feedback, “Shipped —” seguito dal titolo della voce e un link alla voce pubblicata, e il widget mostra a chi l’ha inviato la stessa voce rilasciata. Una volta, mai due, e solo dopo che una persona ha pubblicato la voce. La stessa voce esce tramite feed e widget a tutti quelli che non hanno chiesto.

L’ordine nel passo cinque è tutto il design. Avvisare chi ha chiesto al merge sarebbe più presto e più facile, e sarebbe sbagliato circa tanto spesso quanto slittano i rilasci. Un feature flag rompe persino quest’ordine, perché approvato e pubblicato può succedere mentre la funzionalità resta invisibile per l’account di chi ha fatto la richiesta; feature flag e richieste di funzionalità copre il controllo extra di cui questo passaggio ha bisogno appena c’è di mezzo un flag.

Come appare un ciclo chiuso per la cliente?

Sembra una risposta. La cliente ha inviato una richiesta tramite un widget, e un giorno il widget la mostra come rilasciata, con link a una voce che la descrive nei suoi termini; su GitHub, l’issue riceve la stessa notizia come commento. Non si è iscritta a una newsletter, non ha controllato una roadmap, non ha cercato nel changelog. Le è stato detto.

Questa è l’esperienza che fa succedere il prossimo pezzo di feedback. Le persone mandano feedback a prodotti che rispondono. La pagina esempi di changelog include voci di team i cui utenti tornano visibilmente con richieste, e il filo comune non è lo strumento; è che le voci si leggono come risposte.

Come si misura un ciclo di feedback?

Misurate la frazione di cambiamenti rilasciati che hanno informato almeno chi ha chiesto, e il tempo dal rilascio all’avviso. Due numeri, entrambi facili una volta che il link esiste e impossibili prima.

• Tasso di chiusura: delle voci di changelog pubblicate questo mese, quante collegavano almeno una richiesta, e di quelle, quante hanno avvisato chi ha chiesto. Se il secondo numero è molto più basso del primo, le notifiche stanno fallendo; se il primo è basso, le richieste non vengono referenziate dalle pull request, e la correzione è una frase nel template della PR.
• Tempo dal rilascio all’avviso: quanto passa tra la voce che va live e l’avviso a chi ha chiesto. Col meccanismo sopra sono secondi. A mano sono tipicamente settimane, o mai, e “mai” è il numero che conta.

Non misurate il ciclo per volume di feedback raccolto. Raccogliere è il passo facile, e un team che lo misura lo ottimizzerà, il che produce più cicli aperti.

Dove si inserisce la roadmap?

Una roadmap pubblica è un modo di chiudere il ciclo in anticipo: dice a chi ha chiesto che la sua richiesta è stata ascoltata, prima che venga rilasciata. È utile, e non sostituisce l’ultimo passo. “Pianificato” è una promessa sul futuro; “Rilasciato” è un fatto sul presente. Eseguite la roadmap pubblica dagli stessi issue, con un’etichetta per colonna, così che la stessa richiesta si sposti da pianificata a rilasciata senza essere reinserita da nessuna parte. Lo spostamento a rilasciata è un cambio di etichetta (roadmap:shipped) che nessuno fa per voi quando la voce viene approvata, quindi fatelo nella stessa revisione.

FAQ

Quali sono i quattro passi di un ciclo di feedback del cliente? Raccogliere, decidere, rilasciare, avvisare. Il ciclo è aperto finché non avviene il quarto passo. La maggior parte dei framework aggiunge passi di analisi e prioritizzazione nel mezzo; sono raffinamenti di “decidere”, e nessuno di essi chiude nulla.

Si dovrebbe avvisare i clienti quando si rifiuta una richiesta? Sì, ed è il messaggio più trascurato del ciclo. Un chiaro “non lo faremo, ed ecco perché” finisce l’attesa. Il silenzio lascia il ciclo aperto per sempre e la cliente a controllare.

In cosa si differenzia chiudere il ciclo dall’annunciare una funzionalità? Un annuncio va a tutti. Chiudere il ciclo è una risposta alle persone che hanno chiesto, sul canale attraverso cui hanno chiesto. Fate entrambe le cose; sono messaggi diversi per lettrici diverse.

E se chi ha chiesto non è su GitHub? La maggior parte non lo è, e va bene così. Il widget continua a mostrargli lo stato di ciò che ha inviato, compresa la voce rilasciata e il suo link, quindi non gli serve nulla oltre alla pagina da cui ha scritto. Il commento sull’issue è per le persone che possono vedere il repository.

Questo ciclo funziona su GitLab o Bitbucket invece che su GitHub? Il widget e il changelog sì; il commento automatico del passo cinque no, per ora. Un team su GitLab o Bitbucket riceve comunque ogni invio, lo archivia comunque come issue, e mostra comunque a chi ha chiesto uno stato nel widget, ma chiudere quello specifico ciclo tornando sull’issue stesso è un passo che si fa a mano finché quell’integrazione non esiste.

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, Esempi di changelog