La filosofia del DevOps, in cui lo sviluppo si unisce alla manutenzione del software, non sorprende più nessuno. Sta guadagnando terreno una nuova tendenza: il DevOps 2.0 o BizDevOps. In questa filosofia si fondono tre componenti: business, sviluppo e supporto. E proprio come nelle pratiche ingegneristiche del DevOps è alla base della connessione tra sviluppo e supporto, nel BizDevOps l'analisi assume il ruolo di "collante" che unisce sviluppo e business.
Voglio essere sincero: solo ora, leggendo libri specializzati, abbiamo realizzato di aver implementato un vero BizDevOps. È accaduto in modo naturale grazie all'iniziativa dei dipendenti e alla loro incessante passione per il miglioramento. Oggi l'analisi è una parte integrante del processo produttivo dello sviluppo, riducendo significativamente i cicli di feedback e fornendo regolarmente approfondimenti. Vi racconterò nel dettaglio come è organizzato il nostro sistema.
Svantaggi del classico DevOps
Quando si progettano nuovi prodotti per i clienti, le aziende creano un modello ideale di comportamento dei clienti e si aspettano buone conversioni, a partire da cui definiscono i loro obiettivi aziendali e i risultati. Il team di sviluppo si impegna a scrivere un codice di alta qualità. Il supporto, d'altro canto, punta a una completa automazione dei processi, garantendo facilità e comodità nella gestione del nuovo prodotto.
La realtà è spesso che i clienti si trovano ad affrontare un processo piuttosto complicato, le aziende si scontrano con basse conversioni, i team di sviluppo rilasciano correzioni su correzioni, e il supporto è sommerso da un elevato numero di richieste da parte dei clienti. Ti sembra familiare?
Il vero problema risiede in un lungo e inefficace ciclo di feedback, intrinseco al processo. Le aziende e gli sviluppatori, durante la raccolta dei requisiti e ricevendo feedback durante gli sprint, interagiscono con un numero limitato di clienti, i quali hanno una forte influenza sul destino del prodotto. Spesso, ciò che è importante per uno non è affatto rappresentativo dell'intera audience di riferimento.
Comprendere se lo sviluppo del prodotto sta procedendo nella giusta direzione arriva con i report finanziari e i risultati delle ricerche di mercato mesi dopo il lancio. E anche questi, a causa della limitatezza del campione, non permettono di testare le ipotesi su un ampio volume di clienti. In sintesi, il risultato è che ci vuole tempo, è impreciso e inefficace.
Strumento di trofeo
Abbiamo trovato un buon modo per evitarlo. Uno strumento che prima aiutava solo i marketer è ora nelle mani delle aziende e degli sviluppatori. Abbiamo iniziato a utilizzare attivamente l'web analytics per osservare il processo in tempo reale, comprendendo immediatamente cosa sta accadendo. Sulla base di questo pianificare il prodotto stesso e il suo lancio su un ampio volume di clienti.
Se si prevede un miglioramento del prodotto, è possibile esaminare immediatamente quali metriche sono coinvolte e come queste metriche influenzano le vendite e le caratteristiche importanti per il business. In questo modo, si possono scartare subito le ipotesi a basso impatto. Oppure, ad esempio, lanciare una nuova funzionalità a un numero statisticamente significativo di utenti e monitorare in tempo reale le metriche, comprendendo se tutto funziona come previsto. Non aspettare feedback sotto forma di richieste o report, ma monitorare direttamente e apportare rapidamente correzioni al processo di creazione del prodotto. Possiamo lanciare una nuova funzionalità, raccogliere dati statistici precisi dopo tre giorni, apportare modifiche ancora dopo tre giorni — e in una settimana avere un ottimo nuovo prodotto.
È possibile monitorare l'intero funnel, tutti i clienti che sono entrati in contatto con il nuovo prodotto, identificare i punti in cui il funnel si restringeva bruscamente e analizzare le cause. Sia gli sviluppatori che il business ora seguono questo aspetto, che è parte del lavoro quotidiano. Vedono lo stesso percorso del cliente e insieme possono generare idee e ipotesi per il miglioramento.
Questa integrazione tra business e sviluppo, insieme all'analisi, consente di creare prodotti in modo continuo, ottimizzando costantemente, identificando e visualizzando i colli di bottiglia, e l'intero processo nel suo complesso.
È tutto nella complessità
Quando creiamo un nuovo prodotto, non partiamo da un foglio bianco, ma lo integriamo già nella rete esistente di servizi. Durante l'interazione con il nuovo prodotto, il cliente di solito entra in contatto con diverse strutture. Può comunicare con il personale del contact center, con i manager in ufficio, può contattare il supporto, o utilizzare le chat online. Attraverso le metriche, possiamo esempio monitorare il carico sul contact center e capire come gestire al meglio le richieste in ingresso. Possiamo anche comprendere quante persone raggiungono l'ufficio e suggerire come continuare a consigliare il cliente.
Con i sistemi informativi funziona esattamente allo stesso modo. La nostra banca esiste da oltre 20 anni e in questo periodo è stato creato e continua a funzionare un ampio insieme di sistemi eterogenei. L'interazione tra i sistemi backend può talvolta essere imprevedibile. Ad esempio, in un vecchio sistema, su un determinato campo ci sono limitazioni riguardo al numero di caratteri, e a volte questo provoca il crash di un nuovo servizio. Tracciare il bug con metodi standard può essere piuttosto difficile, mentre attraverso l'analisi web diventa elementare.
Siamo arrivati al punto di estrarre e analizzare i messaggi di errore provenienti da tutti i sistemi coinvolti, quelli che vengono mostrati al cliente. Si è scoperto che molti di essi erano obsoleti e non avremmo mai immaginato che potessero in qualche modo influire sul nostro processo.
Lavorare con l'analisi
I nostri analisti web e i team SCRUM di sviluppatori lavorano nella stessa sede. Interagiscono costantemente tra loro. Quando è necessario, i specialisti aiutano a configurare le metriche o a estrarre i dati; per lo più, i membri dei team lavorano autonomamente con il servizio di analisi, che non presenta difficoltà particolari.
L'assistenza è necessaria, ad esempio, se servono alcune dipendenze, filtri aggiuntivi per un tipo limitato di clienti o fonti. Ma nell'architettura attuale, ci troviamo raramente ad affrontare questo.
È interessante notare che l'implementazione dell'analisi non ha richiesto l'installazione di un nuovo sistema IT. Utilizziamo lo stesso software con cui lavoravano in precedenza i marketer. Era solo necessario concordare il suo utilizzo e integrarlo nell'attività e nello sviluppo. Certo, non potevamo semplicemente prendere ciò che aveva il marketing, abbiamo dovuto riconfigurarlo completamente e dare al marketing accesso al nuovo ambiente, in modo che fossero con noi nello stesso campo informativo.
In futuro prevediamo di acquistare una versione migliorata del software per l'analisi web, che permetterà di gestire i crescenti volumi di sessioni elaborate.
Inoltre, stiamo attivamente integrando l'analisi web e i database interni provenienti da CRM e sistemi di contabilità. Combinando i dati, otteniamo una visione completa del cliente in tutte le dimensioni necessarie: per fonti, tipi di clienti e prodotti. I servizi di BI, che aiutano a visualizzare i dati, saranno presto disponibili per tutti i reparti.
Qual è il risultato finale? In pratica, abbiamo integrato l'analisi e il processo decisionale in quello produttivo, il che ha portato a un effetto visibile.
Analisi: non inciampate sugli stessi errori
Infine, voglio condividere alcuni consigli che vi aiuteranno a evitare errori durante la creazione del bizdevops.
- Se l'analisi non può essere eseguita rapidamente, significa che non state facendo l'analisi giusta. Dovete seguire un percorso semplice partendo da un prodotto e poi espandervi.
- È fondamentale avere un team o una persona che comprenda bene l'architettura analitica futura. Dovete decidere in anticipo come scalerete l'analisi, integrandola in altri sistemi e riutilizzando i dati.
- Evitare di generare dati superflui. Le statistiche web contengono, oltre a informazioni utili, anche una grande quantità di dati non pertinenti e di bassa qualità. Questa spazzatura ostacolerà le decisioni e le valutazioni, se non ci sono obiettivi chiari.
- Non fate analisi per il solo gusto di farle. Prima gli obiettivi, la scelta degli strumenti e solo dopo, l'analisi dove avrà effetto.
Il materiale è stato preparato in collaborazione con Olga Chebotar ().
Fonte: habr.com
