DevOps-filosofin, när utveckling kombineras med mjukvaruunderhåll, kommer inte att förvåna någon. En ny trend tar fart - DevOps 2.0 eller BizDevOps. Den kombinerar tre komponenter till en enda helhet: verksamhet, utveckling och support. Och precis som i DevOps utgör ingenjörspraktik basen för kopplingen mellan utveckling och support, och i affärsutveckling tar analytics rollen som ”limmet” som förenar utveckling med affärer.
Jag vill erkänna direkt: vi fick reda på först nu att vi har en riktig affärsutveckling, efter att ha läst smarta böcker. Det gick på något sätt ihop tack vare initiativ från medarbetarna och en oåterkallelig passion för förbättring. Analytics är nu en del av utvecklingsproduktionsprocessen, vilket avsevärt minskar återkopplingsslingor och ger regelbundet insikter. Jag ska berätta i detalj hur allt fungerar för oss.
Nackdelar med klassiska DevOps
När nya kundprodukter utformas skapar ett företag en idealisk modell för kundbeteende och förväntar sig god konvertering, på basis av vilken den bygger sina affärsmål och resultat. Utvecklingsteamet å sin sida strävar efter att göra mycket bra kod av hög kvalitet. Support hoppas på fullständig automatisering av processer, enkelhet och bekvämlighet för att underhålla en ny produkt.
Verkligheten utvecklas oftast på ett sådant sätt att kunder får en ganska komplex process, verksamheten har fastnat med låg konvertering, utvecklingsteam släpper fix efter fix och support dränks i flödet av förfrågningar från kunder. Låter bekant?
Roten till det onda här ligger i den långa och dåliga återkopplingsslingan som är inbyggd i processen. När företag och utvecklare samlar in krav och får feedback under sprints, kommunicerar de med ett begränsat antal kunder som i hög grad påverkar produktens öde. Ofta är det som är viktigt för en person inte alls typiskt för hela målgruppen.
Att förstå om en produkt rör sig i rätt riktning kommer med finansiella rapporter och marknadsundersökningsresultat månader efter lanseringen. Och på grund av den begränsade urvalsstorleken ger de inte möjlighet att testa hypoteser på ett stort antal klienter. I allmänhet visar det sig vara långt, felaktigt och ineffektivt.
Troféverktyg
Vi hittade ett bra sätt att komma bort från detta. Ett verktyg som tidigare bara hjälpt marknadsförare har nu hittat sin väg i händerna på företag och utvecklare. Vi började aktivt använda webbanalys för att titta på processen i realtid, här och nu för att förstå vad som händer. Utifrån detta, planera själva produkten och rulla ut den till ett stort antal kunder.
Om du planerar någon form av produktförbättring kan du direkt se vilka mätetal det är förknippat med, och hur dessa mätvärden påverkar försäljning och egenskaper som är viktiga för verksamheten. På så sätt kan du omedelbart sålla bort hypoteser med låg effekt. Eller till exempel rulla ut en ny funktion till ett statistiskt signifikant antal användare och övervaka mätvärdena i realtid för att förstå om allt fungerar som det är tänkt. Vänta inte på feedback i form av förfrågningar eller rapporter, utan övervaka och justera omedelbart processen för att skapa produkter själv. Vi kan rulla ut en ny funktion, samla in statistiskt korrekt data på tre dagar, göra ändringar på ytterligare tre dagar – och om en vecka är en fantastisk ny produkt klar.
Du kan spåra hela tratten, alla kunder som kom i kontakt med den nya produkten, upptäcka punkter där tratten minskade kraftigt och förstå orsakerna. Både utvecklare och företag övervakar nu detta som en del av deras dagliga arbete. De ser samma kundresa och tillsammans kan de generera idéer och hypoteser för förbättringar.
Denna integration av affär och utveckling tillsammans med analys gör det möjligt att skapa produkter kontinuerligt, ständigt optimera, söka efter och se flaskhalsar, och hela processen som helhet.
Allt handlar om komplexitet
När vi skapar en ny produkt börjar vi inte från noll, utan integrerar den i en redan befintlig webb av tjänster. Vid provning av en ny produkt kontaktar en kund oftast flera avdelningar. Han kan kommunicera med kontaktcenteranställda, med chefer på kontoret, han kan kontakta support eller i onlinechattar. Med hjälp av mätvärden kan vi till exempel se vad belastningen är på kontaktcentret, hur man bäst behandlar inkommande förfrågningar. Vi kan förstå hur många som når kontoret och föreslå hur vi kan ge kunden ytterligare råd.
Det är precis samma sak med informationssystem. Vår bank har funnits i mer än 20 år, under vilken tid ett stort lager av heterogena system har skapats och fungerar fortfarande. Interaktion mellan backend-system kan ibland vara oförutsägbar. Till exempel, i vissa gamla system finns det begränsningar för antalet tecken för ett visst fält, och ibland kraschar detta den nya tjänsten. Det är ganska svårt att spåra en bugg med standardmetoder, men att använda webbanalys är enkelt.
Vi kom till den punkt där vi började samla in och analysera feltexter som visas för kunden från alla inblandade system. Det visade sig att många av dem var föråldrade och vi kunde inte ens föreställa oss att de på något sätt var involverade i vår process.
Jobbar med analys
Våra webbanalytiker och SCRUM-utvecklingsteam finns i samma rum. De interagerar ständigt med varandra. När det behövs hjälper specialister till att ställa in mätvärden eller ladda ner data, men mestadels arbetar teammedlemmarna själva med analystjänsten, det finns inget komplicerat där.
Hjälp krävs om du till exempel behöver vissa beroenden eller ytterligare filter för en begränsad typ av klienter eller källor. Men i dagens arkitektur stöter vi sällan på detta.
Intressant nog krävde implementeringen av analys inte installationen av ett nytt IT-system. Vi använder samma mjukvara som marknadsförare tidigare arbetat med. Det var bara nödvändigt att komma överens om dess användning och implementera den i affärer och utveckling. Naturligtvis kunde vi inte bara ta vad marknadsföring hade, vi var tvungna att konfigurera om allt på nytt och ge marknadsföring tillgång till den nya miljön så att de skulle vara i samma informationsfält som oss.
I framtiden planerar vi att köpa en förbättrad version av webbanalysprogramvara som gör att vi kan hantera de ökande volymerna av bearbetade sessioner.
Vi arbetar också aktivt med att integrera webbanalys och interna databaser från CRM och redovisningssystem. Genom att kombinera data får vi en helhetsbild av kunden i alla nödvändiga aspekter: efter källa, typ av kund, produkt. BI-tjänster som hjälper till att visualisera data kommer snart att bli tillgängliga för alla avdelningar.
Vad slutade vi med? Faktum är att vi gjorde analyser och beslutsfattande om det till en del av produktionsprocessen, vilket hade en synlig effekt.
Analys: trampa inte på raken
Och till sist vill jag dela med mig av några tips som hjälper dig att undvika att hamna i problem i processen att bygga upp en affärsutvecklingsverksamhet.
- Om du inte kan göra analyser snabbt, gör du fel analys. Du måste följa en enkel väg från en produkt och sedan skala upp.
- Du måste ha ett team eller en person som har god förståelse för framtidens analysarkitektur. Du måste fortfarande bestämma dig på stranden hur du ska skala analysen, integrera den i andra system och återanvända data.
- Generera inte onödig data. Webbstatistik är, förutom användbar information, också en enorm soptipp med låg kvalitet och onödig data. Och detta skräp kommer att störa beslutsfattande och bedömning om det inte finns några tydliga mål.
- Gör inte analyser för analysens skull. Först, mål, val av verktyg, och först därefter - analys bara där det kommer att ha effekt.
Materialet framställdes tillsammans med Chebotar Olga ().
Källa: will.com