Come rendere il monitoraggio degli eventi parte del processo di rilascio

Nota del redattore: questo articolo è stato originariamente pubblicato sul blog di Iterativamente il 15 marzo 2021.

Quando si creano nuove funzionalità o prodotti, è molto comune lasciare l'analisi all'ultimo minuto o addirittura dimenticarsene completamente. Questo scenario potrebbe sembrarti familiare:

• PM lavora su un rilascio
• Il rilascio avviene
• Il CEO chiede al PM come sta andando
• PM: Mi permetta di chiedere al team dei dati
• Team di dati: non ci hai mai coinvolto, non ci sono dati su questa funzione
• PM torna dal CEO senza risposte
• Il team dei dati e il PM sono sconvolti

Situazioni come questa possono potenzialmente accadere abbastanza spesso, ed è davvero importante ricordare che nessuna delle parti è da biasimare per questo. Molto potrebbe benissimo dipendere dalla cultura .

Indicare la "cultura" come una parte fondamentale del problema potrebbe sembrare facile, perché la cultura è difficile da definire. Tuttavia, molto spesso i valori e gli obiettivi di un'organizzazione non si riflettono pienamente nel modo in cui i membri del team si comportano. Per esempio:

La tua organizzazione afferma di prendere decisioni basate sui dati per fornire il miglior servizio ai tuoi utenti. Tutti capiscono che una buona base per questo è una solida strategia di dati, altrimenti non produrrai approfondimenti affidabili da cui partire per prendere quelle decisioni.

Ma, in pratica, le conversazioni sui tuoi dati e sulla tua strategia di insight (o anche metterne insieme una), non sembrano accadere. L'attività viene messa da parte e dimenticata e raramente si materializzano analisi affidabili.

Ciò accade a causa di un divario tra i valori della tua organizzazione e l'attuale cultura quotidiana: è molto facile scivolare in questo divario. Spesso i team si concentreranno maggiormente sull'ottenere informazioni dai dati piuttosto che sulla creazione di buone pratiche attorno all'effettiva acquisizione dei dati. Mantenere una buona cultura dei dati è difficile!

Costruire una tale cultura è molto più che una semplice pubblicità e un teatro di celebrazione. In questo post ti forniremo alcuni consigli pratici su come iniziare con processi semplici e applicabili ti aiuterà a mantenere la cultura dei dati desiderata . Uno che si concentra sull'acquisizione di dati di alta qualità e sulla loro trasformazione in intuizioni utili e attuabili che portano a un buon processo decisionale.

Integra l'analisi nel ciclo di vita dello sviluppo software

Quando un team di ingegneri si mette al lavoro per costruire parti di un prodotto, scriverà il codice e farà le solite cose con esso: branch, commit, test, review, merge. Questo per garantire che tutti siano sulla stessa pagina con la build e che eventuali errori possano essere facilmente corretti.

Non c'è motivo per non trattare l'analisi allo stesso modo. È probabile che tu abbia già una sorta di piano di tracciamento (in caso contrario, abbiamo una guida su come iniziare), quindi un ottimo modo per iniziare a implementarlo è suddividerlo in ticket Jira, proprio come con qualsiasi altro sottocompito. Un fantastico piano di monitoraggio non avrà importanza se non viene implementato. Continuerai a perdere intuizioni vitali a meno che tu non consideri che:

• Hai bisogno del consenso delle parti interessate e dei team di leadership pertinenti che il monitoraggio dell'analisi è importante quanto la funzionalità che stai creando
• Le attività che implementano il piano di monitoraggio dovrebbero avere la priorità insieme a tutte le altre attività per la compilazione
• Se non c'è tracciamento, non sei pronto per rilasciare la build

Sappiamo tutti che solo perché è su una serie di biglietti Jira, non significa che accadrà. È qui che entra in gioco il cambiamento culturale. Assicurati che il piano di tracciamento diventi parte del ciclo di vita dello sviluppo del tuo software ogni volta celebrando il successo di una funzionalità e non solo il fatto che la funzionalità sia stata distribuita. Dopotutto, se la tua azienda produce prodotti digitali, le funzionalità di spedizione sono l'intero punto. Cerca di evitare il teatro delle celebrazioni: festeggia quando vedi che un film funziona bene.

L'unico vero modo per capire come si sta comportando una funzionalità è raccogliere analisi, cosa che ovviamente farai, se il tuo piano di monitoraggio è stato implementato fin dalla prima build.

Una nota sul QA nel contesto dell'analisi: potresti pensare che mentre l'implementazione di un piano di monitoraggio è abbastanza semplice con gli strumenti e la cultura giusti, non esiste ancora una soluzione ovvia ed elegante per verificare che funzioni Questo è il motivo per cui Amplitude si integra con CI e ti consente di aggiungere la copertura analitica al tuo test esistente con il nostro plug-in di unit test.

Stabilire un processo ripetibile per il monitoraggio dell'analisi

Un altro motivo per cui il processo git funziona così bene è che tutti lo seguono in modo coerente, e quindi è naturalmente integrato nella cultura aziendale. Puoi creare processi attorno al monitoraggio delle analisi che possono diventare parte dei flussi di lavoro quotidiani con la stessa facilità. ‍

