Ho parlato con molti colleghi professionisti dell’analisi che sono convinti di non voler mai toccare la “produzione”. Mentre ci sono buone ragioni per stare attenti ogni volta che si apportano modifiche che potrebbero avere un impatto sui clienti, credo che man mano che il software diventa sempre più data-driven, è fondamentale trovare modi sicuri per consentire ai team di Analytics di costruire e distribuire applicazioni data-driven.
Che cos’è la produzione?
Primo, qualche definizione del termine. “Produzione” è un ambiente. Comunemente ci sono alcuni ambienti dove il codice può essere eseguito (in ordine di progressione):
- Sviluppo locale
- Sviluppo remoto
- Staging / QA
- Produzione
Ogni “applicazione” avrà più ambienti, uno dei quali sarà quello rivolto agli utenti non sviluppatori. Quello che affronta gli utenti non sviluppatori è tipicamente chiamato “produzione”.
Ecco la mia tesi: È fondamentale per i team di Analytics avere un impatto sulle applicazioni rivolte al cliente1Ci sono, naturalmente, eccezioni a questo e diversi tipi di applicazioni avranno diversi “gradi” di data-driven-ness. Storicamente, alcune aziende hanno esitato a rendere le loro applicazioni più guidate dai dati perché i loro ingegneri del software non avevano competenze in materia di dati e avevano paura di lasciare che il team di analisi avesse un impatto sull’applicazione. Naturalmente dovreste prendere decisioni sull’aggiunta di nuove funzionalità in base a quanto saranno preziose, non semplicemente perché qualche blogger vi ha detto di farlo. Se non è possibile abilitarlo in modo sicuro, allora dovreste modificare la vostra applicazione rivolta al cliente in modo tale da renderlo possibile.
Se avete trovato quest’ultimo paragrafo scioccante, sto per farvi saltare i calzini: tutti i vostri analisti stanno distribuendo in produzione ogni giorno, già. Lasciate che vi accompagni attraverso il mio preferito2e più odioso. La gente mi ama alle feste. linea di interrogazione:
- Lo strumento di BI che configuri per fornire report agli utenti all’interno della tua azienda – non è produzione?
- Lo script R che ha assemblato i dati, li pulisce, e fornisce visualizzazioni per un PPT che viene inviato via e-mail al team esecutivo, non è produzione?
- Quel file Excel (pieno di codice) che viene utilizzato per prendere una decisione di inventario multimilionaria, non è produzione?
Ricorda: solo perché non hai un ambiente di sviluppo non significa che il tuo ambiente rivolto all’utente non sia di produzione!
Per molte startup, la gente usa “produzione” come un’abbreviazione per riferirsi alla loro web app rivolta all’utente (a seconda della fase dell’azienda, può essere o non essere ancora un monolite di rails). Oltre a dire che dovreste smettere di usare termini così poco chiari, voglio sostenere la necessità di pensare al perché potreste voler permettere ad analisti non ingegneri e scienziati dei dati di distribuire un’applicazione rivolta al cliente. Finirò con alcune strategie su come potreste rendere tutto questo operativo.
Perché abilitare il team di analisti ad avere un impatto sui clienti?
Costruire applicazioni guidate dai dati è la posta in gioco per la moderna ingegneria del software e lo sviluppo dei prodotti. Le applicazioni di domani avranno dati integrati da cima a fondo e se c’è un muro tra i vostri esperti di dati e i vostri sviluppatori di applicazioni avrete un brutto periodo.
Qui ci sono alcuni esempi di prodotti guidati dai dati che potresti voler costruire:
- Implementare il campionamento Thompson per testare le varianti del sito con banditi a più braccia
- Cluster di clienti per email di marketing mirate o varianti di landing page
- Prevedere i clienti che probabilmente si ritireranno e dare solo a questi clienti un codice coupon
- Introdurre algoritmi di raccomandazione del prodotto/classificazione della ricerca
Se vuoi costruire questi prodotti guidati dai dati, vorrai che i tuoi esperti di dati ci lavorino. Ecco alcune ragioni per pensare di sfumare la linea di demarcazione tra il tuo Analytics3A come al solito, in questo post uso il termine “Analytics” e “analisti” nel modo più ampio possibile, includendo scienziati di dati, analisti di dati e altri esperti di dati. e il resto del tuo team di ingegneria del software:
- Gli scienziati di dati sono i tuoi esperti di algoritmi, e l’integrazione continua è importante
- Vuoi che la tua app sia alimentata dai dati!
- Gli analisti conoscono meglio i dati, quindi hanno meno probabilità di commettere errori
- Produrre il lavoro di qualcun altro è un lavoro di merda
- Bloccare l’iterazione degli analisti con una prioritizzazione impegnativa rallenta tutti e porta alla frustrazione
Non è controverso permettere ai product manager o ai designer di distribuire nuovi contenuti al sito tramite un CMS. Se questo supportasse markdown, dovrebbe essere anche banale. Si potrebbe anche permettere agli analisti di modificare i pesi degli algoritmi tramite un CMS, quindi perché non permettere loro di distribuire un modello, purché questo modello sia conforme a qualsiasi API che l’applicazione si aspetta? Naturalmente, poiché il vostro team di analisti potrebbe non avere tutti gli strumenti o le competenze per lavorare su un’applicazione web complessa, volete assicurarvi che possano apportare queste modifiche in un modo che sia sicuro ed efficace (cioè, possono usare gli strumenti con cui hanno familiarità e le altre parti sono astratte).
Come permettere al team di analisti di influenzare i clienti?
Ora che abbiamo discusso perché questa potrebbe essere una buona idea, possiamo parlare di alcuni modi per farlo in modo sicuro ed efficace. Ecco alcuni esempi che ho visto in passato (e mi piacerebbe saperne di più se conosci qualche buon modello):
- Micro servizi
- L’algoritmo di classificazione dei prodotti può vivere dietro un’API in modo che il team di analisi possa implementare i cambiamenti senza toccare il resto dell’app
- Profili degli utenti
- Puoi persistere gli attributi chiave degli utenti in una tabella alla quale la tua web app ha accesso (es.g., tramite una cache redis) che è gestita dal team di analisi (ETL, ML, qualsiasi cosa, purché l’API non cambi)
- Pesi / Punteggi
- Se si ha un modello che lavora su pesi o attributi per creare un “punteggio” (ad es, un punteggio di rischio di frode) allora puoi tenere quei pesi in una tabella a cui il team di analisi può avere accesso in scrittura
Ho scritto prima del pattern di design code-as-configuration, e in generale questo è un ottimo pattern per permettere ai non-ingegneri di implementare il codice negli ambienti di produzione. L’amico del blog Harlan Harris ha anche scritto sull’uso di linguaggi specifici del dominio per facilitare il test, il coordinamento e la distribuzione di modelli di apprendimento automatico in produzione.