DevOpsi filosoofia, kus arendus ühendatakse tarkvara hooldusega, ei üllata enam kedagi. Jõuab järjest enam tähelepanu tõsisem trend - DevOps 2.0 või BizDevOps. Sellega sulanduvad kolmesse komponenti: äri, arendus ja tugi. Nii nagu DevOpsis põhinevad inseneripraktikad arenduse ja toe vahelise ühenduse loomisel, täidab BizDevOpsis analüütika „liimi” rolli, ühendades arenduse äri.
Tahan kohe tunnistada: et meil on tekkinud ehtne bizdevops, saime teada alles nüüd, kui lugesime targaid raamatuid. See kujunes kuidagi ise üles töötajate algatuse ja piiritu soovi kaudu parandamiste osas. Praegu on analüütika osa arenduse tootmisprotsessist, mis vähendab oluliselt tagasiside ahelat ning varustab meid regulaarselt teadmistega. Räägin üksikasjalikult, kuidas meil kõik on korraldatud.
Klassikalise DevOpsi puudused
Uute klienditoodete loomisel loob äri ideaalse kliendi käitumise mudeli ja loodab hea konversiooni peale, mille põhjal seab oma äri eesmärgid ja tulemused. Arendustiim omalt poolt püüab kirjutada väga head, kvaliteetset koodi. Tugi loodab aga täieliku protsesside automatiseerimise, uue toote käitamise lihtsuse ja mugavuse peale.
Tegelikkus kujuneb sageli selliseks, et kliendid saavad üsna keeruka protsessi, äri jääb madala konversiooni taha, arendusteamid väljastavad fikse peale fiksi ja tugi uputab end klientide päringute voolus. Kas see tundub tuttav?
Probleemi juured peituvad pikas ja kehvas tagasiside ahelas, mis on protsessi sisse ehitatud. Äri ja arendajad suhtlevad nõuete kogumise ja tagasiside saamise ajal sprintide vältel piiratud arvu klientidega, kellel on suur mõju toote saatusale. Tihti see, mis on ühe jaoks oluline, ei ole sugugi iseloomulik kogu sihtgrupile.
Arusaam sellest, kas toote areng on õiges suunas, tuleb koos finantsaruannete ja turu-uuringute tulemustega kuude pärast käivitamist. Isegi need ei anna valimi piiratud tõttu võimalust hüpoteeside testimiseks suure hulga klientide seas. Üldiselt on tulemuseks kaua, ebatäpselt ja ebaefektiivne.
Trofee tööriist
Me leidsime hea viisi sellest välja pääseda. Tööriist, mis varem aitas ainult turundajaid, on nüüd jõudnud ettevõtete ja arendajate kätesse. Oleme hakanud aktiivselt kasutama veebianalüüsi, et jälgida protsessi reaalajas, saades kohe aru, mis toimub. Selle põhjal saame planeerida toodet ja selle turule toomist suurele kliendihulgale.
Kui plaanitakse toodet parandada, saab kohe vaadata, milliste mõõdikutega see seotud on ja kuidas need mõõdikud mõjutavad müüki, ärile olulisi omadusi. Nii saab koheselt kõrvaldada madala efektiivsusega hüpoteesid. Või näiteks, saame uue funktsiooni välja tuua statistiliselt olulise hulga kasutajate seas ja jälgida reaalajas mõõdikuid, et mõista, kas kõik töötab nii, nagu planeeritud. Ei pea ootama tagasisidet kaebuste või aruannete näol, vaid saame ise jälgida ja kiiresti kohandada toote loomise protsessi. Saame uue funktsiooni välja tuua ja kolme päeva pärast koguda statistiliselt usaldusväärseid andmeid, teha veel kolme päeva jooksul muudatusi — ja nädala aja pärast on meil valmis suurepärane uus toode.
Saame jälgida kogu müügivoolu, kõiki kliente, kes on sisenenud uue tootega kontakti, avastada kohad, kus jõudlus järsult vähenes, ja aru saada põhjustest. Nii arendajad kui ka äri jälgivad seda nüüd igapäevaselt. Nad näevad sama kliendi teekonda ja saavad koos genereerida ideid ja hüpoteese parandamiseks.
Selline äri ja arenduse integreerimine koos analüüsiga võimaldab pidevalt tooteid luua, pidevalt optimeerida, tuvastada ja märgata kitsaskohti, kogu protsessi üldiselt.
Asi on keerukuses
Kui loome uut toodet, siis ei alusta me puhtalt lehelt, vaid integreerime selle juba olemasolevasse teenuste võrku. Klient puutub uue tootega tutvudes tihti kokku mitme osakonnaga. Ta võib suhelda kontaktkeskuse töötajatega, kontorihalduritega, pöörduda toe poole või kasutada veebichate. Aitame mõõdikute abil näiteks näha, kui suur on koormus kontaktkeskuses, ja kuidas paremini töödelda sissetulevaid päringuid. Mõistame, kui palju inimesi jõuab kontorisse, ja saame anda nõu, kuidas kliente edasi juhendada.
Informatsioonisüsteemidega on kõik täpselt samamoodi. Meie pank on tegutsenud juba üle 20 aasta, selle aja jooksul on loodud ja tõhusalt toimib suur kogum erinevaid süsteeme. Suhtlemine tagasisüsteemide vahel on mõnikord ettearvamatu. Näiteks, mingis vanas süsteemis on teatud välja suhtes sümbolite arvu piirangud, ja see mõnikord kisub uue teenuse kokku. Veaparandamine tavapäraste meetoditega on üsna keeruline, kuid veebianalüüsi abil väga lihtne.
Oleme jõudnud selleni, et oleme hakanud kõigist osalevatest süsteemidest koguma ja analüüsima veateateid, mis kliendile kuvatakse. Selgus, et paljud neist on vananenud ja me ei osanud isegi ette kujutada, et need mingil moel meie protsessis osalevad.
Töö analüütikaga
Meie veebianalüütikud ja arendajate SCRUM-meeskonnad on samas ruumis. Nad suhtlevad pidevalt omavahel. Kui on vaja, aitavad spetsialistid seadistada mõõdikuid või andmeid eksportida, kuid enamikul juhtudel töötavad tiimiliikmed ise analüütika teenusega, seal pole midagi keerulist.
Aitamine on vajalik, kui näiteks on vaja mingeid sõltuvusi, täiendavaid filtreid piiratud tüüpi klientide või allikate suhtes. Kuid praeguses arhitektuuris me harva sellega kokku puutume.
Huvitav on see, et analüütika rakendamine ei nõudnud uue IT-süsteemi paigaldamist. Kasutame sama tarkvara, millega varasemalt töötasid turundajad. Peamine, et oli tarvis selle kasutamine kooskõlastada ning integreerida see äri ja arendusse. Loomulikult ei saanud me lihtsalt võtta seda, mis turundusel oli, pidime kõik uuesti seadistama ja andma turundusele juurdepääsu uuele keskkonnale, et nad oleksid meiega samas informatsiooniväljas.
Tulevikus kavandame osta täiustatud versiooni veebianalüüsi tarkvarast, mis võimaldab toime tulla kasvava töötlemise sessionite mahuga.
Samuti on meil aktiivne protsess veebianalüütika ja sisemiste andmebaaside integreerimiseks CRM-i ja raamatupidamissüsteemidesse. Andmete ühinemisega saame täieliku ülevaate kliendist igas vajalikes mõõtmetes: allikate, klientide tüüpide ja toodete järgi. BI-teenused, mis aitavad andmeid visuaalselt esitada, saavad peagi kätte kõikidesse osakondadesse.
Kuidas meil läks? Tegelikult oleme teinud analüütika ja otsuste tegemise selle põhjal osaks tootmisprotsessist, mis on andnud märgatava mõju.
Analüütika: ärge astuge samasse ämbrisse
Ja lõpetuseks tahan jagada näpunäiteid, mis aitavad teil vältida valusate õpikute kogumist äridisainimise protsessis.
- Kui te ei saa analüütikat kiiresti teha, siis tähendab see, et teete vale analüüsi. Tuleb liikuda lihtsa toote suunas ja seejärel laieneda.
- Teie meeskonnas peab kindlasti olema keegi, kes mõistab tulevast analüütika arhitektuuri. Peate veel enne kindlaks tegema, kuidas te analüütikat laiendate, integreerite selle teiste süsteemidega ja taaskasutate andmeid.
- Ärge genereerige liigseid andmeid. Veebistatistika on lisaks kasulikule teabele ka tohutu prügi siiski ebakvaliteetsete ja liigsete andmete tõttu. See prügi takistab oluliste otsuste tegemist ja hindamist, kui puuduvad selged eesmärgid.
- Ärge tehke analüütikat lihtsalt analüütika nimel. Esiteks eesmärgid, seejärel tööriista valik ja alles seejärel – analüütika ainult seal, kus see toob tulemusi.
Materjal on koostatud koos Olga Čebotariga ().
Allikas: habr.com
