Always in Beta
För att utmärka sig bland sina konkurrenter idag behöver digitala lösningar snabbare nå ut på marknaden och löpande optimeras för ett mer hållbart hushållande av sina resurser. Detta är något som ställer höga krav på webbutveckling i form av arbetsprocesser, hållbara koncept, analys och ständig närvaro av en produktägare.
Fler bygger fortfarande hela sin digitala närvaro på en gigantisk hypotes skör nog att spricka vid första validering. Det är hög tid att etablera ett hållbart arbetssätt och på allvar fundera över vad som egentligen skapar värde. Att vara ”always in beta” innebär att aldrig blir helt klar och att ständigt förädla sina initiativ även om man tror sig nått perfektion.
I extrema fall etableras digitala projekt på lösa grunder som att ett CMS är i behov av uppgradering, en budget har tillkommit utan en föranledd förstudie, eller att den statistik som redan bakåt i tiden visade att webbplatsen var i behov av en mobilanpassning nu nått en beställare. Inte för att rapporten kom fram, utan för att hela företaget helt övergått till smartphones och upptäckt det själva.
Personer med mandat över budget ställer sällan krav på uppföljning utan endast krav på leverans till avtalat pris och ett förbestämt datum. Något som skvallrar om att satsningen ses som en engångskostnad och inte en investering. Det finns en hög inbyggd risk i att se nya webblösningar som ett projekt och inte ett förhållningssätt.
Så vad händer då med webbplatsen, intranätet och appen väl efter lansering? Vad ska fortsatt prioriteras och vad skapar egentligen ett långsiktigt värde?
Utmaningar
Hur ska man då arbeta för att garantera att lösningen byggs på en mer värdebaserad grund? Fler insåg tidigt att idén om den klassiska vattenfallsmodellen innebar oväntade kostnader och förskjutna tidplaner. Idag är arbetssättet istället ofta agilt med hjälp av scrum. Man arbetar med sprintar istället för individuellt tidsuppskattade funktioner efter varandra på nivåer av timmar. Man genomför delleveranser löpande och “beställaren” finns närvarande under sprintdemon. Dessutom sker en högre delaktighet från fler kompetensområden som gemensamt levererar högre kvalitet.
Utmaning #1 – Det tomma löftet
Som regel inleds arbetet med en strategi och konceptfas där man kommer överens om scoopet för det som ska levereras. Utifrån workshops och intervjuer realiseras ett koncept. I steg 1 som består av flera sprintar designas och utvecklas prioriterade funktioner. Ett releasedatum bestäms, ibland kopplad till en marknadsaktivitet eller varför inte en sommarfest. Alla nöjda, alla glada, eller? Efter flertalet genomförda projekt vet man att fasen för strategi och koncept ofta drar ut på tiden och eftersom beställaren förväntar sig en färdig helhetslösning behöver funktioner som nu utlovats levereras och remissrundorna läggs snabbt på hög.
Releasedatumet står trots allt intakt, sommarfesten är helig. Detta resulterar i att teamet får arbeta för högtryck eftersom man lovat att leverera enligt en statisk tidplan. Som regel hålls tidplanen, scoopet minskar, men budgeten springer ofta före. Resultatet blir att en del funktioner uteblir. Det höga omotiverade tempot påverkar snabbt både moralen och relationer med beställaren.
Vad händer då med all den utveckling från steg 1 som utlovats till steg 2? Steg 2 är inget annat än en låda utan innehåll när det kommer till webbutveckling. Steg 2 implementeras nämligen sällan fullt ut. Förklaringen är ofta brist på budget eller så var funktionerna aldrig så viktiga som man först ville tro. Det man däremot lyckats med är att plöja tid på ett koncept som aldrig realiserades. En kostnad utan nytta.
Detta är en av anledningarna till varför det i längden kostar mindre att anlita en leverantör med ett helhetserbjudande än flera som specialiserat sig på olika faser av ett projekt. Hade jag hållit i pengarna hade jag hellre anlitat en byrå som vet hur boken slutar än en byrå som ständigt övar på att skriva bokens förord.
Utmaning #2 — Arbetssättets negativa följder
Vad får då arbetssättet för konsekvenser för t.e.x. webbyrån och uppdragsgivaren? Diagrammet visar en ganska normal arbetsbelastning baserat på konsulters tidrapportering under två år. Som linjerna visar sker lanseringar inte sällan samtidigt som det lutherska arvet gör sig till känna. Vi talar givetvis om högtider och heliga semestrar. När beläggningsgraden för teamet slår över 100 % påverkar det tillslut motivationen och man tvingas till snabba omställningar internt för att hinna leverera i tid.
När lansering blir det uteslutande målet man arbetar efter, hamnar vi snabbt tillbaka i den klassiska vattenfallsmetoden. Prioritering av vad som ska med följer en otydlig ordning och kampen om att upprätthålla en gemensam transparent bild mot beställare avtar lätt med tiden.
När budgeten är förbrukad försvinner nyckelkompetenser till andra uppdrag och teamet blir snabbt sårbart. Att bänka konsulter innebär en direktkostnad och att vänta på att vinden vänder p.g.a. inledande fel fördelad budget är knappast rimligt idag. När beställaren väl får ny budget blir startsträckan ofta lång då nya personer från byrån tillkommit som på nytt behöver sätta sig in i uppdraget. Positiva, men med lång startsträcka.
Utmaning #3 – Tycke, smak och magkänslor
Har man bakåt i tiden tvingats flytta mellan olika andrahandslägenheter utvecklar man tillslut en säregen skicklighet runt själva flyttprocessen. Hemligheten är att vid varje flytt rensa upp i sentimentala lådor för att till nästa flytt minimera flyttlasten. När organisationer står inför en ny webbsatsning så tänker de som en privatperson inför en flytt. Den enda skillnaden är att ALLT innehåll ska med, 50.000 artiklar i ett flyttlass. Ibland är det som det finns en sentimental relation till alla kartor, bildkaruseller, puffar och 7 år gamla pressartiklar. Undervärdera aldrig betydelsen av en ordentligt genomförd nulägesanalys och använd det som kravställning, inte magkänslor.
Utmaning #4 – Missade trender
En annan utmaning idag med webbutveckling är att avståndet mellan releaser och större lanseringar kan vara längre än vad användarna har tålamod till. Linjediagrammet visar mobila besökare på en webbplats ej anpassad för mobila enheter med över 14 miljoner besök/år. Ökningen av mobila användare mellan åren 2013 och 2014 var hela 40% och trenden höll i sig för att kort tid därefter passera besökare från desktop. Att varken visualisera trender eller arbeta med prediktiva analyser för att förutspå trendbrott slår snabbt tillbaka. Demokratisera därför er tillgängliga data och börja agera i tid, innan besökarna lämnar er för gott.
Krav på ständig förändring
Så varför uppstår då samma problem om och om igen? Delar av sanningen ligger i att arbetssättet är linjärt i en värld som kräver ständig förändring. Det är inte lämpligt att arbeta enligt en metod liknande löpande band metodiken där vi redan från början har en bestämd uppfattning om vad slutprodukten ska bli. Men bakgrunden till detta är egentligen inte så märklig. När webbutvecklingen var i sin linda i slutet av nittiotalet var det mer naturligt att arbeta med samma designmetoder som tidigare använts. Oberoende om det varit industridesign, printdesign, modedesign eller annan produktdesign där produkten är av en fysisk vara har tillverkningsmomentet alltid varit kritiskt. Man måste veta exakt hur produkten ska se ut och fungera, annars blir produktion alltför kostsam.
Eftersom digital utbyggnad inte är en fysisk produkt, betyder det att vi behöver hitta nya angreppsätt. Vi behöver helt enkelt gå ifrån en traditionell produktutveckling och istället arbeta med en produkt som förädlas över tid. Vårt mål är inte längre att skapa en leverabel, utan att förändra ett beteende över tid och skapa långsiktigt värde.
Sammanfattning
Slutsatsen av detta reaktiva arbetssätt utan kontroll på värde eller utveckling leder till;
- en ojämn arbetsbelastning
- vi tvingas förlita oss på magkänslor eller till den som tycker mest
- vi missar avgörande trender
- saker som lovas till steg 2 blir aldrig av
Idé och mål
Lösning #1 — Målstyrt
Vad blir då lösningen på ovanstående problem? Först och främst behöver vi etablera ett målstyrt arbetssätt och att inte frångå målet när det kommer till vad vi arbetar med. Oavsett om målet är rörligt. Här är det oerhört viktigt att både beställaren och teamet vet åt vilket håll man är på väg, samt hur vägen dit ska se ut.
Steve Jobs citat förefaller självklart, d.v.s att man ibland stöter på hinder med nya lösningar och att det bästa är att identifiera dem snabbt och fortsätta med andra bättre lösningar. Problemet idag är att fler organisationer inte känner till om lösningen överhuvudtaget gör sitt jobb. Ska man kunna försvara en investering behöver man samtidigt kunna svara upp för hur bra lösningen når sina uppsatta mål. Du kommer inte undan med magkänslan.
Inled först och främst förbättringsarbetet utifrån ett antagande och en hypotes.
Problem: Vi fokuserar på att lösa ett problem, vi bygger t.e.x. inget intranät, vi löser ett problem att organisationen lägger för mycket tid på att skicka mail.
Mål: Målen måste finnas på plats för att vi ska kunna veta när problemet är löst. När resultatet är uppnått är vi på rätt kurs mot nästa mål.
Hur: Utifrån olika antaganden bygger vi en lösning baserat på minsta möjliga arbetsinsats.
Nyckeltal: Nyckeltalen hjälper oss att beräkna hur målet ska valideras.
Lösning #2 - Uppföljning till rätt mottagare
Det finns givetvis olika typer av uppföljning för olika mottagare, alla intresserade av sina delar. Men gemensamt bygger vi mot ett och samma mål som behöver vara tydligt för alla inblandade, nämligen affär — eller verksamhetsmålen. Det är väsentligt att hela teamet förstår vart vi är på väg oavsett roll.
Affärsnyttan: Vad är det reella värdet av det vi gör och vad är den övergripande nyttan? Vill vi öka lojalitet, öka konverteringsgraden eller effektivisera en kortare process i en längre kedja? I regel handlar det om att minska kostnader eller öka intäkter.
Användare: Hur nöjd är användarna med lösningen, vad är deras feedback? Undersök viljan att rekommendera med hjälp av NPS eller enklare enkäter med 1–4 frågor, inte mer.
Koncept: Hur presterar vårt koncept mot våra uppsatta mål? Hur används funktionerna, används de överhuvudtaget? Vad utmärker ett lyckat besök på webbplatsen? Löser de rätt uppgifter? Genomför löpande A/B tester för att bygga insikter om era användare. Allt handlar om att bygga insikter och därefter anpassa lösningen.
Bygg
Lösning #3 — Minsta gångbara produkt (MVP)
Nu är vi framme i ett läge där vi vet vilka problem vi ska lösa och vilka mål som ska uppfyllas, nästa steg är att börja utveckla. För att kunna validera vårt antagande om hur vi ska leverera värde måste vi testa det på riktiga användare. Vi kan inte vänta 1 år på att lösningen ska nå användarna. Därför bygger vi minsta gångbara produkt eller MVP (Minimal Viable Product). MVP bygger på att vi bygger det minsta vi kan för att testa vår viktigaste hypotes ställt mot ett övergripande mål, problem eller syfte.
Exempel
Vi vet att vi behöver ta oss från sträcka A till B. Vår hypotes är att vi använder oss utav ett fordon för att resa mellan sträckan. För att testa vår hypotes bygger vi den minsta gångbara produkten. I det här fallet är det en skateboard. Vi låter slutanvändaren testa vår skateboard och samlar under tiden in feedback som säger att den är svårbemästrad. Vi väljer då att ta fram en ny MVP där vi ber slutanvändaren testa en cykel. Feedbacken vi får tillbaka är att den inte är snabb nog och vi behöver därför konstruera ytterligare en MVP baserat på feedbacken. Vår nästa lösning blir en bil, som är förhållandevis snabb och säker. Genom att arbeta utifrån denna process har vi genom att lyssnat till användaren, samlat insikter och slutligen levererat ett påvisat värde.
Med hjälp av en MVP kan vi:
- testa vår idé med minimal ansträngning
- öka kunskapen om slutanvändaren
- reducera bortkastad tid på specificering av saker vi aldrig kommer bygga
- snabbare nå marknaden med en lösning
Lösning #4 – Teamkonstellation 2.0
För att kunna leverera värde och en produkt som hela tiden utvecklas och förädlas över tid behöver vi en ny typ av teamuppsättning.
Värde och problemfokus: Alla i teamet arbetar mot ett gemensamt mål och värde, inte funktioner och leverabler. Vi talar inte i termer av att bygga en sökfunktion utan att förenkla för användaren att hitta relevant innehåll. Teamet arbetar alltid utifrån problemlösning som grund och inte för att skapa ”the next cool feature”.
“-We want to be the company that makes mistakes as fast as possible”, Daniel Ek, Spotify.
Våga göra fel: Eftersom teamet arbetar utifrån kvalificerade antaganden så är det okej att ha fel. Ett antagande är ju bara ett antagande. Teamet kommer innan vi har kvalificerat underlag som styrker en tes att att arbeta utifrån hypoteser. Detta bygger på att det finns en kultur som tillåter fel och att fel inte är något annan än en insikt rikare.
“-Failure is success if we learn from it”, Malcolm Forbes
Korsfunktionellt: Samtliga kompetenser som behövs för att lösa ett problem behöver finnas i teamet från dag 1 och framåt. Allas insikter behövs för att skapa bättre idéer, detta för att motverka kunskapssilos. Inget team vill vara beroende av ”digitala experter” som tror sig veta hur allt ska göras.
Dedikerat och lokalt: Med ett samlat dedikerat team vana att arbeta tillsammans får man möjlighet att förbättra sin kommunikation, sitt fokus och arbetssätt samt en mer positiv laganda, förutsatt att man arbetar med sin feedback. Den som förespråkar delat ansvar, där ex. ett team designar åt ett annat som bygger saknar förmodligen erfarenhet av att bedriva större lyckade digitala projekt.
Lösning #5 – Uppdaterad metod
När teamet är på plats är det dags att se över vår reviderade arbetsmetod. Den gamla linjära metoden med olika faser för strategi, koncept, implementation och förvaltning är hävd. Istället inriktar vi oss på att bli agila på riktigt. Vi arbetar med sprintar från dag ett och hela teamet arbetar parallellt med design och utveckling. När en spring är färdig sker en release som når våra slutanvändare. Oavsett om det är en pappersprototyp, kodprototyp eller produktionskod. Det väsentliga är att varje release går ut till riktiga användare av lösningen är byggd för att lyckats kunna ta emot feedback.
Releaser sker kontinuerligt och kan variera i storleksgrad. Utifrån detta scenario kan vi nu gradvis bättra på vår lösning och ständigt koppla det vi gör mot övergripande mål och faktiskt testa av mot riktiga användare. Vi bjuder alltså inte in 10st representanter från vår målgrupp att klicka på principskisser och som ofta svarar utifrån ett grupptryck eller biobiljetterna de får som tack för hjälpen.
Med en ny modell där lösningen gradvis bygger på flera mindre releaser får vi istället en linjär arbetsbelastning. Ytterligare en fördel är att teamet nu enklare blir intakt. Vi har inte längre några dalar som gör att nyckelpersoner försvinner in i annat arbete utan bibehåller insikterna inom teamet över tid. Detta förutsätter givetvis att beställaren tar sin digitala närvaro på allvar och ser den som något som ständigt pågår snarare än riktade punktinsatser fram till ett förbestämt datum.
Leverans
Lösning #6 — Continuous delivery
Då vårt arbetssätt nu kommer att innebära att vi gör fler mindre releaser får tid för produktionssättning inte bli ett hinder. Vi behöver helt enkelt automatisera processen. Som tur är finns det en metodik för detta inom systemutveckling. Continuous delivery automatiserar och förbättrar leveransen av mjukvara, vilket är exakt det vi behöver till vår modell.
- Vi utvecklar för att lösa ett problem. När vi anser oss klara sparar vi koden i vår gemensamma kodbank där den även versionshanteras.
- Koden testas per automatik enligt förbestämda regler vi satt upp. Vi kan t.e.x testa huruvida uträkningar som görs är rätt o.s.v. Allt sker med hjälp av automatiska gränssnittstester som testar att allt ser ut som det ska.
- Om alla indikatorer visar grönt ljus paketeras koden och driftsätts i en testmiljö, givetvis automatiskt. Här kan sedan beställaren acceptanstesta i lugn och ro.
- Om beställaren är är nöjd gör vi en driftsättning och koden försvinner ut i produktionsmiljön.
Optimering
Lösning #7 — Optimera löpande
Går det för lång tid mellan releaser finns det ständigt en inbyggd risk i att man missar trender. Detta kan innebära att användarnas lojalitet börjar dala. Det är därför avgörande att vi kan visualisera mönster, identifiera trender och snabb koppla på en åtgärd som sjösätts med hjälp av fler mindre releaser. Det är godtagbart att upptäcka att intranätet aldrig blev socialt, men att inte göra något åt det vinner inga sympatier. Exempel på trender kan vara mobila besökare som ökar, besökare som vänder i dörren, ett sök som ingen använder eller en viktig funktion som inte konverterar. Det kanske även innebära att vi rationaliserar funktioner och innehåll som inte används.
I en undersökning gjord av Sales Force 2014 angav 98 % av marknadsförare att de kommer fortsätta att investera digitalt i med högst prio på analys och optimering.
Lösning #8— Visualisering
För att etablera ett mer proaktivt arbetssätt behöver vi visualisera data som snabbt kan omvandlas till åtgärder. För att möjliggöra detta behöver vi presentera insikter på ett sätt som alla kan ta till sig. Få kan motivera tid för att manuellt flytta siffror mellan system när chefen frågar hur det går.
Möjligheterna för uppföljning är idag oändliga. Det fullständigt kryllar av tjänster som visualiserar, optimerar och rapporterar på exakt den data som efterfrågas. Att möjliggöra realtidsdata till nyckeltagsägare leder snabbt till positiva kulturella skillnader i hur organisationer talar om sina lösningar.
Nu kan vi dessutom analysera hur väl varje release löste ett problem. De insikter vi samlar på oss blir sedan kvalificerad input till nästa release.
Ingen är född med egenskapen att veta exakt vad användaren vill ha, eller hur människor kommer att bete sig. Insikter är inlärda. Så undersök data och se vad användarna gör istället för att lita på det dom säger sig göra.
Vad vi lyckats åstadkomma
Med följande arbetssätt har vi skapat oss ett följsamt förhållningssätt för både organisationen och marknad helt i linje med vår vision, mål och möjligheter längs vägen. Vi blickar tillbaka på våra utmaningar och hur vi med ett uppdaterat arbetssätt nu löst dom:
1. Istället för en ojämn belastning i teamen får vi med en uppdaterad metod en mer jämn belastning över tid.
2. Vi utgår inte från magkänsla och gör fel saker, istället tar vi beslut baserat på inlärda insikter om användarna.
3. Tidigare missade vi trender pga. få större releaser, nu kan vi istället anpassa riktningen mellan fler releaser mot ett uppsatt rörligt mål.
4. Vi lovar inte saker till steg 2 som aldrig blir av, istället levererar vi löpande förbättringar och stannar always in beta.
Av: Fredrik Cederlöf, Head of Analytics & SEO, Creuna och Michel Radosavljevic, CTO Toborrow. Artikeln baseras på seminariet Always in Beta från maj 2014.
