DevOps-en filosofia, garapena softwarearen mantentzearekin konbinatzen denean, ez da inor harritzen. Joera berri bat indarra hartzen ari da - DevOps 2.0 edo BizDevOps. Dagoeneko hiru osagai batzen ditu osotasun bakar batean: negozioa, garapena eta laguntza. Eta DevOps-en bezala, ingeniaritza-praktikek garapenaren eta laguntzaren arteko loturaren oinarria osatzen dute, beraz, negozio-garapenetan, analitikak garapena negozioekin batzen duen "kolaren" papera hartzen du.
Berehala aitortu nahi dut: benetako bizdevops bat lortu dugula, orain bakarrik ikasi dugu, liburu adimentsuak irakurri ondoren. Nolabait, langileen ekimenari eta hobetzeko grina ezin eutsi bati esker garatu zen. Gaur egun, analitika garapenaren ekoizpen-prozesuaren parte da, iritzi-begiztak asko murrizten ditu eta aldian-aldian ikuspegiak ematen ditu. Zehazki esango dizut nola dagoen guztia gurekin antolatuta.
DevOps klasikoen desabantailak
Bezeroen produktu berriak sortzen direnean, negozio batek bezeroen portaeraren eredu ezin hobea sortzen du eta bihurketa on bat espero du, eta horren oinarrian bere negozio-helburuak eta emaitzak eraikitzen ditu. Garapen-taldea, bere aldetik, kode oso ona eta kalitate handikoa egiten ahalegintzen da. Laguntzak, berriz, prozesuen erabateko automatizazioa espero du, produktu berri bat mantentzeko erraztasun eta erosotasunerako.
Errealitatea bezeroek prozesu korapilatsu samarra jasotzen duten moduan garatzen da gehienetan, negozioa bihurketa baxuan oinarritzen da, garapen-taldeek konponketaz konponketa askatzen dute eta laguntza bezeroen eskaeren jario batean itotzen da. Ezaguna?
Hemen gaiztakeriaren sustraia prozesuan txertatuta dagoen kalitate-begizta luze eta eskasean dago. Enpresak eta garatzaileek, eskakizunak bildu eta esprintetan zehar iritziak jasotzen dituzten bitartean, bezero kopuru mugatu batekin komunikatzen dira, eta horrek asko eragiten du produktuaren patua. Askotan pertsona batentzat garrantzitsua dena ez da xede-publiko osoaren ezaugarria.
Produktuaren garapena norabide egokian dagoen ala ez ulertzea finantza-txostenekin eta merkatu-ikerketen emaitzekin dator merkaturatu eta hilabetera. Eta haiek, laginaren tamaina mugatua denez, ez dute hipotesiak bezero bolumen handietan probatzeko aukerarik ematen. Oro har, luzea, zehaztugabea eta eraginkorra ez da.
garaikurra tresna
Modu ona aurkitu dugu honetatik alde egiteko. Merkataritzari soilik laguntzen zien tresna, negozioen eta garatzaileen eskuetara iritsi ginen. Web analitika aktiboki erabiltzen hasi ginen prozesua denbora errealean ikusteko, hemen eta orain gertatzen ari dena ulertzeko. Horretan oinarrituta, planifikatu produktua bera, bezero kopuru handira zabalduz.
Produktuaren hobekuntzaren bat aurreikusiz gero, berehala ikusi ahal izango duzu zer neurketarekin lotuta dagoen, eta neurri horiek nola eragiten duten salmentetan, negozioarentzat garrantzitsuak diren ezaugarriak. Beraz, berehala kendu ditzakezu hipotesiak eragin txikia duten. Edo, adibidez, zabaldu funtzio berri bat estatistikoki esanguratsua den erabiltzaile kopuru bati eta kontrolatu neurketak denbora errealean, dena nahi bezala funtzionatzen ari den ulertzeko. Ez itxaron eskaera edo txostenen bidezko iritzia, baina berehala kontrolatu eta berehala zuzendu produktu bat sortzeko prozesua. Eginbide berri bat zabaldu, hiru egunetan datu estatistiko zuzenak bildu, beste hiru egunetan aldaketak egin ditzakegu, eta orain produktu berri bikaina prest dago astebete barru.
Inbutu osoa, produktu berriarekin harremanetan jarri diren bezero guztien jarraipena egin dezakezu, inbutua nabarmen murriztu den puntuak aurkitu eta arrazoiak ulertu. Garatzaileak eta negozioak hori ikusten ari dira orain, eguneroko lanaren parte da. Bezeroen bidaia bera ikusten dute, eta elkarrekin hobetzeko ideiak eta hipotesiak sor ditzakete.
Negozioaren eta garapenaren integrazio honek, analitikarekin batera, produktuak etengabe sortzea, etengabe optimizatzea, botilak bilatzea eta ikustea ahalbidetzen du, prozesu osoa.
Konplexutasunaren ingurukoa da
Produktu berri bat sortzen dugunean, ez gara hutsetik hasten, baina dagoeneko existitzen diren zerbitzuen korapilatsu batean eraikitzen dugu. Produktu berri bat probatzean, bezeroa gehienetan hainbat sailekin harremanetan jartzen da. Harremanetarako zentroko langileekin komunikatu daiteke, bulegoko arduradunekin, laguntzarekin harremanetan jar daiteke, lineako txatak erabili. Neurrien laguntzaz, ikus dezakegu, adibidez, zein den kontaktu zentroaren karga, sarrerako eskaerak nola prozesatu onena. Bulegora zenbat jende etortzen den uler dezakegu eta bezeroari nola gehiago aholku eman iradoki genezake.
Berdin gertatzen da informazio sistemekin. Gure bankuak 20 urte baino gehiago daramatza, denbora horretan sistema heterogeneoen geruza handi bat sortu da eta oraindik funtzionatzen ari da. Backend sistemen arteko elkarrekintza batzuetan ezustekoa da. Adibidez, antzinako sistema batzuetan, eremu jakin baterako karaktere kopuruan murrizketak daude, eta batzuetan zerbitzu berria huts egiten du. Metodo estandarrak erabiliz akats baten jarraipena nahiko zaila da, baina web analitika erabiltzea oinarrizkoa da.
Bezeroari erakusten zaizkion sistema guztietako errore-testuak hartzen eta aztertzen hasi ginen puntura iritsi gara. Horietako asko zaharkituta zeudela ikusi zen, eta ezin genuen imajinatu ere egin gure prozesuan nolabait parte hartu zutenik.
Analitikekin lan egitea
Web analytics eta SCRUM garapen taldeak gela berean ditugu. Etengabe elkarreragiten dute. Beharrezkoa denean, espezialistek neurriak konfiguratzen edo datuak kargatzen laguntzen dute, baina, funtsean, taldekideek beraiek lan egiten dute analitika zerbitzuarekin, ez dago ezer konplikaturik.
Laguntza beharrezkoa da, adibidez, mendekotasun batzuk behar badira, iragazki osagarriak bezero edo iturri mota mugatu baterako. Baina egungo arkitekturan, oso gutxitan aurkitzen dugu honekin.
Interesgarria da analitika sartzeak ez zuen IT sistema berri bat instalatu behar. Merkataritzaileek aurretik lan egin duten software bera erabiltzen dugu. Bere erabilera koordinatzea eta negozioan eta garapenean ezartzea baino ez zen beharrezkoa. Jakina, ezin izan dugu marketinak daukana bakarrik hartu, dena berriro konfiguratu behar izan dugu eta marketinari ingurune berri baterako sarbidea eman behar izan dugu informazio-eremu berean gurekin egon daitezen.
Etorkizunean, prozesatutako saioen bolumena gero eta handiagoari aurre egiteko gai izango den web analitika softwarearen bertsio hobetua erosteko asmoa dugu.
Era berean, aktiboki integratzen ari gara web analitika eta barne datu-baseak CRM eta kontabilitate sistemetatik. Datuak konbinatuz, bezeroaren irudi osoa lortzen dugu beharrezko atal guztietan: iturrien arabera, bezero motak, produktuak. Datuak bistaratzen laguntzen duten BI zerbitzuak laster egongo dira eskuragarri sail guztientzat.
Zerrekin bukatu dugu? Izan ere, horren inguruko analitika eta erabakiak hartzea ekoizpen-prozesuaren zati bat egin genuen, eta horrek eragin nabaria ematen zuen.
Analitika: ez zapaldu arrastela
Eta azkenik, bizdevops bat eraikitzeko prozesuan kolpeak saihesten lagunduko dizuten aholkuak partekatu nahi ditut.
- Analitika ezin bada azkar egin, orduan okerreko analitika egiten ari zara. Produktu batetik bide sinple bat jarraitu behar duzu, eta gero eskalatu.
- Etorkizuneko analisi-arkitektura ondo ulertzen duen talde edo pertsona bat izan behar duzu. Oraindik ere itsasertzean erabaki behar duzu analitika nola eskalatuko duzun, beste sistemetan integratzeko eta datuak berrerabili.
- Ez sortu datu gehigarririk. Web-estatistikak, informazio baliagarriaz gain, kalitate baxuko eta erredundanteko datuak dituen zabor-zabortegi erraldoia ere bada. Eta zabor horrek erabakiak hartzea eta ebaluazioa oztopatuko ditu helburu argirik ez badago.
- Ez egin analitika analitiken mesedetan. Lehenik eta behin, helburuak, tresna bat aukeratzea, eta orduan bakarrik - analitikak eragina izango duen lekuan bakarrik.
Materiala Olga Chebotarrekin batera prestatu zen ().
Iturria: www.habr.com