Tips
Digital brief
Här har vi samlat våra bästa tips på vad du bör ha med i briefen för att projektet ska få rätt förutsättningar redan från start.
Arbetsmetoder
Vad är MVP - Minimum Viable Product?
Vi har ofta stått inför utmaningar i projekt där vi behövt förhållas oss till budget, tid och kvalitet. I de projekt där det passar jobbar vi enligt modellen eller tankesättet "MVP".
Det väcktes då en tanke att vi kan dela med oss av våra erfarenheter och försöka formulera det på ett enkelt och lättillgängligt sätt.
MVP - Minimum Viable Product i projektet
Du har en idé om en ny produkt. Det kan vara en webbplats, en applikation, funktion eller tjänst, som du tror kan addera värde i form av intäkter, effektivitet eller kundnöjdhet. Frågor du ställer dig inför uppstart av projektet handlar troligen om:
-
vilka funktioner bör jag ta med (scope)
-
hur snabbt kan vi vara klara (tid)
-
hur mycket kommer det kosta (resurser)
Stämmer det in på dig? I så fall kan MVP som projektinriktning vara ett smart alternativ.
MVP är en förkortning av Minimum Viable Product, vilket på svenska ungefär betyder “minsta livskraftiga produkt”. Det är en fungerande version av en ny lösning som ger användarna tillräcklig nytta från dag 1 när den lanseras, även om den inte är helt färdigbyggd.
Enkelt uttryckt så tar man kärnan i produkten, som man vet att den absolut inte kan fungera utan och bygger en testbar eller produktionsduglig produkt. Syftet att snabbt komma ut på marknaden, lära sig mer och fatta välgrundade beslut om hur den bör utvecklas för att addera ännu mera värde.
En tydlig fördel med en MVP är att du snabbt kan komma ut på marknaden och få feedback på lösningen du tagit fram. Eftersom det är en enkel, avskalad produkt med minst möjliga antal funktioner för att fungera, kan du vara säker på att du inte slösat med tid och budget. Flipp eller flopp? Du får svaret innan det är för sent att ändra inriktning.
MVP som inriktning fungerar också bra om man inte är helt säker på hur det man ska bygga ska se ut och fungera.
Utmärkande för en MVP är att den:
-
har initialt tillräckligt mycket värde för att användare ska vilja använda eller köpa den.
-
uppvisar kommande fördelar för att fortsätta behålla tidiga användaren.
-
skapar en feedback-loop som guidar teamet vidare med utvecklingen.
Genom att inte ta en för stor tugga av projektet undviker man att fastna på detaljer och kan istället snabbare fatta rätt beslut för att komma vidare.
En ytterligare fördel med MVP är att det blir enklare att byta spår om det visar sig att man har tänkt fel. Man skulle kunna säga att vi får chansen att vara efterkloka redan från början.
Användarna upplever det positiva i produkten - även om den är avskalad så har den precis de features som tillför något av nytta. De behöver inte vänta superlänge på en fullfjädrad produkt utan kan gilla och nyttja den löpande.
För att illustrera skillnaden mellan ett MVP-projekt och ett traditionellt projekt enligt vattenfallsmetoden kan man jämföra med att ta fram ett bakverk.
Det illustrationen visar är att kunderna/användarna inte ser något värde i sig att en välbyggd plattform finns på plats om den inte är paketerad och användbar. Bakverket känns fattigt om det bara finns en botten.
Användarna upplever däremot att produkten är en riktig produkt om den har de viktigaste funktionerna, användbarhet och utseende. Det fina är att de dessutom kan ge feedback och input på vad de vill att slutresutlatet ska bli.
När ska man arbeta med MVP?
Har du läst så här långt kanske du tänker “men varför arbetar man inte alltid så?”. Svaret är att det borde göras oftare, men MVP lämpar sig inte för alla typer av projekt. Det som är avgörande är mängden osäkerhet när man går in i projektet.
Om du vet vad du ska bygga, hur det ska byggas och har gjort liknande saker tidigare så kan en MVP vara direkt olämplig.
Då kan det vara bättre att återanvända och kombinera väl beprövade lösningar och lägga upp en mer detaljerad projektplan som fokuserar mer på effektivitet än flexibilitet.
Det kan handla om en webbplats med ett CMS som vi kan utan och innan, som ligger till grund i projektet. Vi vet ofta i stora drag vilket innehåll som ska presenteras och vi ska arbeta mot externa system som vi oftast inte kan ändra så mycket på inom ramarna för projektet. Vi har alltså förhållandevis låg grad av osäkerhet rörande den produkt vi ska bygga.
Om vi däremot har ett projekt där vi ska bygga en helt ny digital tjänst (kanske den första på sin marknad) med en lång önskelista med funktioner så skulle en MVP vara en utmärkt idé.
Dels behöver vi veta mer om vilka av alla funktioner som faktiskt är efterfrågade av användarna, dels har vi inte alla lösningar och gränssnitt klara för oss från början eftersom ingen har byggt något liknande tidigare.
MVP-projekt är per definition flexibla/agila vilket gör att vi tillsammans med dig kommer att vilja laborera med de tre projektdimensionerna scope, tid och resurser allt eftersom projektet fortlöper.
En effekt av att arbeta med en MVP är att det är omöjligt att på förhand leverera en spikad funktionsspecifikation till en fast tid och en fast kostnad. Du vet däremot att du kommer få en livskraftig produkt, på tid och inom budget - och ha pengar över att ta nästa steg.
Om du arbetat i ett agilt projekt tidigare så känner du igen dig eftersom detta är grundläggande i det agila arbetssättet. Tycker du att detta är läskigt eller vet att du måste ha en viss funktionalitet på plats vid ett visst datum så ska vi förmodligen titta på andra sätt att hantera osäkerhet i projektet.
Gissa och göra eller göra och testa?
Den första reaktionen när man hör talas om MVP är ofta: det känns osäkert, jag vet ju inte vad jag får. Det är ett väldigt kortsiktigt sätt att se på digitala projekt. Alternativet vore att gissa, göra gissningarna till sanningar och sedan basera resten av projektet på det utan att testa. Det går alldeles utmärkt att göra så, men du har ingen aning om användarna kommer att gilla och använda det du har byggt eller inte. Därmed har du heller ingen aning om du kommer att nå målen med projektet. Det - om något - är att inte veta vad du får.
Genom att vända på ordningen och göra innan vi kanske till 100 % vet att det är rätt, får vi snabbare in feedback, har möjlighet att styra om och förhoppningsvis generera värde betydligt snabbare än vad ett traditionellt projekt kan göra. Tricket ligger i att inte göra för mycket. Gör lite i taget, men se till att varje del tillför värde och nytta för användaren.
