Dos en una caixa (si pots) i tots en documentació (sempre).
En un context informàtic, "dos en una caixa" es refereix a dos servidors o components dissenyats per treballar junts per proporcionar redundància i una major fiabilitat. Aquesta configuració pot garantir que si un component falla, l'altre es farà càrrec de les seves operacions, mantenint així la continuïtat del servei. L'objectiu de tenir "dos en una caixa" és proporcionar alta disponibilitat i recuperació de desastres. Això també s'aplica als rols humans en una organització; tanmateix, rarament s'implementa.
Vegem un exemple d'Analytics rellevant. És probable que tots coneixem una persona de la nostra empresa o organització per nom que és la persona de referència per a Analytics. Són els que tenen informes o taulers de control que tenen el seu nom: Mike's Report o Jane's Dashboard. Per descomptat, hi ha altres persones que coneixen l'anàlisi, però aquests són els veritables campions que semblen saber com fer les coses més difícils i superar els terminis. El problema és que aquestes persones estan soles. En molts casos sota pressió, no treballen amb ningú, ja que això els podria frenar i aquí és on comença el problema. Mai pensem que anem a perdre aquesta persona. M'abstindré del típic "diguem que són atropellats per un autobús" o utilitzar un exemple aprofitant les oportunitats actuals del mercat laboral i diré alguna cosa positiva com "han guanyat la loteria!", perquè tots hauríem de fer la nostra part per ser positius. aquests dies.
La història que hi ha darrere
Arriba dilluns al matí, i el nostre expert en anàlisi i campió MJ ha presentat la seva renúncia. MJ va guanyar la loteria i ja ha deixat el país sense cap atenció al món. L'equip i les persones que coneixen a MJ estan emocionats i gelosos, però la feina ha d'anar. Ara és quan el valor i la realitat del que estava fent MJ està a punt d'entendre's. MJ va ser responsable de la publicació final i la validació de les analítiques. Sempre semblaven ser capaços de millorar l'eficiència o fer aquest canvi difícil abans de subministrar l'anàlisi a tothom. A ningú li importava realment com es feia i estava segur del fet que acabava de passar, i MJ era una estrella de rock individual d'Analytics, per la qual cosa es va atorgar un nivell d'autonomia. Ara, a mesura que l'equip comença a recollir les peces, les peticions, els problemes diaris, les peticions de modificació, estan perduts i comencen a lluitar. Els informes/taulers es troben en estats desconeguts; alguns actius no s'han actualitzat durant el cap de setmana, i no sabem per què; la gent es pregunta què està passant i quan s'arreglaran les coses, les edicions que MJ va dir que s'havien fet no apareixen i no tenim ni idea de per què. L'equip té mala pinta. És un desastre i ara tots odiem a MJ.
Les lliçons
Hi ha algunes opcions fàcils i evidents per emportar.
- No permeteu mai que una persona treballi sol. Sembla bé, però en equips àgils més petits, no tenim temps ni gent per fer-ho possible. La gent va i ve, les tasques són moltes, així que és dividir i conquerir en nom de la productivitat.
- Tothom ha de compartir els seus coneixements. També sona bé, però estem compartint amb la persona o persones adequades? Tingueu en compte que molts guanyadors de la loteria són companys de feina. Fer sessions d'intercanvi de coneixement també s'allunya de les tasques i la majoria de la gent només inverteix en habilitats i coneixements just a temps quan es necessita.
Aleshores, quines són algunes solucions reals que tothom pot implementar i aconseguir?
Comencem amb la gestió de la configuració. Utilitzarem aquest terme com a terme general per a diversos temes similars.
- Gestió del canvi: El procés de planificar, implementar i controlar els canvis als sistemes de programari d'una manera estructurada i sistemàtica. Aquest procés té com a objectiu garantir que els canvis es realitzin de manera controlada i eficient (amb la possibilitat de revertir), amb la mínima interrupció del sistema existent i el màxim benefici per a l'organització.
- Gestió de projectes: La planificació, l'organització i el control dels projectes de desenvolupament de programari per garantir que es completen a temps, dins del pressupost i amb els estàndards de qualitat desitjats. Implica la coordinació de recursos, activitats i tasques al llarg del cicle de vida del desenvolupament de programari per assolir els objectius del projecte i lliurar el producte de programari en el termini previst.
- Integració contínua i lliurament continu (CI/CD): El procés d'automatització de la creació, prova i desplegament de programari. La integració contínua requereix combinar regularment els canvis de codi en un repositori compartit i executar proves automatitzades per detectar errors al principi del procés de desenvolupament. L'entrega/implementació contínua implica l'alliberament automàtic de canvis de codi provats i validats a la producció, permetent llançaments ràpids i freqüents de noves funcions i millores.
- Control de versions: El procés de gestió dels canvis al codi font i altres artefactes de programari al llarg del temps mitjançant eines de programari especialitzades. Permet als desenvolupadors col·laborar en una base de codi, mantenir un historial complet de canvis i experimentar amb noves funcions sense afectar la base de codi principal.
Tot l'anterior es refereix a bones pràctiques de desenvolupament de programari. Les analítiques que impulsen i dirigeixen el negoci no mereixen menys, ja que són fonamentals per a la presa de decisions. Tots els actius analítics (feines ETL, definicions semàntiques, definicions de mètriques, informes, taulers de control, històries, etc.) són només fragments de codi amb una interfície visual per dissenyar i els canvis aparentment menors poden causar estralls a les operacions.
L'ús de Configuration Management ens permet seguir funcionant en bon estat. Els actius es versionen perquè puguem veure què ha passat al llarg de la seva vida útil, sabem qui està treballant en què juntament amb el progrés i els terminis, i sabem que la producció continuarà. El que no està cobert per cap procés pur és la transferència de coneixement i la comprensió de per què les coses són com són.
Cada sistema, base de dades i eina d'anàlisi tenen les seves pròpies peculiaritats. Coses que els fan anar ràpid o lent, elements que els fan comportar-se d'una determinada manera o produir el resultat desitjat. Aquests poden ser configuracions a nivell de sistema o global o coses dins del disseny d'actius que els fan funcionar tal com haurien de ser. El problema és que la majoria d'aquestes coses s'aprenen amb el temps i no sempre hi ha un lloc per documentar-les. Fins i tot quan passem als sistemes al núvol on ja no controlem com s'executa l'aplicació i confiem en el proveïdor perquè ho faci el més ràpid possible, l'ajust de les definicions continua dins dels nostres actius per desbloquejar exactament el que estem buscant. Aquest coneixement és el que cal capturar i compartir posant-lo a disposició dels altres. Aquest coneixement s'ha d'exigir com a part de la documentació dels actius i formar part integral del control de versions i del procés de registre i aprovació de CI/CD i, en alguns casos, fins i tot com a part d'una llista de verificació abans de publicar les coses a fer i no. fer.
No hi ha respostes màgiques ni intel·ligència artificial per cobrir les dreceres en els nostres processos d'anàlisi o la manca d'aquestes. Independentment de la mida de l'equip que fa que les dades i l'anàlisi flueixin, és imprescindible una inversió en un sistema per fer un seguiment dels canvis, versionar tots els actius i ajudar a documentar el procés de desenvolupament i capturar coneixement. La inversió en processos i temps per endavant estalviarà un munt de temps perdut després d'esbrinar les coses per mantenir un estat saludable de les nostres analítiques. Passen coses i és millor tenir una pòlissa d'assegurança per als MJ i altres guanyadors de la loteria.
