augusti 17, 2016
»En backlog är bara en lista över otestade hypoteser. Det enda acceptanskriteriet är business outcome«. Jeff Gothelfs ord låter så fina och kloka. Men hur blir det i praktiken?
Jag jobbar som konsult på SVT med tjänsterna Svt.se och Svtplay.se. Det är välbesökta webbplatser med tydliga och mätbara mål. Kulturen på SVTi (som utvecklar SVT:s digitala tjänster) uppmuntrar eget ansvar, decentraliserade beslut i teamen, samt misstag som lärande. Alltså finns alla förutsättningar på plats för att jobba med lärande framför featureutveckling. Check, check och check.
Att sätta datadriven kultur
Det är ju det det handlar om. Att snabbast lära sig vad som skapar nytta framför att utveckla funktioner och innehåll med hagelbössemetoden. I vårt fina team försöker vi alltid dema lärande och enbart lärande. Alltså insikter, data från experiment samt vad vi får ut av vår KPI-uppföljning.
I vårt fina team försöker vi alltid dema lärande istället för skeppade features
Förut demade team jag jobbat i vad vi utvecklat. Massa features och funktioner. Det kändes alltid trevligt att visa vad en slitit med. Men det blev fel fokus. Det etablerades fel sanningar. Att vi skapat värde nu när våra features var skeppade. Vi kunde skapa waste och komma undan med det. Inte bra när en jobbar med värdefulla licenspengar.
Effekten av att endast dema lärande visade sig efter ett tag. Målen blev gemensamma för intressenter och vårt team. Redaktörer ville köra egna A/B-test. Hjälpa till att nå målen. Kravställare ville ha uppskattningar av förväntade effekter av olika idéer innan de "beställde".
Vi är inga stora fans av dogmatiska läror, processer eller metoder i teamet. Men vi försöker förstå hur vi jobbar. Så vi ritade upp en process.
En modell för hur vi jobbar med krav.
1. Beställning och initiativ
Det kommer beställningar till teamet. Helst vill vi ha beställningar i utforskande, sokratisk stil. Typ: "Utforska personalisering av rekommendationer i SVT Play". Eller "Vad händer om vi flyttar tv-tablån från Svt.se till Svtplay.se?".
Krav kan också uppkomma genom initiativ i teamet. Bra idéer helt enkelt. Eller resultat av hack vi gör på de schemalagda hackdagar vi har.
2. Research
Hur mycket ska en researcha ett krav? Svår fråga men enkelt svar. Tillräckligt mycket så att du kan formulera tillräckligt pricksäkra hypoteser. Är kostnaden för att validera hypotesen hög? Researcha mer. Har du förutsättningar för att testa hypoteser billigt (rekommenderas som strategi)? Begränsa researchen till ett minimum.
Vi får in en större beställning. Det första vi gör är att räkna på potential gentemot de olika tjänsternas mål. Kommer beställningen att hjälpa oss att nå våra mål? Vi räknar och räknar genom traditionell webbanalys. Vi har metrics på det mesta, in i minsta detalj. Men det finns också värdefull data vi saknar. Vi kan till exempel inte koppla total tittad tid till justeringar vi gör i gränssnittet.
Exempel på flödesanalys sidtyper på Svtplay.se
Vi tittar på våra mätetal: historik, säsongsvariationer och trender över tid. Genom månadsuppföljning och alla A/B-test vi genomför (kanske 50 st senaste året) får vi bra uppskattning för hur stor potentialen är för idén. T.ex. att flytta tv-tablån från Svt.se till Svtplay.se. Vi har metrics på avhoppningsfrekvens, exits, konverteringar till Svtplay.se etc. Vi har metrics på besökarvolym över tid, vi kan se på Google Trends hur sökningnar på "tv-tablå" utvecklats över tid.
Vi kan i många fall hjälpa beställare att redan här förstå hur beställningen kommer påverka våra övergripande mål. Att förstå potentialen i form av besökarvolym och måluppfyllnad. Tidigt hantera förväntningar på effekter.
3. Design studio
Om det behövs genomför vi design studios. För att fånga synpunkter och lösningsidéer från alla intressenter och medlemmar i teamet. För att få hela teamet att förstå helheten och vilket problem vi vill lösa; team alignment. Design studios kan vara väl förberedda eller ad hoc beroende på problemets komplexitet, risk och kostnad för att testa idéer.
Mycket är bra med design studios. Men ibland blir det väl mycket kommittédesign. Ingen skärpa eller edge i lösningsförslagen. Utsmetade koncept utan tydlig riktning. Ibland blir det riktigt bra. Kanske påverkar feedbackkulturen i gruppen resultatet. Är den bra blir det bra.
4. Hypoteser
Outputen från research och design studio-arbetet är hypoteser. Krav har blivit hypotes. Härifrån pratar vi om hypoteser hela tiden. Aldrig om krav. "Hypoteser" sätter fokus på osäkerhet som behöver valideras."Krav" sätter fokus på något som är etablerat som bra för tjänsten och användarna. Och det vet vi ju inte ännu.
Härifrån pratar vi om hypoteser. Aldrig om krav.
En kan skriva hypoteser på alla möjliga skitnödiga sätt. Vi skriver dem lite hur vi vill. Ibland som krav, ibland lite mer strukturerat med målgrupper. Det viktigaste är att en får med hur hypotesen ska valideras. Då är en hemma.
Exempel på hypoteser, MVP och mätpunkter.
5. MVP (Minimum Viable Product)
I teamet diskuterar vi vad som är det absolut minsta vi behöver bygga för att testa hypotesen. Ofta blir det ett eller flera dumma och snabba experiment i form av A/B-test. Vi hårdkodar in en ny rekommendationsrad på Svtplay.se:s startsida under vissa tidpunkter som är relevanta för testet. Vi lägger in ett halvdynamiskt tablå-element på Svt.se:s startsida.
I andra fall utvecklar vi en mer färdig tjänst som vi A/B-testar. Ibland på få, ibland på många. Det beror på trafikvolym och risken att varianter presterar så dåligt att det påverkar hela tjänstens måluppfyllnad. Vi vill inte riskera att antal videostarter minskar med flera tusen p.g.a. validering av en hypotes.
Exempel på dumt A/B-test i Optimizely som går snabbt att ta fram.
Ser vi potential efter genomfört A/B-test gör vi nästan alltid ett uppföljningstest. Vi vill minska risken att innehåll, tidpunkt eller andra faktorer har påverkat resultatet. Samma test igen. Ibland ser vi viss potential och justerar lösningsförslagen och testar igen. Och sedan uppföljningstest igen.
Här pratar vi nålsöga.
Hypoteser som validerats går vidare in i prioritering. Hypoteser som inte validerats kastas i papperskorgen eller skrivs om. Om beställare vill gå vidare med hypoteser som inte validerats gör vi klart vad konsekvenserna blir. Hur det påverkar tjänstens mål. Teamet gör tydligt att vi härifrån inte tar något ansvar för hur den här hypotesen påverkar måluppfyllnaden.
(Kan inte nog poängtera hur viktigt det är att alltid inkludera tjänstens övergripande mål i A/B-test. Det händer ofta att vi ser positiva resultat i A/B-test på mikronivå, alltså nytt innehåll eller funktion, medan det övergripande målet påverkats negativt eller inte alls. Då handlar det ofta om kannibalism och risk för suboptimering.)
6. Utveckling
Vanlig fin utveckling och skeppning.
7. Uppföljning över tid
En kan tro att vi genom analys och validering av hypoteser har så hög pricksäkerhet att vi är säkra på att vi skapat värde. Men nej. Vi behöver följa upp över tid. En kan ha missat något, säsongsvariationer, innehåll eller något annat kan ha påverkat. Något en inte tänkt på.
Vi skriver ner i vårt kravverktyg hur en ska följa upp hypotesen. Så att alla kan göra det. Mätpunkter och hur en hittar till rapporten.
Skriv in hur hypoteser ska följas upp i ditt kravverktyg.
KPI-uppföljning som skyddsnät
Den här processen är något förenklad. Men inte mycket. Vi jobbar med kvalitativa metoder när det behövs. I researchfasen om komplexiteten är stor. Om A/B-test visar på knasig data, kanske vi vill förstå varför. Vi använder dock aldrig kvalitativa metoder som användningstest för att validera hypoteser. Det vore oprofessionellt.
Vi struntar såklart i att validera hypoteser ibland. Vi kör bara på. Det gör vi vid mindre krav och när vi har mycket kunskap om hur tjänsten kommer påverkas av kravet.
Vi har ett gigantiskt (skojar inte) uppföljningsark där vi följer upp både KPI:er och detaljerade metrics varje månad. Det är vårt skyddsnät så att vi inte släpper igenom krav som inte skapar värde på lång sikt. Uppföljningsdokumentet gör att vi är beredda att taktiskt göra förändringar och omprioriteringar.
Bild av Johan Larsson under CC BY 2.0
