Chi dovrebbe davvero possedere il tuo piano di monitoraggio?

Nota del redattore: questo articolo è stato originariamente pubblicato sul blog di Iterativamente l'11 gennaio 2021.

"I dati sono uno sport di squadra" è qualcosa in cui crediamo fermamente e di cui parliamo spesso in Amplitude. I piani di monitoraggio di Analytics non sono diversi: i piani di monitoraggio (e la loro strumentazione) sono collaborativi per natura. Funzionano meglio quando i team interessati si uniscono.

Prendiamo l'esempio di una nuova versione di funzionalità. Il team del prodotto ha definito gli obiettivi e le metriche per questa nuova funzionalità e avrà una visione di quale monitoraggio degli eventi è necessario per misurare tali metriche. I team di sviluppo iOS, Android e Web sono responsabili della strumentazione (e idealmente del test) di tali eventi nel codice e avranno un'opinione su ciò che è fattibile. Un analista o un ingegnere di analisi è responsabile della modellazione dei dati e si occuperà della loro struttura, e potresti avere diversi team responsabili della creazione di report e dell'analisi dei dati in diversi strumenti. Insomma, nelle aziende data-led l'analytics coinvolge quasi tutti.

L'esempio parla di quanto sia realmente complesso il monitoraggio dell'analisi e parla anche dell'importanza della collaborazione quando si definiscono e si acquisiscono gli eventi giusti, implementandoli in modo accurato e facilitando l'esplorazione dei dati da parte dei consumatori di dati. Detto questo, con così tante persone coinvolte, il monitoraggio dell'analisi diventa facilmente una patata bollente.

Se è di proprietà di tutti, non è di proprietà di nessuno

Con così tante parti interessate coinvolte, il piano di tracciamento diventa spesso una responsabilità condivisa, senza un chiaro proprietario. E con la responsabilità condivisa arriva poca responsabilità.

Abbiamo parlato con molte aziende che vogliono (ri)creare processi attorno al monitoraggio dell'analisi. Di solito ruota attorno a un foglio di calcolo o a una pagina Confluence o Notion. Sebbene sia per lo più manuale e non sia possibile applicare il piano di tracciamento nel codice, si rivela utile all'inizio e costringe i team a pensare di più al tracciamento degli eventi.

Tuttavia, dopo alcuni mesi, la pagina Notion o Google Spreadsheet diventa obsoleta: il monitoraggio per l'ultima versione è stato documentato solo in una storia di Jira e per alcune altre versioni di funzionalità ora non è chiaro se il monitoraggio sia stato implementato o meno. Nessuno si assume la responsabilità di mantenere aggiornato il piano di monitoraggio.

Quindi, come si cambia questo in meglio e chi è nella posizione migliore per possedere il monitoraggio delle analisi?

Inizia mettendo l'analisi in primo piano e al centro

Prima di addentrarci nella questione della proprietà, dobbiamo menzionare le basi necessarie per il successo del monitoraggio dell'analisi: il monitoraggio degli eventi è importante e senza di esso rimani all'oscuro. La realtà è che per la maggior parte dei team l'analisi è un ripensamento. Ecco un esempio che vediamo sempre:

• PM lavora su un rilascio
• Il rilascio avviene
• Il CEO chiede al PM come sta andando
• PM: "Fammi chiedere al team di 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

Se l'analisi non diventa parte integrante di ogni versione, ciò accadrà più e più volte e non importa se il tuo piano di monitoraggio sembra davvero lucido e aggiornato. Hai bisogno del consenso di tutte le parti interessate (così come dei tuoi team di leadership) che il monitoraggio dell'analisi è importante tanto quanto la funzionalità stessa. Nessun tracciamento, nessun rilascio.

