Het doel van een eerste versie is niet om alle ideeën tegelijk te realiseren, maar om een werkend antwoord te bieden op een echte behoefte. De MVP-aanpak (minimum viable product, oftewel een minimaal levensvatbaar product) is erop gericht dit antwoord sneller bij de gebruiker te brengen. Een kleine scope hoeft geen halfafgewerkte ervaring te betekenen.
01Kies eerst één resultaat
Bij bedrijfssoftware kan het eerste doel zijn: een offerte opstellen, een afspraak boeken of een voorraadbeweging volgen. Beschrijf het volledige pad dat de gebruiker van start tot resultaat moet afleggen. Behoud de kritieke stappen van dit pad in de eerste versie. Extra rapporten en verdere personalisatie kunnen wachten; maar als de gebruiker zijn kerntaak niet kan afronden, is de scope van de eerste versie verkeerd afgebakend.
02Houd wat u uit de scope haalt zichtbaar
Een uitgestelde functie is geen vergeten functie. Door verzoeken die buiten de eerste versie vallen met hun onderbouwing vast te leggen, weten belanghebbenden waar ze aan toe zijn. Starten met slechts één betaalmethode kan bijvoorbeeld een bewuste keuze zijn. Maar het uitleggen aan de gebruiker wanneer een betaling mislukt, hoort wél bij een werkende oplevering van die methode. Dit is precies het verschil tussen de scope verkleinen en het werk onvolledig laten.
Om de scope en uitgestelde onderdelen op papier te zetten, kunt u onze specificatiepagina gebruiken. De algemene planningsstappen hebben we beschreven in ons artikel over het plannen van een maatwerksoftwareproject.
03Verzamel feedback op een manier die tot beslissingen leidt
In plaats van gebruikers alleen te vragen of ze iets goed vinden, onderzoekt u waar ze een taak hebben afgebroken en wat ze niet begrepen. Een te lang formulier kan een probleem zijn, maar net zo goed het niet uitleggen waarom een veld wordt gevraagd. Beoordeel de relatie met het kerndoel voordat u feedback omzet in een lijst nieuwe functies. Zo wordt de volgende versie gevormd door waargenomen behoeften, niet door het luidst geuite verzoek.
04Zet het brede team gericht in
Het brede team van Paradigma7, met ontwikkelaars uit verschillende regio's, maakt het mogelijk om onafhankelijke ontwikkel- en testwerkzaamheden parallel te laten verlopen. We gebruiken deze capaciteit niet om overbodige functies aan de eerste versie toe te voegen, maar om de gekozen scope sneller af te ronden. De planning wordt pas bepaald nadat scope, gereedheid en de beschikbaarheid van externe systemen samen zijn beoordeeld. Bij onze SaaS-ontwikkeling plannen we eerste versies volgens deze aanpak.
05Korte checklist
- Is het ene resultaat dat de eerste versie de gebruiker moet bieden vastgelegd?
- Werkt elke stap op de weg naar dat resultaat?
- Zijn uitgestelde verzoeken met hun onderbouwing vastgelegd?
- Wordt aan de gebruiker uitgelegd wat er gebeurt bij een mislukte handeling?
- Is duidelijk hoe feedback verzameld wordt en wie deze beoordeelt?
Geschreven door
Het Paradigma7-team
Product, engineering en operations
We zijn een op Ankara gebaseerd team dat software voor Europa bouwt. Niets hier is theorie: dit zijn de processen die we werkelijk op klantprojecten uitvoeren.
Over ons