DevOps-filosofien, når utvikling kombineres med programvarevedlikehold, vil ikke overraske noen. En ny trend skyter fart – DevOps 2.0 eller BizDevOps. Den kombinerer tre komponenter til én helhet: virksomhet, utvikling og støtte. Og akkurat som i DevOps, danner ingeniørpraksis grunnlaget for sammenhengen mellom utvikling og støtte, og i forretningsutvikling inntar analytics rollen som «limet» som forener utvikling med virksomhet.
Jeg vil innrømme med en gang: vi fant først ut nå at vi har en skikkelig forretningsutvikling, etter å ha lest smarte bøker. Det kom sammen takket være de ansattes initiativ og en ukuelig lidenskap for forbedring. Analytics er nå en del av utviklingsproduksjonsprosessen, noe som reduserer tilbakemeldingssløyfer betydelig og gir regelmessig innsikt. Jeg skal fortelle deg i detalj hvordan alt fungerer for oss.
Ulemper med klassiske DevOps
Når nye kundeprodukter unnfanges, skaper en bedrift en ideell modell for kundeadferd og forventer god konvertering, på grunnlag av denne bygger den sine forretningsmål og resultater. Utviklingsteamet på sin side streber etter å lage svært god kode av høy kvalitet. Support håper på fullstendig automatisering av prosesser, enkelhet og bekvemmelighet ved å vedlikeholde et nytt produkt.
Virkeligheten utvikler seg oftest på en slik måte at klienter får en ganske kompleks prosess, virksomheten sitter fast med lav konvertering, utviklingsteam slipper rettelse etter retting, og support drukner i strømmen av forespørsler fra klienter. Høres kjent ut?
Roten til det onde her ligger i den lange og dårlige tilbakemeldingssløyfen som er innebygd i prosessen. Bedrifter og utviklere, når de samler inn krav og mottar tilbakemeldinger under sprints, kommuniserer med et begrenset antall kunder som i stor grad påvirker skjebnen til produktet. Ofte er det som er viktig for én person slett ikke typisk for hele målgruppen.
Å forstå om et produkt beveger seg i riktig retning kommer med økonomiske rapporter og markedsundersøkelsesresultater måneder etter lansering. Og på grunn av den begrensede utvalgsstørrelsen gir de ikke mulighet til å teste hypoteser på et stort antall klienter. Generelt viser det seg å være langt, unøyaktig og ineffektivt.
Troféverktøy
Vi fant en god måte å komme vekk fra dette på. Et verktøy som tidligere bare hjalp markedsførere, har nå funnet veien til bedrifter og utviklere. Vi begynte aktivt å bruke nettanalyse for å se på prosessen i sanntid, her og nå for å forstå hva som skjer. Basert på dette, planlegg selve produktet og rulle det ut til et stort antall kunder.
Hvis du planlegger en form for produktforbedring, kan du umiddelbart se hvilke beregninger det er knyttet til, og hvordan disse beregningene påvirker salg og egenskaper som er viktige for virksomheten. På denne måten kan du umiddelbart luke ut hypoteser med lav effekt. Eller for eksempel rulle ut en ny funksjon til et statistisk signifikant antall brukere og overvåke beregningene i sanntid for å forstå om alt fungerer etter hensikten. Ikke vent på tilbakemelding i form av forespørsler eller rapporter, men overvåk og juster umiddelbart selv produktopprettingsprosessen. Vi kan rulle ut en ny funksjon, samle inn statistisk korrekte data på tre dager, gjøre endringer på ytterligere tre dager – og om en uke er et flott nytt produkt klart.
Du kan spore hele trakten, alle kundene som kom i kontakt med det nye produktet, oppdage punkter der trakten ble kraftig innsnevret, og forstå årsakene. Både utviklere og bedrifter overvåker nå dette som en del av deres daglige arbeid. De ser den samme kundereisen, og sammen kan de generere ideer og hypoteser for forbedring.
Denne integrasjonen av virksomhet og utvikling sammen med analytics gjør det mulig å skape produkter kontinuerlig, hele tiden optimalisere, søke etter og se flaskehalser, og hele prosessen som helhet.
Alt handler om kompleksitet
Når vi lager et nytt produkt, starter vi ikke fra bunnen av, men integrerer det i en allerede eksisterende nett av tjenester. Ved utprøving av et nytt produkt kontakter en klient oftest flere avdelinger. Han kan kommunisere med kontaktsenteransatte, med ledere på kontoret, han kan kontakte support eller i nettprat. Ved hjelp av beregninger kan vi for eksempel se hva belastningen er på kontaktsenteret, hvordan vi best behandler innkommende forespørsler. Vi kan forstå hvor mange personer som når kontoret og foreslå hvordan vi kan gi klienten ytterligere råd.
Det er akkurat det samme med informasjonssystemer. Banken vår har eksistert i mer enn 20 år, i løpet av denne tiden har et stort lag av heterogene systemer blitt opprettet og fungerer fortsatt. Interaksjon mellom backend-systemer kan noen ganger være uforutsigbar. For eksempel, i noen eldgamle systemer er det begrensninger på antall tegn for et bestemt felt, og noen ganger krasjer dette den nye tjenesten. Det er ganske vanskelig å spore en feil ved å bruke standardmetoder, men å bruke nettanalyse er enkelt.
Vi kom til et punkt hvor vi begynte å samle inn og analysere feiltekster som vises til klienten fra alle involverte systemer. Det viste seg at mange av dem var utdaterte, og vi kunne ikke engang forestille oss at de på en eller annen måte var involvert i prosessen vår.
Jobber med analyser
Våre webanalytikere og SCRUM-utviklingsteam er lokalisert i samme rom. De samhandler konstant med hverandre. Når det er nødvendig hjelper spesialister med å sette opp beregninger eller laste ned data, men stort sett jobber teammedlemmene selv med analysetjenesten, det er ikke noe komplisert der.
Hjelp er nødvendig hvis du for eksempel trenger noen avhengigheter eller tilleggsfiltre for en begrenset type klienter eller kilder. Men i dagens arkitektur møter vi sjelden dette.
Interessant nok krevde ikke implementeringen av analyse installasjon av et nytt IT-system. Vi bruker den samme programvaren som markedsførere tidligere har jobbet med. Det var bare nødvendig å bli enige om bruken og implementere den i virksomhet og utvikling. Selvfølgelig kunne vi ikke bare ta det markedsføringen hadde, vi måtte konfigurere alt på nytt og gi markedsføringstilgang til det nye miljøet slik at de ville være i samme informasjonsfelt som oss.
I fremtiden planlegger vi å kjøpe en forbedret versjon av nettanalyseprogramvare som vil tillate oss å takle de økende volumene av behandlede økter.
Vi er også aktivt i gang med å integrere webanalyse og interne databaser fra CRM og regnskapssystemer. Ved å kombinere data får vi et fullstendig bilde av kunden i alle nødvendige aspekter: etter kilde, type kunde, produkt. BI-tjenester som hjelper å visualisere data vil snart bli tilgjengelig for alle avdelinger.
Hva endte vi opp med? Faktisk gjorde vi analyser og beslutninger på det til en del av produksjonsprosessen, noe som hadde en synlig effekt.
Analytics: ikke tråkk på raken
Og til slutt vil jeg dele noen tips som vil hjelpe deg å unngå å havne i trøbbel i prosessen med å bygge en forretningsutviklingsvirksomhet.
- Hvis du ikke kan gjøre analyser raskt, gjør du feil analyse. Du må følge en enkel vei fra ett produkt og deretter skalere opp.
- Du må ha et team eller en person som har god forståelse for fremtidens analysearkitektur. Du må fortsatt bestemme på kysten hvordan du skal skalere analysene, integrere dem i andre systemer og gjenbruke dataene.
- Ikke generer unødvendige data. Nettstatistikk er, i tillegg til nyttig informasjon, også en enorm søppelplass med lav kvalitet og unødvendige data. Og dette søppelet vil forstyrre beslutninger og vurdering hvis det ikke er klare mål.
- Ikke gjør analyser for analysenes skyld. Først mål, valg av verktøy, og først da - analyser bare der det vil ha effekt.
Materialet ble utarbeidet sammen med Chebotar Olga ().
Kilde: www.habr.com