DevOpsi filosoofia, kus arendus seondub tarkvarahooldusega, ei üllata enam kedagi. Tugevneb uus trend — DevOps 2.0 või BizDevOps. Selles ühinevad kolm komponenti: äri, arendus ja tugi. Nii nagu DevOpsis toetavad inseneripraktikad arenduse ja toe seoseid, nii mängib bizdevopsis analüütika rolli „liimina”, mis ühendab arenduse ärihuvidega.
Tahan kohe tunnistada: et meil on tekkinud tõeline bizdevops, saime teada alles nüüd, lugedes nutikaid raamatuid. See kujunes iseeni tänu töötajate algatusele ja väsimatule soovile parendada. Praegu on analüütika osa arenduse tootmisprotsessist, mis oluliselt lühendab tagasiside sildu ja varustab meid regulaarselt siseteadlike teadmistega. Räägin üksikasjalikult, kuidas meil kõik toimin.
Klassikalise DevOpsi puudused
Uute klienditoodete loomise korral mõtleb ettevõte välja ideaalse kliendi käitumismudeli ja loodab hea konversiooni peale, mille põhjal määratletakse oma ärieesmärgid ja tulemused. Arendajate meeskond püüab omalt poolt luua väga head kvaliteetset koodi. Toetustiim loodab täieliku automatiseerimise, lihtsuse ja mugavuse peale uue toote haldamisel.
Tõde on sageli see, et kliendid saavad üsna keerulise protsessi, ettevõtte konversioon jääb madalaks, arendusmeeskonnad väljastavad parandusi pidevalt ja toedesk annab endast kõik, et vastata klientide päringutele. 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 jooksul piiratud arvu klientidega, kes mõjutavad toote saatust. Tihti see, mis on ühele oluline, ei pruugi olla kogu sihtrühma jaoks üldse iseloomulik.
Mõistmine, kas toote areng liigub õiges suunas, tuleb finantsaruannete ja turu-uuringute tulemustega, mis arriveeruvad mitu kuud pärast lansseerimist. Ning nende tõttu, et valim on piiratud, ei anna nad võimalust hüpoteeside valideerimiseks suure kliendibaasi peal. Ühesõnaga, see on aeglane, täpsustamata ja ebaefektiivne.
Trofee tööriist
Oleme leidnud hea viisi, et sellest üle saada. Tööriist, mis varem aitas ainult turundajaid, jõudis meie kätesse äri ja arendajate jaoks. Oleme hakanud aktiivselt kasutama veebi-analüütikat, et jälgida protsessi reaalajas, et siin ja praegu mõista, mis toimub. Selle põhjal plaanida toodet ning selle turule toomist suurele kliendibaasile.
Kui toote täiustamine on plaanis, saab kohe vaadata, milliste metrikatega see on seotud ja kuidas need metrikad mõjutavad müüki ning ettevõttele olulisi omadusi. Nii saab kohe kõrvale jätta madala mõjuga hüpoteesid. Või näiteks, uuendades funktsiooni statistiliselt olulisel hulgal kasutajatega, saab reaalajas jälgida metrikaid, mõista, kas kõik töötab nagu plaanitud. Ei pea ootama tagasisidet, mis tuleb päringute või aruannete vormis, vaid saame ise jälgida ja kiiresti kohandada tootmisprotsessi. Me võime uuendada funktsiooni, koguda juba kolme päeva pärast statistiliselt usaldusväärseid andmeid, teha muudatusi veel kolme päeva jooksul — ja nädalaga on meil valmis suurepärane uus toode.
Saame jälgida kogu müügivoolu, kõiki kliente, kes on kontakteerunud uue tootega, avastada punktid, kus müügivool järsult kitsenes, ja aru saada põhjustest. Nii arendajad kui ka äri jälgivad seda nüüd igapäevaselt. Nad näevad sama klienditeed ja saavad koos genereerida ideid ja hüpoteese parandamiseks.
Äri ja arenduse ning analüüsi selline integreerimine võimaldab luua tooteid pidevalt, pidevalt optimeerida, otsida ja näha kitsaskohti, kogu protsess tervikuna.
Küsimus on keerukuses
Uut toodet luues ei alusta me puhtalt lehelt, vaid integreerime selle juba olemasolevasse teenuste keerukusse. Uue tootega tutvudes suhtleb klient kõige sagedamini mitme osakonnaga. Ta võib rääkida kontaktsentri töötajate, kontorihalduritega, pöörduda tugiteenuste poole või vestelda veebichattides. Ahniskuse abil saame näha näiteks, milline on koormus kontaktsentril, kuidas paremini käsitleda sisendpäringuid. Saame aru, kui palju inimesi jõuab kontorisse, ja anda soovitusi, kuidas klienti edasi nõustada.
Infotehnoloogiate maailmas on asjad sarnased. Meie pank on tegutsenud juba üle 20 aasta, selle aja jooksul on loodud ja siiani toimib suur hulk eriotstarbelisi süsteeme. Suhtlemine tagasisüsteemidega võib olla kohati ettearvamatu. Näiteks mõnes vanas süsteemis on mingi välja osas sümbolite arvu piirang ja see võib uue teenuse kokku kukutada. Vea jälgimine tavaliste meetoditega on üsna keeruline, kuid veebianalüütika abil on see elementaarne.
Olemegi jõudnud selleni, et hakkasime kõigist osalevatest süsteemidest koguma ja analüüsima neid vigade tekstide, mis kliendile kuvatakse. Selgus, et paljud olid ajale jalgu jäänud ja me ei osanud isegi ette kujutada, et need osalevad meie protsessis.
Töö analüütikaga
Meie veebiandmete analüütikud ja SCRUM-arendusmeeskonnad töötavad samas ruumis. Nad suhtlevad pidevalt. Kui on vajalik, aitavad spetsialistid seada mõõdikuid või eksportida andmeid, peamiselt töötavad meeskonna liikmed ise analüütika teenusega, seal pole midagi keerulist.
Abi on vajalik, kui näiteks on vajalikud teatud sõltuvused, täiendavad filtrid piiratud tüüpi klientide või allikate jaoks. Kuid praeguses arhitektuuris satume sellise olukorraga harva kokku.
Huvitav on see, et analüüsi rakendamine ei nõudnud uue IT-süsteemi installimist. Kasutame sama tarkvara, millega varem töötasid turundajad. Tulemus oli vaid selle kasutamise kooskõlastamine ja selle integreerimine äri ja arenduse protsessidesse. Loomulikult ei saanud me lihtsalt võtta seda, mis turundusel on, vaid pidime kõik uuesti seadistama ja lubama turundusele juurdepääsu uude keskkonda, et nad saaksid olla meiega ühes infosüsteemis.
Tulevikus plaanime osta täiustatud versiooni veebianalüüsi tarkvarast, mis aitab hallata suurenevaid töödeldavate seansside mahtusid.
Samuti on meil aktiivne protsess veebianalüüsi ja sisemiste andmebaaside integreerimiseks CRM-i ja raamatupidamissüsteemidest. Andmeid ühendades saame täieliku ülevaate kliendist kõigis vajalikes lõigetes: allikate, klientide tüüpide, toodete kaupa. BI-teenused, mis aitavad andmeid visualiseerida, saavad peagi kätte kõigile osakondadele.
Mis meil lõpuks välja tuli? Tegelikult tegime analüüsist ja selle põhjal otsuste langetamisest osa tootmisprotsessist, mis andis märgatava efekti.
Analüütika: ärge astuge samadesse augudesse
Lõpetuseks soovin jagada nõuandeid, mis aitavad teil vältida komistamisi bizdevopsi ülesehitamisel.
- Kui analüütikat ei õnnestu kiiresti teha, siis tähendab, et teete vale analüüsi. Tuleb minna lihtsat teed ühe tootega ja siis laiendada.
- Teil peab kindlasti olema meeskond või inimene, kes mõistab hästi tulevast analüütika arhitektuuri. Tuleb juba varakult otsustada, kuidas analüütikat laiendada, integreerida see teiste süsteemidega, andmeid taaskasutada.
- Ärge genereerige liigselt andmeid. Veebi statistika on kasuliku teabe kõrval ka suur prügi, mis sisaldab halva kvaliteediga ja tarbetuid andmeid. See prügi segab otsuste tegemist ja hindamist, kui pole selgeid eesmärke.
- Ärge tehke analüütikat ainult analüütika nimel. Esmalt eesmärgid, seejärel tööriista valik, ja alles siis - analüütika seal, kus see toob kasu.
Materjal on koostatud koos Olga Čebotariga ().
Allikas: habr.com
