presentation_none
>

Målbasert Utvikling

Eivind Andreas Arvesen 
28. feb. 2018

Smidig metodikk fra en utviklers perspektiv

På teamet jeg er en del av jobber vi med flere løpende prosjekter for samme kunde. Vi arbeider strategisk med kontinuerlig forbedring i et kryssfunksjonelt team, bestående av prosjektleder, analytiker, designere og utviklere. Vi kan eliminere ulønnsomme aktiviteter ved å utvikle iterativt, måle resultater og å bygge hyppig. Dette lar oss optimalisere arbeid som resulterer i verdi for kunde.

Vår smidige arbeidsprosess henter elementer fra flere steder, som Scrum, Agila, Kanban, DevOps og Lean Startup.

Prosessen

Fra Scrum henter vi konseptene om et selvdrevet team med store fullmakter og standups; fra Agile (smidig) tar vi filosofien om å eliminere ikke-lønnsomme aktiviteter; fra Kanban henter vi fokuset på å begrense mengden igangsatt arbeid og å visualisere dette; fra DevOps kommer tanken om å ta eierskap til hele løpet - fra planlegging, gjennom utvikling og til drift ( eller "you build it, you run it"); Lean Startup gir oss fokuset på å validere løsningen - Hvorfor bygger vi det vi gjør, og vil det medføre suksess (hvordan kan vi vite dette)?

Fokuset på validert læring innebærer at vi til enhver tid begrenser oss til å lage kun det som lages - såkalte Minimal Viable Products (MVPs). Vi gjør dette via testbare hypoteser, iterativt arbeid på løsningen og validert læring.

MVP er motivert av "build, measure and learn"-prosessen fra Lean Startup. Dette innebærer at man hver gang man lager noe nytt også må ha en plan for validering - hvordan man måler innvirkning på bruker og påvirkning på den totale løsningen - og en prosess som tilrettelegger for å lære av denne dataen og iterere over løsningen og lansere på nytt. Dette lar en bygge videre på det en vet fungerer etter sin hensikt - og fortsette å validere hver ny iterasjon.

På utviklersiden fordrer dette reproduserbare utviklingsmiljøer og en arbeidsflyt som tilrettelegger for kontinuerlig bygging (f.eks. Git Flow), inkl. f.eks. automatisk testing og automatiserte bygg. Dette bidrar til å senke terskelen for å få endringer ut til produksjon, og lar oss gjennomføre deployment opp til flere ganger om dagen. Det krever at arbeidsflyten lar oss enkelt gjøre endringer, samt at en eventuell tilbakerulling er enkel å gjennomføre.

Denne prosessen avhenger av god kommunikasjon og informasjonsflyt mellom interessenter, som produkteier og medlemmene av utviklingsteamet. I vårt tilfelle gjennomfører vi ukentlige demomøter, der vi går over den siste dataen fra pågående eksperimenter, status på oppgaver som er under arbeid og prioriterer backlog.

Alt dette gir oss raskere endringsevne.

Eksemplene i denne teksten vil ta utgangspunkt i en oppskriftsside vi lager for en større kunde, da dette er løsningen jeg hovedsakelig jobber på.

Arbeidsmetodikk

Som utgangspunkt for å jobbe målbasert i henhold til Lean Startup metodikk forholder vi oss til tre nivåer med mål/avgjørelser:

  • Strategisk mål (kundens overordnede mål: mellom 10 og 20 KPIer, f.eks. å forbedre omdømme)

  • Taktisk mål (produkteiers mål via strategi for å nå det strategiske målet, f.eks. å sikre en høy Google ranking for å oppnå mer organisk trafikk)

  • Operasjonelt mål (måle effekt fra våre handlinger mot det taktiske målet, f.eks. å optimalisere bilder for å redusere lastetid på siden)

All utvikling knyttes opp mot de strategiske og taktiske målene. Vi starter derfor med en hypotese om hvordan vi kan forbedre den nåværende løsningen og formulerer vårt operasjonelle mål utifra dette.

Planleggingsprosessen for en ny feature inneholder derfor følgende trinn:

Identifisere taktisk mål

Vi og/eller kunden identifiserer et mål å jobbe mot, f.eks. å få brukere til å bli lenger på siden og ikke returnere til Google.

Handling

Noe vi kan gjøre som et forsøk på å nå målet vårt, f.eks. å tilgjengeliggjøre enda et nivå i brødsmulestien på innholdssider.

Hypotese

Grunnen til at vi gjennomfører handlingen; hvorfor vi tror at den gitte handlingen vil virke etter hensikt og oppnå resultatene vi ønsker, f.eks. at å gjøre mer relatert innhold fra samme innholdskategori tilgjengelig vil gi brukerne flere alternative stier å utforske.

Måle

Hvordan vi måler handlingens virkning; Identifisere hvordan et vellykket eksperiment vil se ut, f.eks. at sidevisninger og/eller en økning i tid brukt på siden per besøk.

