MVP – wat is het nu eigenlijk
Vraag je je wel eens af waar de term MVP voor gebruikt wordt?
Als we het over software hebben wordt de term MVP op verschillende manieren gebruikt. Van een schets op een A4-tje tot een volledige project scope en alles daar tussenin. In het eerste geval gaat het om een discussiestuk, waarbij slechts globaal wordt aangegeven wat het zou moeten worden. In het 2e geval heeft het de vorm van een klassiek (waterval) project gebruikt, waarbij de scope vooraf bepaald is en aanpassingen apart onderhandeld moeten worden.
Er zijn dus veel verschillende meningen over wat de term MVP inhoudt en je kunt je dus ook de verwarring voorstellen.
Waar iedereen het wel over eens is, is dat de afkorting staat voor Minimum Viable Product. Dus laten we dat als uitgangspunt nemen.
Een definitie
De oorspronkelijk definitie gaat uit van een eerste versie van een werkend product dat voorziet in het oplossen van de primaire uitdaging van de gebruiker. Het doel hiervan is om feedback op te halen bij gebruikers dat als input dient voor verdere ontwikkeling. Omdat de software in deze fase weinig functionaliteit bevat, kun je het snel bouwen. Vervolgens kun je je aannames testen tegenover echte gebruikers en hun werkelijke gebruik van je applicatie.
Een voorbeeld
Een simpel voorbeeld: als je postcodes vast wil leggen in je applicatie, kun je in je eerste versie een postcodeveld maken met
- Een check of het in het juiste formaat is (1234 AB)
- Een check of er inderdaad een spatie zit tussen de cijfers en letters
- Functionaliteit om zelf de spatie ertussen te zetten
- Check of de postcode wel bestaat (via een link naar een postcodetabel)
- Check of de postcode wel klopt met de straatnaam en stad
Aan de andere kant kun je in je MVP een veld maken met het label postcode ervoor en de volgende punten controleren:
- Hoe vaak vullen mensen hun postcode verkeerd in?
- Wat gebeurt er als de postcode niet volgens het vastgestelde formaat ingevuld wordt?
- Hebben we echt alleen maar Nederlandse klanten en dus alleen Nederlandse postcodes?
- Wat is het risico als de postcode tabel niet bijgewerkt is met nieuwe postcodes?
Door geen aannames te doen, maar echt onderzoek te doen naar daadwerkelijk gebruik kom je er wellicht achter, dat je minder functionaliteit hoeft in te bouwen en daardoor veel goedkoper kan bouwen. Of meer kan bouwen omdat de ontwikkelaars veel korter bezig zijn met deze functionaliteit.
Meer waarde met minder functionaliteit
Te vaak zien we dat organisaties en teams te veel willen automatiseren, terwijl dat helemaal niet nodig is. Door een applicatie te bouwen met voldoende functionaliteit om bruikbaar te zijn, leveren we sneller waarde aan de klant en kunnen we sneller bepalen hoe we meer waarde aan de klant kunnen leveren. Zolang functionaliteit niet gebruikt wordt door klanten, heeft het geen waarde. Niet voor de klant, die het niet gebruikt, maar ook niet voor de leverancier, die geen feedback en daardoor nieuwe inzichten krijgt.
Ik ga niet vertellen welke definitie DE definitie is voor MVP, maar ik neig wel meer naar de versie waar we nog kunnen leren, dan eentje die van tevoren vastligt voor een langere periode.
Welke definitie wordt gebruikt in jouw organisatie? En wordt die echt door iedereen op die manier gebruikt?
Als je meer over het bepalen van een MVP wilt weten, neem dan contact met ons op.
Alex Roos, DevOps Consultant