Due in una scatola (se puoi) e tutti nella documentazione (sempre).
In un contesto IT, "due in una scatola" si riferisce a due server o componenti progettati per funzionare insieme per fornire ridondanza e maggiore affidabilità. Questa configurazione può garantire che in caso di guasto di un componente, l'altro subentri nelle sue operazioni, mantenendo così la continuità del servizio. L'obiettivo di avere "due in una scatola" è fornire alta disponibilità e ripristino di emergenza. Questo vale anche per i ruoli umani in un'organizzazione; tuttavia, è raramente implementato.
Diamo un'occhiata a un esempio pertinente di Analytics. Probabilmente tutti conosciamo per nome una persona nella nostra azienda o organizzazione che è la persona di riferimento per Analytics. Sono quelli che hanno report o dashboard intitolati a loro: Mike's Report o Jane's Dashboard. Certo, ci sono altre persone che conoscono l'analisi, ma questi sono i veri campioni che sembrano sapere come fare le cose più difficili e superare le scadenze. Il problema è che queste persone sono sole. In molti casi sotto pressione, non lavorano con nessuno in quanto ciò potrebbe rallentarli ed è qui che inizia il problema. Non pensiamo mai che perderemo questa persona. Mi asterrò dal tipico "diciamo che vengono investiti da un autobus" o utilizzando un esempio sfruttando le attuali opportunità del mercato del lavoro e dire qualcosa di positivo come "hanno vinto alla lotteria!", perché dovremmo tutti fare la nostra parte per essere positivi in questi giorni.
la nostra storia
Arriva il lunedì mattina e il nostro esperto di analisi e campione MJ ha presentato le proprie dimissioni. MJ ha vinto alla lotteria e ha già lasciato il paese senza preoccupazioni al mondo. Il team e le persone che conoscono MJ sono entusiasti e gelosi, ma il lavoro deve andare. Ora è quando il valore e la realtà di ciò che MJ stava facendo sta per essere compreso. MJ era responsabile della pubblicazione finale e della convalida dell'analisi. Sembravano sempre in grado di migliorare l'efficienza o apportare quel cambiamento difficile prima di fornire l'analisi a tutti. A nessuno importava davvero come fosse fatto ed era sicuro del fatto che fosse appena successo, e MJ era una Rock Star individuale di Analytics, quindi gli fu concesso un livello di autonomia. Ora, mentre il team inizia a raccogliere i pezzi, le richieste, i problemi quotidiani, le richieste di modifica sono in perdita e iniziano ad arrampicarsi. Report/Dashboard si trovano in stati sconosciuti; alcune risorse non si sono aggiornate durante il fine settimana e non sappiamo perché; le persone chiedono cosa sta succedendo e quando le cose saranno risolte, le modifiche che MJ ha detto che sono state fatte non vengono visualizzate e non abbiamo idea del perché. La squadra sembra messa male. È un disastro e ora tutti odiamo MJ.
Le lezioni
Ci sono alcuni take-away facili e ovvi.
- Non permettere mai a un individuo di lavorare da solo. Sembra buono, ma in team agili più piccoli non abbiamo il tempo o le persone per farlo accadere. Le persone vanno e vengono, i compiti sono molti, quindi è divide et impera in nome della produttività.
- Tutti devono condividere le proprie conoscenze. Suona anche bene, ma stiamo condividendo con la persona o le persone giuste? Tieni presente che molti vincitori della lotteria sono colleghi. Anche le sessioni di condivisione delle conoscenze tolgono tempo alle attività e la maggior parte delle persone investe in competenze e conoscenze solo nel momento in cui è necessario.
Quindi, quali sono alcune soluzioni reali che tutti possono essere in grado di implementare e sostenere?
Iniziamo con la gestione della configurazione. Useremo questo come termine generico per diversi argomenti simili.
- Cambio gestione: Il processo di pianificazione, implementazione e controllo delle modifiche ai sistemi software in modo strutturato e sistematico. Questo processo mira a garantire che le modifiche vengano apportate in modo controllato ed efficiente (con la possibilità di ripristinarle), con la minima interruzione del sistema esistente e il massimo vantaggio per l'organizzazione.
- Gestione Progetto: La pianificazione, l'organizzazione e il controllo dei progetti di sviluppo software per garantire che siano completati in tempo, entro il budget e secondo gli standard di qualità desiderati. Implica il coordinamento di risorse, attività e compiti durante tutto il ciclo di vita dello sviluppo del software per raggiungere gli obiettivi del progetto e consegnare il prodotto software nei tempi previsti.
- Integrazione continua e distribuzione continua (CI/CD): Il processo di automazione della creazione, del test e della distribuzione del software. L'integrazione continua richiede l'unione regolare delle modifiche al codice in un repository condiviso e l'esecuzione di test automatizzati per rilevare gli errori nelle prime fasi del processo di sviluppo. Il Continuous Delivery/Deployment comporta il rilascio automatico in produzione di modifiche al codice testate e convalidate, consentendo rilasci rapidi e frequenti di nuove funzionalità e miglioramenti.
- Controllo della versione: Il processo di gestione delle modifiche al codice sorgente e ad altri artefatti software nel tempo utilizzando strumenti software specializzati. Consente agli sviluppatori di collaborare su una base di codice, mantenere una cronologia completa delle modifiche e sperimentare nuove funzionalità senza influire sulla base di codice principale.
Tutto quanto sopra si riferisce a buone pratiche di sviluppo software. Le analisi che guidano e gestiscono il business non meritano di meno in quanto sono mission-critical per il processo decisionale. Tutte le risorse analitiche (lavori ETL, definizioni semantiche, definizioni metriche, report, dashboard, storie...
L'utilizzo di Configuration Management ci consente di continuare a funzionare in buono stato. Le risorse sono versionate in modo da poter vedere cosa è successo nel loro ciclo di vita, sappiamo chi sta lavorando su cosa insieme ai progressi fatti e alle tempistiche, e sappiamo che la produzione andrà avanti. Ciò che non è coperto da alcun processo puro è il trasferimento della conoscenza e la comprensione del perché le cose sono come sono.
Ogni sistema, database e strumento di analisi ha le proprie stranezze. Cose che li fanno andare veloci o lenti, elementi che li fanno comportare in un certo modo o producono un risultato desiderato. Queste possono essere impostazioni a livello di sistema o globale o cose all'interno della progettazione delle risorse che le fanno funzionare esattamente come dovrebbero. Il problema è che la maggior parte di queste cose vengono apprese nel tempo e non sempre c'è un posto dove documentarle. Anche se passiamo ai sistemi cloud in cui non controlliamo più come viene eseguita l'applicazione e ci affidiamo al fornitore per renderlo il più veloce possibile, l'ottimizzazione delle definizioni continua all'interno delle nostre risorse per sbloccare esattamente ciò che stiamo cercando. Questa conoscenza è ciò che deve essere catturato e condiviso mettendolo a disposizione degli altri. Questa conoscenza deve essere richiesta come parte della documentazione delle risorse e resa parte integrante del controllo della versione e del processo di check-in e approvazione di CI/CD e in alcuni casi anche come parte di una lista di controllo prima della pubblicazione delle cose da fare e da non fare Fare.
Non ci sono risposte magiche o intelligenza artificiale per coprire le scorciatoie nei nostri processi di analisi o la loro mancanza. Indipendentemente dalle dimensioni del team che mantiene il flusso di dati e analisi, un investimento in un sistema per tenere traccia delle modifiche, controllare la versione di tutte le risorse e aiutare a documentare il processo di sviluppo e acquisire le conoscenze è un must. L'investimento in processi e tempo in anticipo farà risparmiare un sacco di tempo sprecato in seguito a capire le cose per mantenere uno stato sano della nostra analisi. Le cose accadono ed è meglio avere una polizza assicurativa per MJ e altri vincitori della lotteria.