Her vil vi trenge å planlegge lanseringsdato og muligens innhente data som sammenligningsgrunnlag i forkant. Vi benytter oss ofte av A/B-testing som metode for å måle resultater. Vi vil også trenge å definere en tidsramme for sammenligning.

Estimert effekt

Hva slags effekt vi tror vi kommer til å være i stand til å se fra målingene, f.eks. en økning i sidevisninger på kategorisider.

Under et illustreres eksempel på et case vi har gjennomført ved hjelp av "The LEAN Learning loop", som vi bruker i teamet.

Prosess fra A til Å

Utviklingssyklusen kan grovt deles inn i følgende seks steg, som jeg her vil illustrere ved erfaringer fra vår løsning.

learningLoopLean Learning Loop.

Ideer

Fra en brukertest oppdaget vi at det var lite navigasjon mellom innhold; hvis brukere ikke fant det de var på utkikk etter returnerte de til der de kom fra.

scrollsAndel av brukerne som så deler av siden.

Bygg, Produkt

Vi la derfor følgende plan for å jobbe mot det taktiske målet (økt engasjement):

  • Handling: Flytte relaterte oppskrifter oppover, til over kommentarfeltet.

  • Hypotese: Ved å vise relaterte oppskrifter tidligere på siden tror vi at det er mer sannsynlig at brukere vil klikke seg videre i løsningen, snarere enn å gå tilbake til Google.

  • Måle: Fler klikk på relaterte oppskrifter.

  • Dagens tall: Mellom 5000 og 7000 klikk per uke (hypotetiske tall).

  • **Estimert effekt: 180% økning, rundt 8000 fler klikk.

  • Tidsramme: Sjekk status 1 uke etter produksjonssetting.

solutionLøsning med relatert innhold over kommentarfeltet.

Mål, Data

  • Taktisk mål: Øke engasjement

  • Få besøkende til å bli på siden og ikke returnere til Google.

    • Flere sidevisninger på besøk.

    • Økt tid brukt på side per besøk.

statisticsGrafer over events / sessions.

Grafen over viser at flere har trykket på relaterte oppskrifter etter at vi gjennomførte endringer.

Fra dataene kan vi se følgende:

Gjennomsnittlig tid brukt per besøk Gjennomsnittlig sider sett per besøk
Endring + 00:00:02 - 0,02

Lær

eventsFiredAntall brukere som utløste forskjellige events.

  • Ved å flytte relaterte oppskrifter opp nedprioriterer vi annet innhold, f.eks. kommentarer.

  • Andel brukere som ser kommentarer har gått fra 19,8% til 9.01%.

  • Det ble opprettet færre kommentarer denne måneden enn samme måned året før.

Vi tolker resultatene som at vi nådde vårt operasjonelle mål ved å tilgjengeliggjøre mer relevant innhold, siden flere brukere klikker på relaterte oppskrifter. De positive resultatene bekreftet hypotesen - vi anser derfor eksperimentet som vellykket.

På den negative siden ser vi også at det ble opprettet færre kommentarer etter at kommentarfeltet ble plassert under relaterte oppskrifter. Vi ønsker derfor å motvirke denne effekten.

Ideer

  • Handling: Lage en snarvei til kommentarfeltet i oppskriftens hovedinnhold.

  • Hypotese: Brukerne kan ikke enkelt se at det finnes kommentarer på oppskriften. Det kan se ut som om sidens innhold er over når man når det relaterte innholdet.

  • Mål: Motarbeide negativ effekt fra endret posisjon på siden.

  • Dagens tall: Fra 280 til 145 nye kommentarer.

shortcutForslag på lenke til kommentarfelt.

Oppsummert

Denne måten å jobbe på er veldig inspirerende som utvikler. De kollaborative beslutningsprosessene gir økt følelse av eierskap til endringene og lar oss få bedre innsikt på makroplan - som gjør det enklere å forstå hvordan det enkelte bidrag påvirker totaliteten av løsningen. Etter vår erfaring gjør det også utviklingssyklusen raskere og målingene vi gjør av hvordan endringene påvirker brukerne underveis bidrar til bedre forståelse og økt motivasjon. Det krever dog tillit og at alle involverte parter er med på denne tankegangen.

Målinger og fokus på resultater lar oss verifisere at endringene våre er for det bedre ved å verifisere at vi når målene våre, via prosessen Lean-startup metodologien summerer opp som "build-measure-learn" (bygg-mål-lær).

Dette lar oss fokusere på om resultatene dekker kundens behov - i stedet for å være låst til en gitt spesifikasjon, som i verste fall kan vise seg å ikke dekke alle behovene til kunden etter at løsningen er ferdig bygd.

Vi kan summere opp arbeidsprosessen på denne måten: Test hypotesene dine (i forhold til hvordan du kan nå målene dine) og feil fort om du må. På den måten bruker du ikke resursser på handlinger som ikke gjør løsningen bedre. Dette inspirerer til kreativitet og fører til lavere risiko og kostnader.