Două într-o cutie (dacă poți) și toată lumea în documentație (întotdeauna).
Într-un context IT, „două într-o cutie” se referă la două servere sau componente care sunt proiectate să funcționeze împreună pentru a oferi redundanță și fiabilitate sporită. Această configurare poate asigura că, dacă o componentă eșuează, cealaltă își va prelua operațiunile, menținând astfel continuitatea serviciului. Scopul de a avea „două într-o cutie” este de a oferi disponibilitate ridicată și recuperare în caz de dezastru. Acest lucru se aplică și rolurilor umane într-o organizație; cu toate acestea, este rar implementat.
Să ne uităm la un exemplu relevant Analytics. Cu toții probabil cunoaștem pe nume o persoană din compania sau organizația noastră, care este persoana de referință pentru Analytics. Ei sunt cei care au rapoarte sau tablouri de bord numite după ele – Raportul lui Mike sau tabloul de bord al lui Jane. Sigur, există și alți oameni care cunosc analize, dar aceștia sunt adevărații campioni care par să știu cum să facă cele mai grele lucruri și să depășească termenele limită. Problema este că acești oameni sunt singuri. În multe cazuri, sub presiune, nu lucrează cu nimeni, deoarece asta i-ar putea încetini și de aici începe problema. Nu credem niciodată că vom pierde această persoană. Mă voi abține de la tipicul „să spunem că sunt loviți de un autobuz” sau să folosesc un exemplu care profită de oportunitățile actuale de pe piața muncii și voi spune ceva pozitiv, cum ar fi „au câștigat la loterie!”, pentru că toți ar trebui să ne facem partea pentru a fi pozitivi. aceste zile.
Povestea
Vine luni dimineața, iar expertul nostru în analiză și campionul MJ și-a prezentat demisia. MJ a câștigat la loterie și a părăsit deja țara fără grijă în lume. Echipa și oamenii care îl cunosc pe MJ sunt încântați și geloși, dar munca trebuie să plece. Acum este momentul în care valoarea și realitatea a ceea ce făcea MJ este pe cale să fie înțelese. MJ a fost responsabil pentru publicarea finală și validarea analizelor. Păreau întotdeauna să fie capabili să îmbunătățească eficiența sau să facă acea schimbare dificilă înainte de a furniza analizele tuturor. Nimănui nu i-a păsat cu adevărat cum s-a făcut și a fost în siguranță în faptul că tocmai s-a întâmplat, iar MJ a fost un individ Rock Star din Analytics, așa că i s-a acordat un nivel de autonomie. Acum, pe măsură ce echipa începe să ridice piesele, cererile, problemele zilnice, cererile de modificare, acestea sunt în pierdere și încep să se amestece. Rapoartele/Tablourile de bord se găsesc în stări necunoscute; unele active nu s-au actualizat în weekend și nu știm de ce; oamenii întreabă ce se întâmplă și când se vor rezolva lucrurile, editările despre care MJ a spus că au fost făcute nu apar și nu avem idee de ce. Echipa arată rău. Este un dezastru și acum cu toții îl urâm pe MJ.
Lectiile
Există câteva lucruri simple și evidente.
- Nu permiteți niciodată unui individ să lucreze singur. Sună bine, dar în echipe mai mici agile, nu avem timp sau oameni pentru a face acest lucru să se întâmple. Oamenii vin și pleacă, sarcinile sunt multe, așa că este împărțit și cucerit în numele productivității.
- Fiecare trebuie să-și împărtășească cunoștințele. De asemenea, sună bine, dar împărtășim cu persoana sau oamenii potriviti? Rețineți că mulți câștigători la loterie sunt colegi. Efectuarea sesiunilor de împărtășire a cunoștințelor ia, de asemenea, timp departe de sarcini și majoritatea oamenilor investesc în abilități și cunoștințe doar la timp atunci când este necesar.
Așadar, care sunt câteva soluții reale pe care toată lumea le poate implementa și le poate sprijini?
Să începem cu gestionarea configurației. Vom folosi acesta ca termen umbrelă pentru mai multe subiecte similare.
- Managementul schimbării: Procesul de planificare, implementare și control al modificărilor sistemelor software într-un mod structurat și sistematic. Acest proces are ca scop asigurarea faptului că modificările sunt efectuate într-o manieră controlată și eficientă (cu capacitatea de a reveni), cu întreruperi minime ale sistemului existent și beneficii maxime pentru organizație.
- Management de proiect: Planificarea, organizarea și controlul proiectelor de dezvoltare software pentru a se asigura că acestea sunt finalizate la timp, în limita bugetului și la standardele de calitate dorite. Aceasta implică coordonarea resurselor, activităților și sarcinilor de-a lungul ciclului de viață al dezvoltării software pentru a atinge obiectivele proiectului și a livra produsul software în termen.
- Integrare continuă și livrare continuă (CI/CD): Procesul de automatizare a construirii, testarii și implementării software-ului. Integrarea continuă necesită îmbinarea regulată a modificărilor codului într-un depozit partajat și rularea de teste automate pentru a detecta erorile la începutul procesului de dezvoltare. Livrarea/Implementarea continuă implică lansarea automată a modificărilor de cod testate și validate în producție, permițând lansări rapide și frecvente de noi funcții și îmbunătățiri.
- Controlul versiunii: Procesul de gestionare a modificărilor codului sursă și a altor artefacte software în timp, folosind instrumente software specializate. Permite dezvoltatorilor să colaboreze la o bază de cod, să mențină un istoric complet al modificărilor și să experimenteze cu noi funcții fără a afecta baza de cod principală.
Toate cele de mai sus se referă la bune practici de dezvoltare software. Analizele care conduc și conduc afacerea nu merită mai puțin, deoarece sunt esențiale pentru luarea deciziilor. Toate elementele de analiză (lucrări ETL, definiții semantice, definiții de metrici, rapoarte, tablouri de bord, povești... etc) sunt doar fragmente de cod cu o interfață vizuală pentru proiectare, iar modificările aparent minore pot face ravagii în operațiuni.
Utilizarea Configuration Management ne acoperă pentru a continua să rulăm într-o stare bună. Materialele sunt versionate, astfel încât să putem vedea ce s-a întâmplat pe durata lor de viață, știm cine lucrează la ce, împreună cu progresele înregistrate și calendarele și știm că producția va continua. Ceea ce nu este acoperit de niciun proces pur este transferul de cunoștințe și înțelegerea de ce lucrurile sunt așa cum sunt.
Fiecare sistem, bază de date și instrument de analiză au propriile sale particularități. Lucruri care îi fac să meargă repede sau încet, elemente care îi fac să se comporte într-un anumit fel sau să producă un rezultat dorit. Acestea pot fi setări la nivel de sistem sau global sau lucruri din designul activelor care le fac să ruleze așa cum ar trebui. Problema este că majoritatea acestor lucruri se învață în timp și nu există întotdeauna un loc unde să le documenteze. Chiar dacă trecem la sistemele Cloud, unde nu mai controlăm modul în care se execută aplicația și ne bazăm pe furnizor pentru a o face cât mai rapid posibil, modificarea definițiilor continuă în cadrul activelor noastre pentru a debloca exact ceea ce căutăm. Această cunoaștere este ceea ce trebuie să fie capturată și împărtășită, punându-le la dispoziție altora. Aceste cunoștințe trebuie să fie solicitate ca parte a documentației activelor și să facă parte integrantă din procesul de verificare și aprobare de control al versiunilor și CI/CD și, în unele cazuri, chiar ca parte a unei liste de verificare înainte de publicarea lucrurilor de făcut și nu. do.
Nu există răspunsuri magice sau AI care să ascundă scurtăturile în procesele noastre de analiză sau lipsa acestora. Indiferent de dimensiunea echipei care menține datele și analizele care circulă, o investiție într-un sistem pentru a urmări modificările, versiunea tuturor activelor și a ajuta la documentarea procesului de dezvoltare și la captarea cunoștințelor este o necesitate. Investițiile în procese și timp în avans vor economisi o grămadă de timp pierdut ulterior descoperind lucruri pentru a menține o stare sănătoasă a analizelor noastre. Lucrurile se întâmplă și cel mai bine este să ai o poliță de asigurare pentru MJ și alți câștigători la loterie.
