Dietro le quinte

Dall'istinto alla cultura della prova

Christian Sager
18.9.2020
Traduzione: tradotto automaticamente
Immagini: Thomas Kunz
Co-autore: Christoph Glaser

Nello sviluppo del software, prendiamo decisioni basate sui dati. Le prove A/B ci aiutano a farlo. Poiché non eravamo soddisfatti dello strumento di test esterno, abbiamo rapidamente sviluppato un nostro strumento di A/B testing.

Da tre mesi a questa parte, i clienti di digitec e Galaxus possono fare acquisti a impatto climatico zero. Questo è possibile
compensazione climatica alla cassa. Ma non tutti i clienti sono riusciti a compensare fin dall'inizio. Abbiamo effettuato una prova alla pari nelle prime due settimane. Una parte degli acquirenti ha visto la nota variante A senza l'opzione di compensazione delle emissioni di CO2 nel check-out. L'altro gruppo ha visto l'opzione B, precedentemente sconosciuta, con la possibilità di compensare le emissioni di CO2. Volevamo scoprire come i nostri clienti hanno reagito alla funzione di compensazione delle emissioni di CO2.

Le prove A/B sono ormai uno strumento consolidato nello sviluppo di software per misurare l'efficacia di nuove funzionalità. Secondo Google, solo il 30% di tutte le prove A/B ha esito positivo. Questo significa che senza prove c'è il 70% di possibilità di apportare un cambiamento che ha un impatto negativo.

Citazione da W.E. Deming «Senza dati sei solo un'altra persona con un'opinione.»
Citazione da W.E. Deming «Senza dati sei solo un'altra persona con un'opinione.»

Più semplice a dirsi che a farsi

Anche se il principio di base dell'A/B testing è di rapida comprensione, l'area tematica nasconde una grande complessità: a partire da una solida ipotesi di test, passando per la corretta impostazione e il monitoraggio, fino alla valutazione e alla formulazione di ipotesi di follow-up. Per questo motivo, sul mercato esistono innumerevoli strumenti di test che semplificano alcuni aspetti dell'A/B testing per i team di software o addirittura li tolgono completamente dalle loro mani. Finora anche noi di Digitec Galaxus abbiamo utilizzato uno strumento di testing esterno. Con l'aumentare dell'esperienza nel campo dei test e con una curva di apprendimento generale in aumento nel nostro team di ingegneri, abbiamo raggiunto un punto in cui i team di sviluppo hanno avuto diversi problemi con l'uso dello strumento precedente. Ecco dove le cose si sono bloccate:

  • Esigenze elevate sulle prestazioni della pagina: vogliamo evitare che i test abbiano un impatto sul tempo di caricamento e quindi sull'esperienza dell'utente.
    - Lo strumento che utilizzavamo in precedenza era una scatola nera per noi: non avevamo una visione dettagliata di quali metodi fossero utilizzati per generare i risultati dei test.

E non volevamo nemmeno scendere a compromessi con la nostra cultura della sperimentazione: Vogliamo determinare noi stessi l'andamento dei nostri test alla prova e offrire ai nostri utenti i test più veloci possibili.

La soluzione è stata subito chiara

In poco tempo avevamo un gruppo compatto e motivato pronto ad affrontare il problema. Il gruppo era un mix variopinto: ingegneri del software, un analista, ricercatori UX e proprietari di prodotti erano pienamente motivati ad affrontare l'argomento.

La prima domanda che ci siamo posti è stata quali opzioni avevamo a disposizione:

  • Risolvere i problemi con lo strumento esistente
  • Valutare un nuovo strumento
  • Costruire un nostro strumento
Prospettive diverse unite in un unico team.
Prospettive diverse unite in un unico team.

Insieme a due esperti esterni di A/B testing, siamo andati a fondo dei problemi di performance e abbiamo effettuato un piccolo audit. Ci siamo subito resi conto che non sarebbe stato difficile costruire il nostro strumento in base alle nostre esigenze. Inoltre, ci avrebbe dato piena trasparenza e controllo sullo strumento e ci avrebbe permesso di svilupparlo ulteriormente in base alle nostre esigenze in futuro.

Lo strumento di test deve essere testato

Lo sviluppo del nuovo strumento è quindi iniziato. Tuttavia, gli sviluppatori non hanno abbandonato tutto, ma hanno investito qualche minuto di tanto in tanto accanto al loro lavoro principale. Ed ecco che nel giro di tre settimane il primo prototipo era pronto per una prima prova. Abbiamo poi utilizzato varie prove (AA test) per convalidare la plausibilità dei dati e dei risultati dei test. Dopo essere riusciti a mettere un segno di spunta verde dietro la convalida, dopo un totale di sei settimane abbiamo proceduto alla prima prova con il cliente finale. Eravamo tutti ansiosi di vedere i risultati iniziali e se il nuovo strumento avrebbe retto. Ma con nostro grande sollievo, non ci sono state brutte sorprese e la prima prova si è svolta senza problemi!

C'era molta eccitazione prima del primo test effettivo con il cliente finale.
C'era molta eccitazione prima del primo test effettivo con il cliente finale.

Da allora sono passati cinque mesi e abbiamo già eseguito decine di prove con il nostro strumento. Ci sono ancora delle sfide. Ma poiché abbiamo il pieno controllo del nostro strumento, possiamo reagire rapidamente e svilupparlo in base alle esigenze dei nostri team. Nel corso del tempo, la squadra di ingegneri, colorata e motivata, si è trasformata in un team consolidato che continua a portare avanti l'argomento dei test AB all'interno dell'azienda.

Entra nel team

Anche a te piacerebbe risolvere i problemi in modo semplice? Allora dai un'occhiata ai nostri annunci di lavoro:le nostre offerte di lavoro

A 25 persone piace questo articolo


User Avatar
User Avatar

L'apprendimento rapido attraverso piccoli ma preziosi passi è la chiave per prodotti di successo.

Potrebbero interessarti anche questi articoli

  • Dietro le quinte

    Lego e iPhone: le ricerche più frequenti della clientela

    di Manuel Wenk

  • Dietro le quinte

    La nostra strategia per una maggiore sostenibilità

  • Dietro le quinte

    Come un software engineer si innamora della logistica

    di Tiago Santos Baranita

Commenti

Avatar