Du en skatolo (se vi povas) kaj ĉiuj en dokumentado (ĉiam).
En IT-kunteksto, "du en skatolo" rilatas al du serviloj aŭ komponentoj kiuj estas dizajnitaj por labori kune por disponigi redundon kaj pliigitan fidindecon. Ĉi tiu aranĝo povas certigi, ke se unu komponanto malsukcesas, la alia transprenos ĝiajn operaciojn, tiel konservante la kontinuecon de servo. La celo havi "du en skatolo" estas provizi altan haveblecon kaj katastrofan reakiron. Ĉi tio validas ankaŭ por homaj roloj en organizo; tamen, ĝi malofte estas efektivigita.
Ni rigardu koncernan ekzemplon de Analytics. Ni ĉiuj verŝajne konas personon en nia kompanio aŭ organizo laŭnome, kiu estas la "irebla" persono por Analytics. Ili estas tiuj, kiuj havas raportojn aŭ panelojn nomitajn laŭ ili - Mike's Report aŭ Jane's Dashboard. Certe, estas aliaj homoj, kiuj konas analizojn, sed ĉi tiuj estas la veraj ĉampionoj, kiuj ŝajnas scii kiel fari la plej malfacilajn aferojn kaj superatingi limdatojn. La afero estas, ke ĉi tiuj homoj staras solaj. En multaj kazoj sub premo, ili ne funkcias kun iu ajn ĉar tio povus malrapidigi ilin kaj ĉi tie komenciĝas la problemo. Ni neniam pensas, ke ni perdos ĉi tiun homon. Mi sin detenos de la tipa "ni diru, ke ili estas trafitaj de buso" aŭ uzos ekzemplon utiligante la nunajn labormerkatajn ŝancojn kaj diros ion pozitivan kiel "ili gajnis la loterion!", ĉar ni ĉiuj devus fari nian parton por esti pozitivaj. ĉi tiuj tagoj.
la Rakonto
Venas lundo matene, kaj nia analiza fakulo kaj ĉampiono MJ prezentis sian eksiĝon. MJ gajnis la loterion kaj jam forlasis la landon sen zorgo en la mondo. La teamo kaj homoj kiuj konas MJ estas ravitaj kaj ĵaluza, tamen laboro devas iri. Nun estas kiam la valoro kaj realeco de tio, kion MJ faris, estas komprenontaj. MJ respondecis pri la fina publikigo kaj validumado de la analizo. Ili ĉiam ŝajnis povi plibonigi efikecon aŭ fari tiun malfacilan ŝanĝon antaŭ provizi la analizojn al ĉiuj. Neniu vere zorgis kiel ĝi fariĝis kaj estis sekura en la fakto ke ĝi ĵus okazis, kaj MJ estis Analytics individua Rokstelulo do nivelo de aŭtonomeco estis donita. Nun kiam la teamo komencas repreni la pecojn, la petojn, la ĉiutagajn aferojn, la modifpetojn ili estas en perdo kaj komencas miksi. Raportoj / Paneloj troviĝas en nekonataj ŝtatoj; iuj aktivoj ne ĝisdatiĝis dum la semajnfino, kaj ni ne scias kial; homoj demandas kio okazas kaj kiam aferoj estos riparitaj, redaktoj kiujn MJ diris ke estis faritaj ne aperas kaj ni ne scias kial. La teamo aspektas malbone. Estas katastrofo kaj nun ni ĉiuj malamas MJ.
La lecionoj
Estas kelkaj facilaj kaj evidentaj prenoj.
- Neniam permesu al individuo labori sola. Sonas bone sed en pli malgrandaj lertaj teamoj, ni ne havas tempon aŭ homojn por fari tion. Homoj venas kaj iras, taskoj estas multaj, do ĝi estas dividi kaj konkeri en la nomo de produktiveco.
- Ĉiu devas dividi sian scion. Ankaŭ sonas bone, sed ĉu ni kundividas kun la ĝusta persono aŭ homoj? Memoru, ke multaj loteriogajnintoj estas kunlaborantoj. Fari scion kundividas sesiojn ankaŭ prenas tempon for de taskoj kaj plej multaj homoj nur investas en kapabloj kaj scio ĝuste ĝustatempe kiam ĝi estas bezonata.
Do, kiuj estas iuj realaj solvoj, kiujn ĉiuj povas efektivigi kaj postresti?
Ni komencu kun Agorda Administrado. Ni uzos ĉi tion kiel la tegmentan terminon por pluraj similaj temoj.
- Ŝanĝadministrado: La procezo de planado, efektivigado kaj kontrolado de ŝanĝoj al softvarsistemoj en strukturita kaj sistema maniero. Ĉi tiu procezo celas certigi, ke ŝanĝoj estas faritaj en kontrolita kaj efika maniero (kun la kapablo reveni), kun minimuma interrompo al la ekzistanta sistemo kaj maksimuma profito al la organizo.
- Projekt-administrado: La planado, organizo kaj kontrolo de softvarprojektoj por certigi ke ili estas kompletigitaj ĝustatempe, ene de buĝeto, kaj laŭ la dezirataj kvalitnormoj. Ĝi implikas la kunordigon de resursoj, agadoj kaj taskoj laŭlonge de la programaro-disvolva vivociklo por atingi la projektcelojn kaj liveri la programaron laŭplane.
- Kontinua Integriĝo kaj Kontinua Livero (CI/KD): La procezo de aŭtomatigo de la konstruaĵo, testado kaj deplojo de programaro. Kontinua Integriĝo postulas regule kunfandi kodŝanĝojn en komunan deponejon kaj ruli aŭtomatigitajn testojn por detekti erarojn frue en la evoluprocezo. Kontinua Livero/Deplojo implikas aŭtomate liberigi provitajn kaj validigitajn kodŝanĝojn en produktadon, permesante rapidajn kaj oftajn eldonojn de novaj funkcioj kaj plibonigoj.
- Versio-Kontrolo: La procezo de administrado de ŝanĝoj al fontkodo kaj aliaj softvarartefaktoj laŭlonge de tempo uzante specialigitajn programarajn ilojn. Ĝi permesas al programistoj kunlabori sur kodbazo, konservi kompletan historion de ŝanĝoj kaj eksperimenti kun novaj funkcioj sen tuŝi la ĉefan kodbazon.
Ĉio ĉi-supra rilatas al bonaj praktikoj pri programaro-disvolvado. Analizoj, kiuj stiras kaj administras la komercon, meritas ne malpli, ĉar ili estas misiaj kritikaj por decidi. Ĉiuj analizaj aktivoj (ETL-laboroj, semantikaj difinoj, metrikaj difinoj, raportoj, paneloj, rakontoj... ktp) estas nur kodaj fragmentoj kun vida interfaco por desegnado kaj ŝajne etaj ŝanĝoj povas malbonodori operaciojn.
Uzado de Agorda Administrado kovras nin por daŭre funkcii en bona stato. Aktivaĵoj estas versionitaj por ke ni povu vidi kio okazis en ilia vivdaŭro, ni scias kiu laboras pri kio kune kun la progreso farita kaj templinioj, kaj ni scias ke la produktado daŭros. Kio ne estas kovrita per iu pura procezo estas la translokigo de scio kaj la kompreno de kial aferoj estas kiel ili estas.
Ĉiu sistemo, datumbazo kaj analiza ilo havas siajn proprajn strangaĵojn. Aferoj kiuj igas ilin iri rapide aŭ malrapide, aĵoj kiuj igas ilin konduti certan manieron aŭ produkti deziratan rezulton. Ĉi tiuj povas esti agordoj je sistemo aŭ tutmonda nivelo aŭ aferoj ene de la aktiva dezajno, kiuj igas ilin funkcii ĝuste kiel ili devus. La problemo estas, ke la plej multaj el ĉi tiuj aferoj estas lernitaj laŭlonge de la tempo kaj ne ĉiam estas loko por dokumenti ilin. Eĉ kiam ni moviĝas al Nubaj sistemoj, kie ni ne plu kontrolas kiel la aplikaĵo plenumas kaj ni fidas je la provizanto por fari ĝin kiel eble plej rapide, la ĝustigo de difinoj daŭras ene de niaj aktivaĵoj por malŝlosi ĝuste tion, kion ni serĉas. Ĉi tiu scio estas tio, kio devas esti kaptita kaj dividita, disponigante ĝin al aliaj. Ĉi tiu scio devas esti postulata kiel parto de la dokumentado de aktivoj kaj igita integrita parto de la versiokontrolo & CI/KD-kontrolo kaj aprobprocezo kaj en kelkaj kazoj eĉ kiel parto de kontrola listo antaŭ publikigo de aferoj farendaj kaj ne. faru.
Ne ekzistas magiaj respondoj aŭ AI por kaŝi ŝparvojojn en niaj analizaj procezoj aŭ mankas tie. Sendepende de la grandeco de la teamo, kiu konservas la datumojn kaj analizojn, investo en sistemo por spuri ŝanĝojn, versioni ĉiujn aktivojn kaj helpi dokumenti la disvolvan procezon kaj kapti scion estas nepra. Investado en procezoj kaj tempo antaŭe ŝparos multon da malŝparita tempo poste eltrovi aferojn por konservi sanan staton de nia analizo. Aferoj okazas kaj estas plej bone havi asekuron por MJ-oj kaj aliaj loteriogajnintoj.
