Il collaudo che ha scritto a tutti i clienti

Narratrice: Questa puntata usa voci sintetiche. È martedì mattina. Il team sta provando le notifiche prima del rilascio. Il Product Owner ha già chiamato il collaudo «un giro veloce».

Product Owner: Confermo: un giro veloce. Dobbiamo provare le notifiche e arrivare pronti alla demo. Se il giro è veloce, anche la riunione dopo sarà veloce. È una catena di efficienza.

Narratrice: Il Junior guarda il messaggio di prova. Nell’elenco dei destinatari compaiono indirizzi di clienti veri. Fa una domanda semplice, che nella stanza produce il silenzio di una domanda complicata.

Junior Developer: Scusate, questi sono indirizzi di clienti veri. Chi ha deciso di usarli per il collaudo? Pensavo che i messaggi di prova andassero ai contatti di prova.

Narratrice: Il Senior ammette di aver riutilizzato la rubrica del vecchio collaudo: almeno qualcuno risponde. Il Junior controlla di nuovo. La rubrica, a quanto pare, ha conservato una notevole voglia di partecipare.

Junior Developer: Ma se rispondono clienti veri, non è più una prova interna. È un messaggio vero che dice di essere una prova. La distinzione è scritta solo nella nostra speranza?

Product Owner: La demo è prima del rilascio, quindi la prova va completata adesso. Facciamo un solo messaggio, controlliamo che arrivi e poi chiudiamo. Un invio piccolo, una decisione piccola.

Narratrice: Il Senior sceglie il pulsante che sembra più prudente. Parte invece l’invito a tutti i contatti. Il sistema interpreta «un solo messaggio» come il messaggio inviato a ciascuno.

Junior Developer: È partito l’invito a tutti i contatti. Non uno. Tutti. Posso sapere se c’è un pulsante che ferma gli invii, prima che anche il pulsante di prova provi a fermarci?

Product Owner: Fermiamo tutto. Però dobbiamo capire cosa è partito e a chi. Non mandiamo un secondo messaggio per spiegare il primo finché non sappiamo se il secondo raggiunge gli stessi contatti.

Narratrice: Arriva Security mentre le prime risposte indignate compaiono. Chiede di fermare gli invii e distinguere i messaggi di test da quelli reali. Inizia la parte del collaudo in cui si collauda il collaudo.

Security: Fermate gli invii. Adesso distinguete quello che era previsto da quello che è partito davvero. Non chiamate tutto «test»: i clienti stanno ricevendo un invito e stanno rispondendo.

Commerciale: Aspetta: non diciamo incidente. Per i clienti è un’anteprima esclusiva. Sono stati coinvolti prima del rilascio, che è una forma di attenzione molto personalizzata.

Security: Un’anteprima esclusiva che nessuno aveva annunciato? Se vogliamo capire l’accaduto, chiamiamolo con il suo nome. E smettiamo di inviare messaggi finché non è chiaro cosa sta succedendo.

Commerciale: Sto ricevendo richieste di chiarimento. Posso dire che stiamo raccogliendo feedback? La parola «errore» apre conversazioni lunghe; «coinvolgimento» le chiude con una presentazione.

Narratrice: Il Junior mostra che alcuni destinatari hanno già risposto alla domanda di prova. Il Senior propone di contare quelle risposte come collaudo completato. La rubrica ora sembra anche un gruppo di lavoro.

Junior Developer: Hanno risposto a una domanda che non doveva arrivare a loro. Se le contiamo, il collaudo misura che i clienti leggono i messaggi inattesi. Non so se fosse questo il requisito.

Commerciale: Però hanno risposto. Questo è un dato di engagement. Non l’avevamo previsto, ma il mercato ci ha fornito un risultato senza aspettare la demo.

Security: Un risultato non trasforma un invio non voluto in una prova ben progettata. Prima fermiamo gli invii, poi ricostruiamo i destinatari e distinguiamo i messaggi reali da quelli di test.

Product Owner: Quindi la demo non può essere «guardate, abbiamo spedito a tutti». Devo rivedere il requisito. Avevo chiesto un messaggio, non una distribuzione con ambizioni da evento aziendale.

Narratrice: Il CTO convoca una breve riunione. La breve riunione comincia quando tutti hanno finito di spiegare perché la riunione non era necessaria.

Chief Technology Officer: Ragioniamo sul risultato. Abbiamo eseguito un test reale di engagement, in condizioni reali e con destinatari reali. Non era la modalità prevista, ma ha generato un’evidenza utile per la trasformazione del prodotto.

Security: La modalità prevista era un collaudo. L’evidenza utile è che un messaggio di prova è arrivato ai clienti. Dobbiamo tenere separate queste due frasi, altrimenti anche il resoconto diventa un invio a tutti.

Chief Technology Officer: Certo. Non stiamo negando l’accaduto: lo stiamo traducendo in apprendimento scalabile. Prepariamo una presentazione sui risultati e definiamo il prossimo passaggio con una responsabilità chiara.

Junior Developer: Nel titolo scriviamo che il sistema ha raggiunto tutti i clienti, compresi quelli che non volevano essere raggiunti? È preciso. E almeno non dobbiamo collaudare la precisione del titolo.

Commerciale: Io lo presenterei come un risultato di copertura. La frase è positiva e non nasconde niente; basta non mettere «non volevano» nella prima slide, magari nella seconda, con un grafico.

Product Owner: La demo doveva mostrare le notifiche. Adesso mostrerà anche quanto è importante definire bene un test. Possiamo chiamarla demo estesa, così almeno la durata è coerente con l’accaduto.

Chief Technology Officer: Perfetto. Chiudiamo l’incidente con una presentazione sui risultati: il sistema ha raggiunto tutti i clienti, compresi quelli che non volevano essere raggiunti. È una copertura che non lascia fuori nessuno.

Narratrice: La presentazione viene preparata. La demo è pronta. Il collaudo delle notifiche, invece, ha già trovato il suo pubblico.