I denna del av rapporten presenteras tre olika MVP:er och gruppens MVP. Även gruppens utvecklingsprocess och hur kunden använde gruppens MVP tas upp.
A.5.1
Verkliga MVP:er
I detta avsnitt presenteras tre olika MVP:er gjorda av tre olika företag av varierande storlek, MVP:erna som företagen gjorde och en beskrivning av respektive företags historia och tjänst ges även.
Groupon Groupon är en amerikansk e-handelsplattform verkande i 15 länder världen över.
Groupon sammanfogar köpare med lokala säljare genom att erbjuda aktiviteter, resor, gods och tjänster. Groupon ståtar med att vara den mest nedladdade appen både på iOS och
Android med över 171 miljoner nedladdningar. Idén bakom Groupon är kort och gott att man som användare varje dag får en rekommendation på t.ex. en restaurang eller affär i sin närhet. Samtidigt som användaren får denna rekommendation erbjuds denne även en rabatt i from av en elektronisk kupong. [37]
MVP:n bakom Groupon var att genom att omdesigna en färdig mall skapa en hemsida för att sedan, varje dag, skriva ett nytt inlägg om ett erbjudande. Det enda de sålde på denna MVP-version av Groupon var T-shirts. I ett inlägg kunde det exempelvis stå ”This T-shirt will come in the color red, size large. If you want a different color or size, e-mail that to us”. Denna tidiga version av Groupon var nog för grundarna att se potentialen i sin tjänst. [36]
Dropbox Dropbox möjliggör för sina användare att spara filer över internet. De är ett fö-
retag som tillhandahåller en molntjänst tillsammans med en klientmjukvara. De grundades 2007 och har sitt huvudkontor i San Francisco. Det som skiljer Dropbox från en renodlad molntjänst är att Dropbox skapar en speciell mapp på användarens dator där denne kan spa- ra filer precis som vanligt. Skillnaden att alla filer som sparas i den speciella Dropbox-mappen automatiskt synkroniseras med användarens online-konto och andra enheter.[38]
Ries skriver i sin bok att Dropbox i början hade framstående riskkapitalinvesterare och kunde ha implementerat det, enligt honom, vanliga sättet att bygga en produkt, nämligen att bygga en helt färdig produkt och låta användarna strömma in. Grundarna hade dock tänkt sig något annat, de ville samla in feedback samtidigt som produkten höll på att utvecklas. De ville veta vad som verkligen var viktigt för kunderna. De fick dock snabbt reda på att syn- kronisering var ett problem som många inte visste att de hade. De upplevde även att många hade svårt att förstå Dropbox-konceptet när det väl förklarades. Även Dropbox utvecklade en MVP, men i och med den tekniska svårigheten att utveckla tjänsten hade de ingen version av tjänsten som de kunde använda som MVP. MVP:n var kort och gott en informativ video på tre minuter som demonstrerade hur det var tänkt att tjänsten skulle fungera. Videon ökade antal påskrifter i medlemslistan till beta-versionen av tjänsten från 5000 till 75000 stycken. [36]
Food on the Table Food on the Table försåg sina användare med recept, rabatterade varor
och inköpslistor baserade på preferenser som användarna matade in i tjänsten. Dessa prefe- renser kunde röra sig om t.ex. önskade ingredienser, favoritaffär eller budget. Tjänsten be- stod av en webbsida och en mobilapplikation. Food on the Table köptes av det amerikanska livstilsnätvärket Food Network i april 2014 [39]. Food Network kallar sig själva ett livsstils- nätverk och i detta ingår bland annat en hemsida, en tidskrift och en tv-kanal. Tv-kanalen distribueras till närmare 100 miljoner amerikanska hushåll och hemsidan har över 46 miljo- ner unika besökare i månaden [40].
Åter till Food on the Table, som även de, gjorde en MVP. I detta fall hade de varken en tidig version av tjänsten eller en informativ video. Denna MVP löste endast en kunds problem. Manuel Rosso, grundaren av Food on the Table gick tillsammans med VP:n Steve Sanderson till lokala mataffärer och grupper för mammor. På dessa ställen intervjuade de människor och berättade om sin tjänst och vid slutet av varje intervju försökte de sälja in sin tjänst till personen som intervjuades. Efter ett antal intervjuer lyckades de få sin första kund. MVP:n i detta fall blev att Rosso och Sanderson för hand gjorde det som hemsidan i framtiden skulle göra. De träffade kunden personligen en gång i veckan för att leverera ett recept baserat på kundens preferenser i utbyte mot en check. Efter ett tag ackumulerade de ett antal kunder och märkte snabbt att manuell betjäning inte var hållbart och de började då arbeta för att implementera hemsidan och mobilapplikationen som skulle automatisera detta. [36]
A.5.2
Optilys MVP
Optily är ett optimeringsverktyg skapat av projektgruppen i kursen TDDD96 - kandidatarbe- te i programvaruutveckling åt kunden Ionbond Sweden AB. Syftet med Optily är att hjälpa
A.5. Resultat
till att effektivisera Ionbonds verksamhet. Mer specifikt ämnar Optily lösa det optimerings- problem som fanns då uppdraget gavs. Ionbond ytbelägger objekt av olika slag. Dessa måste placeras i en kammare och problemet som Ionbond upplevde var att de ej alltid kunde maxi- mera nyttjandet av kammarens volym. Det är just detta problem som Optily löser, nämligen att försöka maximera utnyttjandet av plats i denna kammare. Optily är alltså ett datorpro- gram där användaren, efter att ha kopplat ihop Optily med en databas av verktyg kan söka och lägga till olika objekt som ska beläggas och lägga till dem i en lista. Optily placerar se- dan ut objekten virtuellt på ett så effektivt sätt som möjligt. Användaren får sedan en visuell representation av hur objekten ska placeras i beläggningskammaren.
Projektgruppen levererade sin första version av Optily till kund 2018-04-11. Projektgrup- pen besökte Ionbond på deras kontor och med sig hade de ett par användartester som skulle utföras i Optily. Vid demonstrationstillfället hade gruppen använt ungefär tre veckor till att utveckla Optily. Detta gjordes i enlighet med kravspecifikationen som gruppen och Ionbond gemensamt tog fram. Denna leverans kan ses som en MVP av Optily. Denna version av Op- tily var relativt nära slutversionen. Det fattades en del funktioner som kunden hade önskat, men programmet gick att använda och uppfyllde majoriteten av kundens behov. Största skill- naden mellan denna version av Optily och slutversionen var att denna inte tillät kunden att helt släppa sitt gamla arbetssätt eftersom all nödvändig information inte visades i program- met än. Detta ledde till att användaren, för att kunna utföra sitt jobb, var tvungen att ha två program öppna samtidigt istället för endast Optily. Innan leveransen, i ett mycket tidigare skede, presenterade gruppen för Ionbond en skiss på hur programmet skulle se ut. Denna skiss innehöll de tänkta vyerna i programmet samt de olika knapparna och hur dessa skulle hänga ihop. Skissen gjordes med penna och papper och användes sedan som underlag för att påbörja utvecklingen. Denna skiss kan ses som den första MVP-versionen av Optily.
Figur A.1: Första skissen av Optily
Figur A.1 visar fliken Produkter. På denna flik finns tre textfält en knapp och en lista. Textfälten används för att fylla i information om ordern och knappen används sedan för att
lägga till den i listan. Den vänstra sidan av programmet visar de tre flikar som gruppen hade tänkt sig skulle finnas samt en knapp för att sätta igång optimeringen.
A.5.3
Utvecklingsprocessen
Under utvecklingsfasen försökte projektgruppen efter bästa förmåga förhålla sig till arbets- metodiken känd som Scrum. Här kommer det endast att ges en kompakt version om hur Scrum fungerar och hur projektgruppen valde att följa Scrum. Detaljerad information om detta går att hitta i avsnittet 3.5 respektive 4.2.4 i den gemensamma rapporten.
När man arbetar efter Scrum delar man in utvecklingstiden i tidsperioder som kallas för sprintar. I detta projekt valde gruppen att sprintarna skulle vara sju dagar med start på en måndag och slut på måndagen därefter. Vid början av varje sprint hade gruppen ett möte där förra sprinten utvärderades och nästa sprint planerades. Vid planeringen av varje sprint valdes de uppgifter som skulle göras under sprinten ut och listades. På detta sätt arbetade gruppen under hela utvecklingsfasen. Gruppen hade även som mål att en fungerande ver- sion av Optily skulle tillhandahållas efter varje sprint. Däremot fanns inga krav på att alla delar av Optily skulle finnas efter varje sprint, men att det ändå skulle vara en relativt kom- plett produkt. Denna produkt byggdes sedan på efter varje sprint för att iterativt närma sig slutprodukten.
Valet att använda Scrum gjordes innan gruppen bestämde sig för att utveckla en MVP. På grund av att gruppen ville skapa en MVP var målet att en sådan skulle finnas efter var- je sprint. Detta åstadkoms, men det var inte förrän efter den tredje sprinten som gruppen valde att visa kunden sina resultat. Det är därför den versionen kom att bli en av gruppens MVP:we. Även fast någorlunda fungerande versioner fanns efter varje sprint visades dessa inte för kund. Gruppen kunde således inte dra några lärdomar ur kundkontakt för dessa ver- sioner i och med att ingen återkoppling gavs. Enligt Ries är ju detta tanken, eftersom de var fungerande och därmed tillräckliga för att kunna lära sig av [36].
Arbetet under utvecklingsfasen var uppdelat och varje gruppmedlem utvecklade på sin del av programmet för att sedan, i slutet av varje sprint, gå ihop med de andra och försöka knyta samman varje del. Det skedde en del överlappning då gruppmedlemmar arbetade på flera olika aspekter av programmet, men för det mesta var arbetsuppgifterna uppdelade på så sätt att varje gruppmedlem huvudsakligen höll sig till ett område. Detta betydde att gruppen t.ex. hade en gruppmedlem fokuserande på optimeringsproblemet medan en annan arbetade med det grafiska gränssnittet och en tredje med databasen osv.
A.5.4
Kundens användande av gruppens MVP
Gruppen hade i början av utvecklingsfasen med sig till kund en skiss av hur det var tänkt att Optily skulle se ut och fungera. Detta var inget som kunden direkt kunde använda sig av, men projektgruppen fick utifrån denna skiss klartecken från kunden att sätta igång och arbe- ta. Skissen användes således som en tidig målbild för gruppen i deras utvecklingsarbete. Då gruppen hade slutfört tre sprintar levererades som tidigare nämnts en tidig version av Op- tily. Denna version av Optily hade de nödvändiga funktionerna som kunden behövde för att kunna börja använda och testa programmet vilket kunden också gjorde. Under tiden kunden använde denna version av Optily skickades återkoppling från kunden med förbättringsför- slag. Detta ledde till att gruppen kunde börja prioritera uppgifter efter kundens återkoppling.