Det finns spaltkilometrar med artiklar att läsa om Minimum Viable Product (MVP) inom systemutveckling. Alltså kärnan av de mest nödvändiga funktioner i en produkt/tjänst och som tillför värde. Oftast handlar MVP om produkter/tjänster som ska lanseras till kunder på marknaden, när de ska lanseras internt inom en organisation fungerar det lite annorlunda.
Som produktägare har du diskuterat med ditt team om en idé på tjänst fram till lösning inom din organisation. Alla i teamet (lösningsarkitekten, utvecklarna och testledaren tillsammans med projektledaren) verkar ha likadan bild av vad som ska göras. Tillsammans tar ni fram ett antal användningsfall (scenarios). En UX designer tar fram prototyper och pratar med olika användare. Olika mätningar och uppskattningar tyder på att konceptet håller och att det är värt att bygga tjänsten. Du och teamet vill släppa en första liten och avskalad version.
Syftet är att snabbt kunna komma ut på marknaden för att hitta testkunder, sälja in ditt erbjudande och ta in feedback. Utifrån den kan du skruva på ditt erbjudande eller din produkt och göra om proceduren. Att samla in insikter från en MVP blir oftast billigare än att utveckla en produkt med många funktioner. På så sätt går det att minimera risken att bygga något stort och fel, som annars kan bli mycket kostsamt.
Inte ovanligt brukar olika delar av verksamheten komma med ännu fler önskemål. Och vill kanske helt ändra det ni var överens om med hänvisning till att de inte vill förändra sitt sätt att arbeta.
Vad gör du i ett sådant läge? Det finns bara ett sätt: Involvera ledningen att fatta beslut. Flera med mig har stått här och upplevt denna situation.
När tjänster ska lanseras internt i en organisation gäller andra förutsättningar. Exempelvis krävs en ledning som tydligt visar behovet av förändring och hur organisationen ska nå dit. Av någon anledning är det ganska vanligt att starta IT-projekt trots att det är förändringsledning som behövs. Om flera avdelningar arbetar i samma process på olika sätt så blir det svårt att ta fram lösningar som passar hela verksamheten.
I exemplet ovan går det redan att ana att den MVP du och ditt team var överens om håller på att byggas sönder. Inte nog med att det är svårt att ta fram en MVP, det är också svårt att stå fast vid den. Ganska många artiklar handlar om MVPs som byggs sönder, här är en som skrivits av Allan Kelly, som uttrycker skepsis till att använda begreppet MVP överhuvudtaget:
> The MVP is broken: It’s time to restore the minimum viable product
Tips! För dig som vill veta mer vad som är bra att tänka på för att ta fram en MVP, rekommenderar jag denna artikel som skrivits av Martin Christensen:
> En guide till minimum viable products
Björn Rutholm delar med sig flera bra tips att tänka på vid tjänstedesign. Han nämnder några olika metoder att använda när det har har gått överstyr och blivit rörigt. Exempelvis dela på en komplicerad produkt till flera tjänster. MVPn går alltså att rädda!
> Så lyckas du med din tjänstedesign
Vad är din upplevelse av MVP i systemutveckling? Vore kul att veta.
Författare: Helén Alseby, agil produktägare samt krav- och verksamhetsanalytiker
Tyckte du om denna artikel? Dela gärna! > Läs fler artiklar
Vill du ställa en fråga eller tipsa om något du vill läsa om? > Välkommen att höra av dig