DevOps-filosofin, dĂ€r utveckling förenas med mjukvaruunderhĂ„ll, förvĂ„nar ingen lĂ€ngre. En ny trend har vuxit fram â DevOps 2.0 eller BizDevOps. I denna fusion samlas tre komponenter: affĂ€rer, utveckling och support. Precis som ingenjörspraxis i DevOps ligger till grund för kopplingen mellan utveckling och support, sĂ„ tar analysen i BizDevOps rollen som 'limmet' som förenar utvecklingen med affĂ€ren.
Jag vill genast erkÀnna: att vi har lyckats skapa en Àkta BizDevOps, insÄg vi först nu efter att ha lÀst kloka böcker. Det har liksom blivit sÄ tack vare medarbetares initiativ och en omÀttlig passion för förbÀttringar. Nu Àr analys en del av utvecklingsprocessen som vÀsentligt minskar feedbackloopar och regelbundet förser oss med insikter. Jag ska berÀtta i detalj hur allt Àr ordnat hos oss.
Nackdelar med klassisk DevOps
NÀr nya kundprodukter designas skapar affÀren en perfekt modell för kundbeteende och rÀknar med en god konversion, pÄ grundval av vilken de bygger sina affÀrsmÄl och resultat. Utvecklarteamet Ä sin sida strÀvar efter att skapa mycket bra, kvalitativ kod. Supporten hoppas pÄ full automatisering av processerna, pÄ enkelhet och bekvÀmlighet i hanteringen av den nya produkten.
Verkligheten brukar oftast se ut sÄ hÀr: kunderna fÄr en ganska komplicerad process, affÀren kÀmpar med lÄg konversion, utvecklingsteamen slÀpper fix efter fix, medan supporten drunknar i en ström av kundÀrenden. KÀnns det bekant?
Rötterna till ondskan ligger i den lÄnga och dÄliga feedbackloopen som Àr inbyggd i processen. AffÀren och utvecklarna har under kravinsamling och mottagande av feedback under sprintar kommunikation med ett begrÀnsat antal kunder som har stor pÄverkan pÄ produktens öde. Ofta Àr det som Àr viktigt för en person helt otypiskt för hela mÄlgruppen.
Insikten om huruvida produktens utveckling gÄr i rÀtt riktning kommer tillsammans med ekonomiska rapporter och resultaten frÄn marknadsundersökningar flera mÄnader efter lanseringen. Och dessa ger, pÄ grund av urvalets begrÀnsningar, inte möjlighet att testa hypoteser pÄ en stor volym kunder. Sammanfattningsvis blir det lÄngsamt, ofullstÀndigt och ineffektivt.
Troféverktyg
Vi har hittat ett bra sÀtt att komma bort frÄn detta. Ett verktyg som tidigare bara hjÀlpte marknadsförare har nu hamnat hos företag och utvecklare. Vi har börjat anvÀnda webbansanalys aktivt för att kunna se processen i realtid, förstÄ vad som hÀnder hÀr och nu. Baserat pÄ detta kan vi planera produkten och dess utrullning till ett stort antal kunder.
Om det planeras nĂ„gon förbĂ€ttring av produkten kan vi direkt se vilka metrik det Ă€r kopplat till och hur dessa metrik pĂ„verkar försĂ€ljningen och viktiga karakteristika för verksamheten. PĂ„ sĂ„ sĂ€tt kan vi snabbt rensa bort hypoteser med lĂ„g effekt. Eller till exempel rulla ut en ny funktion till ett statistiskt betydande antal anvĂ€ndare och i realtid följa metrik, förstĂ„ om allt fungerar som tĂ€nkt. Vi behöver inte vĂ€nta pĂ„ feedback i form av klagomĂ„l eller rapporter, utan kan istĂ€llet sjĂ€lva övervaka och snabbt justera produktutvecklingsprocessen. Vi kan rulla ut en ny funktion, samla in statistiskt korrekta data efter tre dagar, göra ytterligare Ă€ndringar pĂ„ tre dagar â och pĂ„ en vecka har vi en utmĂ€rkt ny produkt.
Vi kan spÄra hela tratten, alla kunder som har kommit i kontakt med den nya produkten, upptÀcka punkter dÀr tratten plötsligt smalnar av och förstÄ orsakerna. BÄde utvecklare och företag följer nu detta, det Àr en del av det dagliga arbetet. De ser samma kundresa och kan tillsammans generera idéer och hypoteser för förbÀttringar.
Denna integration av verksamhet och utveckling tillsammans med analys gör det möjligt att skapa produkter kontinuerligt, stÀndigt optimera, söka och se snÀva punkter, samt hela processen i stort.
Det handlar om komplexitet
NÀr vi skapar en ny produkt börjar vi inte frÄn ett tomt papper, utan integrerar den i det redan existerande nÀtverket av tjÀnster. I samband med den nya produkten kommer kunden oftast i kontakt med flera avdelningar. De kan kommunicera med kontaktcenter-personal, med chefer pÄ kontoret, kanske kontakta supporten eller online-chattar. Genom metrik kan vi till exempel se vilken belastning kontaktcentret har, hur vi bÀst hanterar inkommande förfrÄgningar. Vi kan förstÄ hur mÄnga som nÄr kontoret och ge rÄd om hur man vidare kan rÄdgiva kunden.
Med informationssystemer Àr det precis likadant. VÄr bank har funnits i över 20 Är, och under denna tid har en stor mÀngd olika system skapats och fortsÀtter att fungera. Interaktionen mellan backend-system kan ibland vara oförutsÀgbar. Till exempel, i nÄgot gammalt system finns det begrÀnsningar för antal tecken i ett visst fÀlt, och ibland kraschar detta den nya tjÀnsten. Att spÄra buggar pÄ vanliga sÀtt Àr ganska svÄrt, medan det Àr enkelt med hjÀlp av webb-analys.
Vi har nÄtt den punkten att vi börjar hÀmta och analysera felmeddelanden frÄn alla involverade system, som visas för klienterna. Det visade sig att mÄnga av dem var förÄldrade, och vi kunde knappt förestÀlla oss att de pÄ nÄgot sÀtt deltog i vÄr process.
Arbete med analys
Vi har webb-analytik och SCRUM-team av utvecklare i samma lokal. De interagerar stÀndigt med varandra. Vid behov hjÀlper specialisterna till att stÀlla in mÀtvÀrden eller exportera data, men i det mesta arbetet hanterar teammedlemmarna sjÀlva analysverktyget, dÀr Àr inget komplicerat.
HjÀlp behövs om det till exempel finns nÄgra beroenden, ytterligare filter för begrÀnsade typer av kunder eller kÀllor. Men i den nuvarande arkitekturen stöter vi sÀllan pÄ detta.
Intressant nog krÀvde införandet av analys inte installation av nÄgot nytt IT-system. Vi anvÀnder samma programvara som tidigare anvÀnds av marknadsförarna. Det krÀvdes bara att godkÀnna dess anvÀndning och integrera den i affÀrer och utveckling. SjÀlvklart kunde vi inte bara anvÀnda det som marknadsföringen har, utan vi var tvungna att stÀlla in allt pÄ nytt och ge marknadsföringsavdelningen tillgÄng till den nya miljön sÄ att de kunde vara med oss i samma informationsfÀlt.
I framtiden planerar vi att köpa en förbÀttrad version av programvaran för webbanalys, vilket kommer att möjliggöra hantering av de ökande volymerna av bearbetade sessioner.
Vi har ocksÄ en aktiv process för att integrera webb-analys och interna databaser frÄn CRM och redovisningssystem. Genom att förena data fÄr vi en fullstÀndig bild av kunden i alla nödvÀndiga dimensioner: efter kÀllor, kundtyper och produkter. BI-tjÀnster som hjÀlper till att visualisera data kommer snart att bli tillgÀngliga för alla avdelningar.
Vad blev resultatet? Faktiskt har vi gjort analys och beslutande del av produktionsprocessen, vilket har gett synliga resultat.
Analys: trampa inte pÄ samma mina igen
Till sist vill jag dela med mig av rÄd som kan hjÀlpa dig att undvika misstag i processen att bygga BizDevOps.
- Om du inte kan göra analysen snabbt, gör du antagligen fel analys. Du bör gÄ den enkla vÀgen 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 den framtida arkitekturen av analysen. Du bör ocksÄ i förvÀg besluta om hur ni ska skala upp analysen, integrera den i andra system och ÄteranvÀnda data.
- Generera inte onödiga data. Webbstatistik handlar utöver anvÀndbar information ocksÄ om en enorm skrÀphög med okvalitativa och överflödiga data. Denna skrÀp kommer att hindra beslutsfattande och utvÀrdering om det inte finns tydliga mÄl.
- Gör inte analys bara för analysens skull. Först mĂ„l, val av verktyg, och först dĂ€refter â analys dĂ€r det ger effekt.
Materialet Àr förberett tillsammans med Olga Chebotar ().
KĂ€lla: habr.com