Hai bisogno di una chiara responsabilità, tempo e risorse per responsabilizzare i team interessati e quindi devi incorporare il monitoraggio degli eventi e le metriche di successo fino al livello del ticket Jira (l'operazione viene eseguita solo quando il codice di monitoraggio viene spedito insieme al resto del codice).

Cosa abbiamo imparato da oltre 400 interviste con professionisti dei dati e dei prodotti

In due anni abbiamo intervistato oltre 400 product manager, data team e ingegneri. Abbiamo visto alcune cose.

Ovviamente, il tuo piano di monitoraggio e il processo che lo circonda sono unici per la tua attività, struttura del team e verticale (ed è probabilmente per questo che è così difficile farlo bene). Un piano di monitoraggio per un'azienda di e-commerce avrà un aspetto molto diverso da un piano di monitoraggio per un'azienda SaaS B2B. Hanno diverse parti interessate coinvolte e risolvono realtà completamente separate. Più comunemente, possiamo suddividere ciò che abbiamo visto in base alle dimensioni dell'azienda.

Startup

Per le piccole aziende, il processo di monitoraggio è solitamente ad hoc. È naturale poiché sono coinvolte pochissime persone e rende la complessità facile (più o meno) da gestire. Molto spesso, vediamo un responsabile del prodotto o un responsabile della crescita assumere la responsabilità in questa fase del viaggio di un'azienda.

PMI

In un'azienda di medie dimensioni, il processo ricade tipicamente sulla testa dei dati/analisi. Ora ci sono più parti interessate coinvolte e la complessità può facilmente diventare un problema. In questa fase c'è una precisa necessità di proprietà per limitare i danni e di solito ciò ricade su qualcuno nel team di dati.

Imprese

Nelle aziende più grandi, la persona che alla fine possiede il piano di tracciamento sarà solitamente il capo dell'analisi del prodotto. Per le società di e-commerce, sarà spesso il capo dell'e-commerce. Spesso non sarà la persona quotidiana che mantiene il piano o applica il processo, sarà qualcuno all'interno del loro team che è responsabile.

Abbiamo visto vari gradi di successo da questi tipi di configurazioni. Quindi, cosa pensiamo funzioni meglio?

Cosa funziona: il team del prodotto è il proprietario finale

Questo è ciò che sappiamo: il miglior processo di proprietà si verifica quando il team del prodotto agisce come proprietario finale. I product manager dovrebbero essere il driver principale e garantire che il monitoraggio dell'analisi sia parte di ogni rilascio di funzionalità . A seconda delle dimensioni del tuo team, potrebbe trattarsi di uno o più product manager o di un analista di prodotto dedicato. Dovrebbero essere ritenuti responsabili del monitoraggio dell'analisi come parte del loro ruolo e degli OKR.

Ma come accennato in precedenza, i dati sono uno sport di squadra e consigliamo ai team di riunirsi per definire cose come la denominazione degli eventi e la tassonomia. Ingegneri e team di dati avranno prospettive importanti in quanto ciò influenza anche la loro quotidianità. Sebbene il team del prodotto sia l'esecutore e il proprietario finale, non dovrebbe mai lavorare in un silo o prendere decisioni importanti senza coinvolgere le parti interessate giuste.

La creazione di un comitato consultivo che rappresenti tutte le parti interessate ha funzionato bene per le aziende con cui abbiamo lavorato. Non tutte le decisioni vanno al comitato consultivo, ma dovrebbero essere il motore all'inizio, definendo la tassonomia e il processo e incontrandosi regolarmente a seconda di quanti cambiamenti di rottura si verificano nel tempo.

Affinché i team di prodotto possiedano con successo questo, è necessario un processo chiaro in atto:

• Avere chiari criteri di successo per le metriche sia qualitative che quantitative come parte di ogni user story. Questi dovrebbero essere definiti dal PM e discussi con il team di dati o gli analisti.
• Tracciamento mancante? Fallisci la costruzione. La nozione di fatto deve evolversi per includere il tracciamento analitico come parte di ogni rilascio. Ciò non significa bloccare i rilasci appena prima del lancio, significa implementare un processo che include considerazioni di tracciamento dall'inizio.
• La collaborazione è fondamentale. Mentre il PM sarà proprietario delle specifiche di tracciamento degli eventi, il team di dati o gli analisti dovrebbero essere disponibili per intervenire e aiutare a definire i dettagli di ciò che dovrebbe essere tracciato.

Consenti ai tuoi product manager di assumersi la responsabilità

Per alcuni PM, possedere il piano di tracciamento è naturale per loro. Vogliono il controllo e hanno l'esperienza. E non hanno nemmeno paura di chiedere aiuto quando ne hanno bisogno. Ma non viene naturale a tutti i PM.

Innanzitutto, deve avvenire un cambiamento culturale: celebrare le prestazioni e il successo di una nuova funzionalità o versione di un prodotto, non il fatto che sia stato spedito! Sorprendentemente, per molti è ancora la spedizione a ricevere elogi, non se il prodotto funziona o meno.

Quindi, come autorizzi il tuo team di prodotto a possedere il piano di monitoraggio? Questo non è un elenco esaustivo, ma si spera che sia un punto di partenza per le persone:

• Formazione regolare : ottenere il monitoraggio degli eventi corretto è tanto un'arte quanto una scienza (vale a dire non è facile), quindi assicurati che il tuo team sia dotato delle conoscenze necessarie per assumerne comodamente la responsabilità. La formazione può essere pranzo e apprendimento, workshop o sessioni individuali (ricorda di registrare le tue sessioni per future assunzioni).
• Orario d'ufficio : abbiamo riscontrato un grande successo quando i team di dati ospitano orari di ufficio regolari per altri team per sfruttare le competenze e le conoscenze del team di dati. Assicurati che i team vengano preparati con un ordine del giorno o domande specifiche per evitare che si trasformi in una riunione in stile "support desk".
• Processo chiaro e punti di controllo: non possiamo sottolineare abbastanza l'importanza di un processo definito. Assicurati di avere un processo chiaro che tutti conoscono, capiscono e seguono e includi punti di revisione regolari per garantire la qualità, proprio come le revisioni del codice e le richieste di unione nello sviluppo del software.
• Incorporare un analista : questa non è sempre un'opzione, ovviamente, ma abbiamo visto team di successo incorporare un analista di dati in un team di prodotto a tempo pieno o parziale per possedere il monitoraggio dell'analisi e aiutare i PM con l'esplorazione e l'analisi dei dati.
• Analisi self-service: riteniamo che sia una buona pratica consentire ai PM e a tutti gli altri membri dell'organizzazione di esplorare facilmente i set di dati e ottenere rapidamente risposte alle domande. Amplitude è ottimo per questo e garantisce alti livelli di alfabetizzazione dei dati in tutta la tua azienda.

Un promemoria: i buoni PM non hanno bisogno di conoscere SQL

Perché preoccuparsi del tracciamento degli eventi se non sei comunque in grado di esplorare i dati da solo? Per espandere l'ultimo punto sopra, abbiamo visto aziende con team di dati centrali che possiedono tutti i report e l'analisi dei dati. Ha i suoi vantaggi, ma dalla nostra esperienza può limitare PM e altri e a loro interesserà meno il monitoraggio dell'analisi o la qualità dei dati.

Ricorda, dare ai PM e ad altri l'accesso a Redash o ad altri strumenti basati su SQL non equivale a consentire ai PM di servirsi da soli. Non aspettarti che i tuoi PM conoscano (o apprendano) SQL. Non è il loro lavoro. Fornisci loro invece un'interfaccia utente facile da usare e molta formazione per accompagnare lo strumento e i set di dati. Naturalmente, la conoscenza di SQL ha i suoi ovvi vantaggi e se sei in grado di trovare o formare talenti in tutta l'azienda (pensa al prodotto, al marketing, al successo del cliente, ecc.) Puoi farlo funzionare, ma ha i suoi evidenti svantaggi e limiti.

Se i PM sono in grado di servirsi da soli, è più probabile che esplorino i dati, ad esempio, da una versione recente. Mentre esplorano i dati, è più probabile che si preoccupino della loro qualità, ricchezza e disponibilità. Crea una cultura di responsabilizzazione e costruisci un solido processo attorno al monitoraggio dell'analisi e avrai PM felici, analisti felici, un team di dati felice e persino sviluppatori felici.

Amplitude è qui per aiutarti

Amplitude aiuta i team di dati, i product manager e gli ingegneri a definire, strumentare, verificare e collaborare al monitoraggio delle analisi. Risolviamo in modo proattivo i problemi di qualità dei dati derivanti da nomi di eventi incoerenti e tracciamento mancante e forniamo un flusso di lavoro per gestire l'evoluzione del tracciamento.

Consentiamo ai product manager di assumersi la responsabilità del piano di monitoraggio e di migliorare la collaborazione tra i 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ù.