Il più grande nemico dell'introduzione di un nuovo processo è la mancanza di buy-in . Non puoi semplicemente dire "questo è il modo in cui stiamo facendo le nostre analisi ora" e aspettarti che tutti salgano a bordo. Abbiamo sempre sostenuto che il monitoraggio dell'analisi è collaborativo; quando stai mettendo insieme il tuo piano di monitoraggio, tutti i team interessati dovrebbero dare una mano a dargli forma.

Ciò significa coinvolgere tutte le principali parti interessate quando si elaborano nuovi processi: il team di prodotto, il team di dati/analisti e il team di ingegneri. L'esperienza unica di questi team ti aiuterà a decidere:

• Quali sono i tuoi obiettivi aziendali
• Le metriche che utilizzerai per determinare se questi obiettivi vengono raggiunti
• Quale convenzione di denominazione utilizzerai per gli eventi e altre tassonomie simili. (ad es. è "songPlayed" o "song_played"? Maggiori dettagli su questo nel nostro pezzo sulle migliori pratiche)

Concordare insieme questi processi è un ottimo primo passo per ottenere il consenso a livello di organizzazione e renderlo parte della tua cultura. Una volta che hai un piano di tracciamento, è importante identificare chi ne assume la responsabilità: attribuirlo a "tutti" non funziona. Hai bisogno che quella persona si assuma la responsabilità e la porti avanti.

Non stai aggiungendo questi processi sopra ad altri, li stai Se desideri creare processi ripetibili come questi nella tua cultura organizzativa, rendili il più semplici possibile affinché i team li adottino nei loro flussi di lavoro. È improbabile che i membri del team vogliano interrompere i loro flussi di lavoro consolidati per adattarsi a nuovi processi. Invece, guarda come questi processi possono adattarsi perfettamente a quelli esistenti. Ad esempio, Amplitude lo rende davvero semplice con la nostra interfaccia a riga di comando: questo garantisce agli sviluppatori di poter strumentare il tuo piano di tracciamento in modo semplice e accurato senza dover lasciare il loro ambiente preferito.

Allinea i tuoi obiettivi di tracciamento con i tuoi obiettivi di business

Se stai costruendo prodotti agili (ad esempio utilizzando il framework build, measure, learn), utilizzerai sicuramente i dati per prendere decisioni. Tuttavia : quando decidi in quale direzione andare dopo, non iniziare con i dati, inizia con una domanda.

Innanzitutto, cosa stai cercando di ottenere? Stai cercando di mettere insieme una nuova funzionalità o eseguire un esperimento? Forse hai una serie di obiettivi specifici per questo trimestre. Qualunque cosa sia, cerca di non pensare a ciò che i dati potrebbero essere in grado di fare per te. Invece, costruisci la tua cultura per porre le domande giuste e vedere se hai i dati per rispondere a queste domande. Quindi, pensa a cose come:

• Le metriche di successo per gli obiettivi o gli esperimenti delineati
• Gli eventi che devi monitorare per essere al corrente di queste metriche
• Quali azioni hai già intrapreso in base alle informazioni esistenti: hanno funzionato?

Se scopri di non poter rispondere a queste domande con i dati che stai raccogliendo, significa che devi modificare il tuo piano di tracciamento. Più dati non sono sempre la risposta, ma i dati accurati lo sono sicuramente.

Parte della costruzione di una buona cultura dei dati è aiutare il team a capire che il modo in cui utilizzi i tuoi dati è il tuo elemento di differenziazione, non i dati stessi. Inizia a incoraggiare la curiosità naturale e a celebrare l'impatto del prendere decisioni basate su intuizioni interne.

Una buona cultura dei dati e dell'analisi è un processo continuo

Non puoi costruire una cultura dall'oggi al domani. Consenti alla tua cultura desiderata di crescere dimostrando il valore dei nuovi processi e celebrando i successi che ne derivano. Cerca di promuovere l'atteggiamento nei confronti dell'utilizzo dei dati per verificare intuizioni e idee, piuttosto che raccogliere dati perché è "bello avere".

Mantenere il monitoraggio degli eventi in primo piano tra i team non deve essere complicato all'inizio. Probabilmente non è necessario iniziare con più di dieci domande. Fissali, ripetili tra i team e lavora da lì. Non è necessario ottimizzare per ogni eventualità fin dall'inizio.

I consigli delineati in questo post sul blog sono solo un punto di partenza. Una volta preso un buon ritmo, noterai che i processi che hai stabilito sono una seconda natura tra i team; proprio come con la scrittura del codice, l'analisi del monitoraggio diventerà una pratica più standardizzata e verificabile.

L'utilizzo di Amplitude rende questo processo estremamente semplice: il tuo piano di tracciamento esiste come documento dinamico che si integra perfettamente nel flusso di lavoro del tuo team. Se sei interessato a provare Amplitude per la tua azienda, crea un account oggi o prenota una demo con il nostro team per saperne di più.