La filozofio de DevOps, kiam disvolviĝo estas kombinita kun programaro prizorgado, neniu surprizas. Nova tendenco akiras impeton - DevOps 2.0 aŭ BizDevOps. Ĝi jam kunfandas tri komponentojn en ununuran tuton: komerco, evoluo kaj subteno. Kaj same kiel en DevOps, inĝenieraj praktikoj formas la bazon de la ligo inter evoluo kaj subteno, do en komercaj devopoj, analizo prenas la rolon de la "gluo" kiu kunigas evoluon kun komerco.
Mi volas tuj konfesi: ke ni ricevis veran bizdevops, ni lernis nur nun, leginte inteligentajn librojn. Ĝi iel disvolviĝis danke al la iniciato de dungitoj kaj neretenebla pasio por plibonigo. Hodiaŭ, analizo estas parto de la produktadprocezo de evoluo, multe reduktante respondajn buklojn kaj regule disponigante komprenojn. Mi detale rakontos al vi, kiel ĉio estas aranĝita ĉe ni.
Malavantaĝoj de klasika DevOps
Kiam novaj klientproduktoj estas koncipitaj, komerco kreas idealan modelon de klienta konduto kaj atendas bonan konvertiĝon, surbaze de kiu ĝi konstruas siajn komercajn celojn kaj rezultojn. La disvolva teamo, siaflanke, strebas fari tre bonan, altkvalitan kodon. Subteno, aliflanke, esperas plenan aŭtomatigon de procezoj, por la facileco kaj oportuno de konservado de nova produkto.
La realo plej ofte evoluas tiel, ke klientoj ricevas sufiĉe komplikan procezon, komerco ripozas sur malalta konvertiĝo, evoluteamoj liberigas riparon post riparo, kaj subteno dronas en fluo de petoj de klientoj. Konata?
La radiko de la malbono ĉi tie kuŝas en la longa kaj malbonkvalita retrosciiga buklo enigita en la procezo. Komercoj kaj programistoj, kolektante postulojn kaj ricevante sugestojn dum sprintoj, komunikas kun limigita nombro da klientoj, kiuj multe influas la sorton de la produkto. Ofte tio, kio gravas por unu persono, tute ne estas karakteriza por la tuta celgrupo.
Kompreni ĉu la disvolviĝo de la produkto estas en la ĝusta direkto venas kun financaj raportoj kaj merkataj esplorrezultoj monatojn post la lanĉo. Kaj ili, pro la limigita specimena grandeco, ne donas ŝancon testi hipotezojn pri granda kvanto de klientoj. Ĝenerale, ĝi rezultas longa, malpreciza kaj malefika.
trofeo ilo
Ni trovis bonan manieron foriri de ĉi tio. Ilo, kiu kutimis helpi nur merkatistojn, ni venis en la manojn de komerco kaj programistoj. Ni komencis aktive uzi retajn analizojn por rigardi la procezon en reala tempo, por kompreni kio okazas ĉi tie kaj nun. Surbaze de ĉi tio, planu la produkton mem, ĝia disvastigo al granda nombro da klientoj.
Se ia produkta plibonigo estas planita, vi povas tuj vidi al kiuj metrikoj ĝi estas asociita, kaj kiel ĉi tiuj metrikoj influas vendojn, trajtojn kiuj estas gravaj por komerco. Do vi povas tuj forigi hipotezojn kun malalta efiko. Aŭ, ekzemple, lanĉu novan funkcion al statistike signifa nombro da uzantoj kaj monitoru la metrikojn en reala tempo, por kompreni ĉu ĉio funkcias kiel celite. Ne atendu reagojn en formo de petoj aŭ raportoj, sed tuj monitoru kaj tuj korektu la procezon de kreado de produkto. Ni povas lanĉi novan funkcion, kolekti statistike ĝustajn datumojn en tri tagoj, fari ŝanĝojn en tri tagoj pli - kaj nun bonega nova produkto estas preta en semajno.
Vi povas spuri la tutan funelon, ĉiujn klientojn, kiuj kontaktis la novan produkton, trovi la punktojn, kie la funelo akre mallarĝiĝis, kaj kompreni la kialojn. Kaj programistoj kaj komerco nun rigardas ĉi tion, ĝi estas parto de la ĉiutaga laboro. Ili vidas la saman klientan vojaĝon, kaj kune ili povas generi ideojn kaj hipotezojn por plibonigo.
Ĉi tiu integriĝo de komerco kaj disvolviĝo, kune kun analizo, ebligas krei produktojn senĉese, konstante optimumigi, serĉi kaj vidi botelojn, la tutan procezon.
Ĉio temas pri komplekseco
Kiam ni kreas novan produkton, ni ne komencas de nulo, sed ni konstruas ĝin en jam ekzistantajn komplikaĵojn de servoj. Provante novan produkton, la kliento plej ofte kontaktas plurajn fakojn. Li povas komuniki kun dungitoj de la kontaktcentro, kun administrantoj en la oficejo, li povas kontakti subtenon, uzi interretajn babilojn. Helpe de metrikoj, ni povas vidi, ekzemple, kia estas la ŝarĝo sur la kontaktcentro, kiel plej bone prilabori envenantajn petojn. Ni povas kompreni kiom da homoj venas al la oficejo kaj sugesti kiel plu konsili la klienton.
Estas same kun informsistemoj. Nia banko ekzistas dum pli ol 20 jaroj, dum ĉi tiu tempo granda tavolo de heterogenaj sistemoj estis kreita kaj daŭre funkcias. La interago inter backend sistemoj foje estas neantaŭvidebla. Ekzemple, en iu antikva sistemo, estas limigoj pri la nombro da signoj por certa kampo, kaj foje ĉi tio frakasas la novan servon. Spuri cimon per normaj metodoj estas sufiĉe malfacila, sed uzi retan analizon estas elementa.
Ni atingis la punkton, kie ni komencis preni kaj analizi erarajn tekstojn de ĉiuj implikitaj sistemoj, kiuj estas montritaj al la kliento. Montriĝis, ke multaj el ili estis malmodernaj, kaj ni eĉ ne povis imagi, ke ili iel partoprenas en nia procezo.
Laborante kun analitiko
Ni havas retajn analitikajn kaj SCRUM-disvolvajn teamojn en la sama ĉambro. Ili konstante interagas unu kun la alia. Kiam necesas, specialistoj helpas agordi metrikojn aŭ alŝuti datumojn, sed esence la teamanoj mem laboras kun la analitika servo, estas nenio komplika.
Helpo estas bezonata se, ekzemple, necesas iuj dependecoj, pliaj filtriloj por limigita speco de kliento aŭ fonto. Sed en la nuna arkitekturo, ni malofte renkontas ĉi tion.
Interese, la enkonduko de analizo ne postulis la instaladon de nova IT-sistemo. Ni uzas la saman programaron, kun kiu komercistoj antaŭe laboris. Necesis nur kunordigi ĝian uzadon kaj efektivigi ĝin en komerco kaj evoluo. Kompreneble, ni ne povis nur preni tion, kion merkatado havas, ni devis reagordi ĉion denove kaj doni merkatan aliron al nova medio por ke ili estu kun ni en la sama informa kampo.
En la estonteco, ni planas aĉeti plibonigitan version de la ret-analitika programaro, kiu povos elteni la kreskantan volumon de prilaboritaj sesioj.
Ni ankaŭ aktive integras retajn analizojn kaj internajn datumbazojn de CRM kaj kontadaj sistemoj. Kombinante la datumojn, ni ricevas kompletan bildon de la kliento en ĉiuj necesaj sekcioj: laŭ fontoj, specoj de klientoj, produktoj. BI-servoj kiuj helpas bildigi datumojn baldaŭ estos haveblaj al ĉiuj fakoj.
Kion ni finis? Fakte, ni faris analizon kaj decidadon pri ĝi parto de la produktada procezo, kiu donis videblan efikon.
Analytics: ne tretu sur la rastilon
Kaj finfine, mi volas dividi konsiletojn, kiuj helpos vin eviti ŝvelaĵojn en la procezo de konstruado de bizdevops.
- Se la analizo ne povas esti farita rapide, tiam vi faras la malĝustan analizon. Vi devas sekvi simplan vojon de unu produkto, kaj poste grimpi.
- Vi devas havi teamon aŭ personon, kiu bone komprenas la estontan analizan arkitekturon. Vi ankoraŭ devas decidi sur la bordo, kiel vi skalos analizojn, integros ĝin en aliajn sistemojn kaj reuzos datumojn.
- Ne generu kromajn datumojn. Reta statistiko estas, krom utilaj informoj, ankaŭ grandega rubujo kun malaltkvalitaj kaj redundaj datumoj. Kaj ĉi tiu rubo malhelpos decidon kaj taksadon, se ne estas klaraj celoj.
- Ne faru analizojn pro analizo. Unue, celoj, la elekto de ilo, kaj nur tiam - analizo nur kie ĝi donos efikon.
La materialo estis preparita kune kun Olga Chebotar ().
fonto: www.habr.com