DevOps-filosofien, hvor udvikling forbindes med softwarevedligeholdelse, er ikke længere overraskende for nogen. En ny trend vinder frem — DevOps 2.0 eller BizDevOps. Her samles tre komponenter i én enhed: forretning, udvikling og support. Ligesom ingeniørpraksis i DevOps danner grundlaget for forbindelsen mellem udvikling og support, tager analysen i BizDevOps rollen som 'limen', der forbinder udviklingen med forretningen.
Jeg vil gerne indrømme med det samme: Vi opdagede først nu, at vi faktisk har fået etableret ægte bizdevops, da vi læste kloge bøger. Det er på en eller anden måde opstået takket være medarbejdernes initiativ og en uophørlig trang til forbedringer. I dag er analysen en del af udviklingsprocessen, som markant reducerer feedback-loopene og regelmæssigt forsynes med indsigt. Jeg vil fortælle detaljeret, hvordan vi har organiseret det hele.
Ulemper ved klassisk DevOps
Når nye kundebaserede produkter udvikles, skaber virksomheden en ideel model for kundeadfærd og satser på en god konvertering, baseret på hvilken den bygger sine forretningsmål og resultater. Udviklingsteamet stræber derimod efter at skrive yderst velskrevet og kvalitetskontekstkode. Supportteamet håber på fuld automatisering af processerne med lethed og bekvemmelighed i vedligeholdelsen af det nye produkt.
Virkeligheden er oftest sådan, at kunderne modtager en ret kompleks proces, forretningen støder på lav konvertering, udviklingsteamene sender fix efter fix ud, og supporten drukner i en strøm af kundehenvendelser. Kender du det?
Roden til ondskaen ligger her i den lange og dårligt udførte feedback-loop, som er indbygget i processen. Virksomheden og udviklerne kommunikerer med et begrænset antal kunder, når de indsamler krav og modtager feedback under sprintene, hvilket har stor indflydelse på produktets skæbne. Ofte er det, der er vigtigt for én, slet ikke typisk for hele målgruppen.
Forståelsen af, om produktudviklingen bevæger sig i den rigtige retning, kommer ofte først med økonomiske rapporter og resultater fra markedsundersøgelser flere måneder efter lanceringen. Og på grund af stikprøvens begrænsning giver de ikke mulighed for at teste hypoteser på et stort antal kunder. Så det bliver langvarigt, unøjagtigt og ineffektivt.
Trofæværktøj
Vi har fundet en god måde at komme uden om dette. Værktøjet, som tidligere kun hjalp marketingfolk, er nu kommet i hænderne på virksomheder og udviklere. Vi begyndte aktivt at bruge webanalyse til at se processen i realtid og straks forstå, hvad der sker. Baseret på dette planlægger vi produktet og dets lancering til en stor kundebase.
Hvis der planlægges en forbedring af produktet, kan man straks se, hvilke metrikker det er relateret til, og hvordan disse metrikker påvirker salget og vigtige forretningskarakteristika. På den måde kan man straks udelukke hypoteser med lav effekt. Eller for eksempel lancerer man en ny funktion til et statistisk signifikant antal brugere og ser i realtid på metrikkerne og forstår, om alt fungerer som tilsigtet. Man venter ikke på feedback i form af henvendelser eller rapporter, men observerer selv og justerer hurtigt produktudviklingsprocessen. Vi kan lancere en ny funktion, indsamle statistisk valide data efter tre dage, lave ændringer på tre dage mere — og således kan vi have et fremragende nyt produkt klar på en uge.
Man kan følge hele trakten, alle kunder, der har været i kontakt med det nye produkt, opdage punkter, hvor trakten pludselig indsnævres, og forstå årsagerne. Både udviklere og forretning holder nu øje med dette, det er en del af det daglige arbejde. De ser den samme kunderejse, og sammen kan de generere ideer og hypoteser til forbedringer.
En sådan integration af forretning og udvikling sammen med analyse muliggør en kontinuerlig produktudvikling, konstant optimering samt identifikation og synliggørelse af flaskehalse i hele processen.
Det handler om kompleksitet
Når vi skaber et nyt produkt, starter vi ikke fra en blank side, men integrerer det i et allerede eksisterende netværk af tjenester. Når kunden prøver det nye produkt, er han oftest i kontakt med flere afdelinger. Han kan tale med ansatte fra kontaktcentret, med managere på kontoret, kan henvende sig til supporten eller online-chatter. Ved hjælp af metrikker kan vi se, for eksempel hvilken belastning kontaktcentret har, og hvordan man bedst behandler indkommende forespørgsler. Vi kan forstå, hvor mange der når frem til kontoret og Give råd om, hvordan man bedst rådgiver kunden.
Med informationssystemer er det nøjagtig det samme. Vores bank har eksisteret i mere end 20 år, og i denne tid er der blevet oprettet og fungerer stadig et stort antal forskellige systemer. Interaktionen mellem backend-systemerne kan nogle gange være uforudsigelig. For eksempel kan der i et gammelt system være begrænsninger på antallet af tegn i et bestemt felt, hvilket nogle gange nedbryder den nye tjeneste. At spore fejl med standardmetoder er ret vanskeligt, mens det er elementært med webanalyse.
Vi er nået dertil, at vi nu indsamler og analyserer fejlmeddelelserne fra alle de involverede systemer, som vises for kunden. Det viste sig, at mange af dem var forældede, og vi kunne ikke engang forestille os, at de på nogen måde deltager i vores proces.
Arbejdet med analyse
Vi har webanalytikere og SCRUM-udviklingsteams placeret i det samme lokale. De interagerer konstant med hinanden. Når det er nødvendigt, hjælper specialisterne med at konfigurere metrics eller eksportere data; oftest arbejder teammedlemmerne selv med analyseværktøjet, da der ikke er noget kompliceret ved det.
Hjælp er nødvendig, hvis der for eksempel er behov for afhængigheder, ekstra filtre baseret på en begrænset type kunder eller kilder. Men i den nuværende arkitektur støder vi sjældent på dette.
Interessen er, at implementeringen af analysen ikke krævede installation af et nyt IT-system. Vi bruger det samme software, som marketingafdelingen tidligere har arbejdet med. Det var kun nødvendigt at godkende brugen og integrere det i forretningen og udviklingen. Selvfølgelig kunne vi ikke bare tage det, som marketing havde; vi måtte omkonfigurere alt fra bunden af og derefter give marketing access til det nye miljø, så de kunne være i samme informationsfelt som os.
I fremtiden planlægger vi at købe en forbedret version af software til webanalyse, som vil være i stand til at håndtere de voksende mængder af behandlede sessioner.
Derudover arbejder vi aktivt på at integrere webanalyse med interne databaser fra CRM- og regnskabssystemer. Ved at kombinere data får vi et fuldstændigt billede af kunden i alle nødvendige dimensioner: efter kilder, kundetyper og produkter. BI-tjenester, der hjælper med at visualisere data, vil snart være tilgængelige for alle afdelinger.
Hvad fik vi i sidste ende? Faktisk har vi gjort analyse og beslutningstagning til en del af produktionsprocessen, hvilket har givet synlige resultater.
Analyse: Undgå at træde i de samme fælder
Og til sidst vil jeg dele nogle råd, der kan hjælpe dig med at undgå at støde på problemer, mens du opbygger BizDevOps.
- Hvis analysekraften ikke kan laves hurtigt, så laver du ikke den rigtige analyse. Det er vigtigt at starte simpelt med ét produkt og derefter skalere.
- Du har nøje brug for et team eller en person, der virkelig forstår den fremtidige analytiske arkitektur. Du skal også afklare, hvordan du vil skalere analytics, integrere det i andre systemer og genbruge data.
- Generér ikke overflødige data. Webstatistik indeholder, udover nyttig information, også en enorm mængde affald med dårlige og unødvendige data. Og denne rod vil påvirke beslutningstagning og evaluering, hvis der ikke er klare mål.
- Lad være med at lave analyse bare for analyses skyld. Start med mål, vælg værktøjet, og derefter - analytics skal kun anvendes, hvor det vil give effekt.
Materialet er forberedt i samarbejde med Olga Chebotary ().
Kilde: habr.com
