DevOps-filosofien, når udvikling kombineres med softwarevedligeholdelse, vil ikke overraske nogen. En ny trend tager fart - DevOps 2.0 eller BizDevOps. Den kombinerer tre komponenter i en enkelt helhed: forretning, udvikling og support. Og ligesom i DevOps danner ingeniørpraksis grundlaget for sammenhængen mellem udvikling og support, og i forretningsudvikling indtager analytics rollen som "limen", der forener udvikling med forretning.
Jeg vil indrømme med det samme: vi fandt først ud af nu, at vi har en reel forretningsudvikling, efter at have læst smarte bøger. Det kom sammen takket være medarbejdernes initiativ og en ukuelig passion for forbedring. Analytics er nu en del af udviklingsproduktionsprocessen, hvilket reducerer feedback-loops markant og giver regelmæssigt indsigt. Jeg vil fortælle dig i detaljer, hvordan alt fungerer for os.
Ulemper ved Classic DevOps
Når nye kundeprodukter udtænkes, skaber en virksomhed en ideel model for kundeadfærd og forventer god konvertering, på grundlag af hvilken den bygger sine forretningsmål og resultater. Udviklingsteamet på sin side stræber efter at lave meget god kode af høj kvalitet. Support håber på fuldstændig automatisering af processer, lethed og bekvemmelighed ved at vedligeholde et nyt produkt.
Virkeligheden udvikler sig oftest på en sådan måde, at kunderne modtager en ret kompleks proces, virksomheden sidder fast med lav konvertering, udviklingsteams frigiver rettelse efter rettelse, og support drukner i strømmen af forespørgsler fra kunder. Lyder det bekendt?
Roden til det onde her ligger i den lange og dårlige feedback-loop, der er indbygget i processen. Virksomheder og udviklere kommunikerer, når de indsamler krav og modtager feedback under sprints, med et begrænset antal kunder, som har stor indflydelse på produktets skæbne. Ofte er det, der er vigtigt for én person, slet ikke typisk for hele målgruppen.
Forståelse af, om et produkt bevæger sig i den rigtige retning, kommer med økonomiske rapporter og markedsundersøgelsesresultater måneder efter lanceringen. Og på grund af den begrænsede stikprøvestørrelse giver de ikke mulighed for at teste hypoteser på et stort antal klienter. Generelt viser det sig at være langt, unøjagtigt og ineffektivt.
Trofæ værktøj
Vi fandt en god måde at komme væk fra dette på. Et værktøj, der tidligere kun hjalp marketingfolk, har nu fundet vej til virksomheder og udviklere. Vi begyndte aktivt at bruge webanalyse for at se på processen i realtid, her og nu for at forstå, hvad der sker. Ud fra dette planlægge selve produktet og rulle det ud til et stort antal kunder.
Hvis du planlægger en form for produktforbedring, kan du med det samme se, hvilke målinger det er forbundet med, og hvordan disse målinger påvirker salg og egenskaber, der er vigtige for virksomheden. På denne måde kan du med det samme luge ud i hypoteser med lav effekt. Eller for eksempel udrulle en ny funktion til et statistisk signifikant antal brugere og overvåge metrics i realtid for at forstå, om alt fungerer efter hensigten. Vent ikke på feedback i form af anmodninger eller rapporter, men overvåg og juster straks selv produktoprettelsesprocessen. Vi kan udrulle en ny funktion, indsamle statistisk korrekte data på tre dage, foretage ændringer på yderligere tre dage – og om en uge er et fantastisk nyt produkt klar.
Du kan spore hele tragten, alle de kunder, der kom i kontakt med det nye produkt, opdage punkter, hvor tragten blev kraftigt indsnævret, og forstå årsagerne. Både udviklere og virksomheder overvåger nu dette som en del af deres daglige arbejde. De ser den samme kunderejse, og sammen kan de generere ideer og hypoteser til forbedring.
Denne integration af forretning og udvikling sammen med analytics gør det muligt at skabe produkter løbende, konstant optimere, søge efter og se flaskehalse og hele processen som helhed.
Det hele handler om kompleksitet
Når vi opretter et nyt produkt, starter vi ikke fra bunden, men integrerer det i et allerede eksisterende web af tjenester. Når man afprøver et nyt produkt, kontakter en kunde oftest flere afdelinger. Han kan kommunikere med kontaktcentermedarbejdere, med ledere på kontoret, han kan kontakte support eller i online chats. Ved hjælp af metrics kan vi for eksempel se, hvad belastningen er på kontaktcenteret, hvordan vi bedst behandler indkommende forespørgsler. Vi kan forstå, hvor mange mennesker der når kontoret og foreslå, hvordan vi kan rådgive kunden yderligere.
Det er præcis det samme med informationssystemer. Vores bank har eksisteret i mere end 20 år, hvor der er skabt et stort lag af heterogene systemer, som stadig fungerer. Interaktion mellem backend-systemer kan nogle gange være uforudsigelig. For eksempel er der i nogle ældgamle systemer begrænsninger på antallet af tegn for et bestemt felt, og nogle gange går det ned med den nye tjeneste. Det er ret svært at spore en fejl ved hjælp af standardmetoder, men ved at bruge webanalyse er det nemt.
Vi nåede dertil, hvor vi begyndte at indsamle og analysere fejltekster, der vises til klienten fra alle involverede systemer. Det viste sig, at mange af dem var forældede, og vi kunne slet ikke forestille os, at de på en eller anden måde var involveret i vores proces.
Arbejder med analytics
Vores webanalytikere og SCRUM-udviklingsteams er placeret i samme rum. De interagerer konstant med hinanden. Når det er nødvendigt, hjælper specialister med at opsætte metrics eller uploade data, men for det meste arbejder teammedlemmerne selv med analysetjenesten, der er ikke noget kompliceret der.
Hjælp er påkrævet, hvis du for eksempel har brug for nogle afhængigheder eller yderligere filtre til en begrænset type klienter eller kilder. Men i den nuværende arkitektur støder vi sjældent på dette.
Interessant nok krævede implementeringen af analyser ikke installation af et nyt it-system. Vi bruger den samme software, som marketingfolk tidligere har arbejdet med. Det var kun nødvendigt at blive enige om dets brug og implementere det i forretning og udvikling. Selvfølgelig kunne vi ikke bare tage det marketing havde, vi skulle omkonfigurere alt på ny og give marketing adgang til det nye miljø, så de ville være i samme informationsfelt med os.
I fremtiden planlægger vi at købe en forbedret version af webanalysesoftware, der vil give os mulighed for at klare de stigende mængder af behandlede sessioner.
Vi er også aktivt i gang med at integrere webanalyse og interne databaser fra CRM og regnskabssystemer. Ved at kombinere data får vi et komplet billede af kunden i alle de nødvendige aspekter: efter kilde, type kunde, produkt. BI-tjenester, der hjælper med at visualisere data, bliver snart tilgængelige for alle afdelinger.
Hvad endte vi med? Faktisk gjorde vi analyser og beslutningstagning på det til en del af produktionsprocessen, hvilket havde en synlig effekt.
Analytics: træde ikke på raken
Og endelig vil jeg dele nogle tips, der hjælper dig med at undgå at komme i problemer i processen med at opbygge en forretningsudviklingsvirksomhed.
- Hvis du ikke kan lave analyser hurtigt, laver du den forkerte analyse. Du skal følge en enkel vej fra ét produkt og derefter skalere op.
- Du skal have et team eller en person, der har en god forståelse for fremtidens analysearkitektur. Du skal stadig beslutte på kysten, hvordan du vil skalere analysen, integrere den i andre systemer og genbruge dataene.
- Generer ikke unødvendige data. Webstatistik er udover nyttig information også et kæmpestort losseplads med lav kvalitet og unødvendige data. Og dette affald vil forstyrre beslutningstagning og vurdering, hvis der ikke er klare mål.
- Lav ikke analyser for analysernes skyld. Først mål, valg af værktøj, og først derefter - kun analyser, hvor det vil have en effekt.
Materialet blev udarbejdet sammen med Chebotar Olga ().
Kilde: www.habr.com