Je MVP afbakenen zodat je hem echt afmaakt

Na deze gids heb je één A4 waarop staat wat je eerste versie wél doet, wat er expliciet níét in zit, en waarom. Je hebt je featurelijst omgezet naar vier bakken (Must, Should, Could, Won't), je Must-bak teruggesnoeid tot iets dat in weken te bouwen is in plaats van maanden, en je kunt tegen je team en je bouwer in één zin uitleggen wat de eerste versie oplost. Het resultaat is geen mooier plan — het is een kleiner plan dat af komt.

Wanneer je hier klaar voor bent

Je bent hier klaar voor als je deze drie dingen hebt liggen:

• Eén werkproces dat aantoonbaar pijn doet. Niet "onze administratie loopt rommelig", maar "van werkbon naar factuur duurt bij ons gemiddeld negen dagen en er vallen regels uit". Als je het proces niet kunt aanwijzen op een tijdlijn, sla deze gids over en ga eerst een week meekijken met degene die het werk doet.
• Minimaal drie mensen die het proces dagelijks uitvoeren. Je hebt ze nodig als toetssteen. Bouw je voor één persoon met een bijzondere werkwijze, dan bouw je een maatpak dat verder niemand past.
• Een lijst met features of wensen. Rommelig mag. Een mail, een notitieblok, een half Excel-bestand: prima. Zonder lijst is er niets af te bakenen.

Wat je níét nodig hebt: een technische keuze, een leverancier, een ontwerp, of een begroting. Die komen na deze gids en worden goedkoper naarmate je scope scherper is.

Twee aannames die ik hier maak, omdat ik jouw situatie niet ken. Eén: je hebt geen eigen ontwikkelteam in dienst en koopt de bouw in of doet het met één interne bouwer. Twee: je wilt binnen ongeveer zes tot tien weken iets in gebruik hebben. Wijkt dat sterk af, dan blijven de stappen gelijk maar schuiven de getallen mee.

1. Schrijf het proces op als tijdlijn, niet als featurelijst

Handeling: neem één A4 en schrijf de stappen op van het proces zoals het vandaag gaat, van eerste handeling tot afgerond. Per stap: wie doet het, waarin (welk systeem, papier, appje), hoe lang duurt het, en hoe vaak gaat het mis. Vraag het aan de mensen die het doen; schrijf niet op hoe het hóórt te gaan.

Voorbeeld met getallen. Een installatiebedrijf met twaalf monteurs schreef op: monteur vult papieren werkbon in (5 min, 40× per week), bon gaat in de bus van de bus, komt gemiddeld na 3 dagen op kantoor, administratie typt hem over in het factuurpakket (7 min per bon), 1 op de 6 bonnen is onleesbaar of mist uren en gaat terug naar de monteur (kost gemiddeld 2 dagen extra), factuur gaat na gemiddeld 9 dagen de deur uit. Onderaan de tijdlijn stond de optelsom: 40 bonnen × 7 minuten = 4,7 uur overtypen per week, plus ongeveer 7 bonnen per week die heen en weer gaan.

Klaar wanneer: je tijdlijn heeft maximaal twaalf stappen, bij elke stap staat een getal (minuten, frequentie of foutkans), en twee mensen die het werk doen hebben hem gelezen en gezegd: zo gaat het inderdaad.

2. Wijs de duurste stap aan en maak die je kern

Handeling: reken per stap uit wat hij jaarlijks kost in uren of in vertraging. Zet ze op volgorde. De bovenste stap is je kern — daar gaat je eerste versie over. Schrijf één zin op: "De eerste versie zorgt dat [rol] [handeling] doet zonder [de dure stap]."

Voorbeeld met getallen. Bij dat installatiebedrijf was overtypen 4,7 uur per week × 46 weken = ruim 215 uur per jaar. De heen-en-weer-bonnen kostten minder uren maar veel meer doorlooptijd. De kernzin werd: "De eerste versie zorgt dat de monteur de werkbon op zijn telefoon afsluit en dat daar direct een conceptfactuurregel uit rolt." Alles wat daar niet aan bijdraagt — voorraadbeheer, planning, urenregistratie voor de loonstrook — viel daarmee automatisch buiten de kern.

Klaar wanneer: je hebt één zin van maximaal twintig woorden, met één rol en één handeling erin. Kun je de zin niet schrijven zonder "en" te gebruiken, dan heb je twee projecten. Kies er één.

3. Verdeel je featurelijst over vier bakken

Handeling: schrijf elke feature op een aparte regel en geef hem één letter volgens MoSCoW. Must = zonder dit werkt de kernzin niet, punt. Should = belangrijk, maar het proces loopt er een paar weken zonder. Could = leuk, pak het op als er tijd over is. Won't = expliciet niet in deze versie, met een datum of voorwaarde erbij wanneer je het opnieuw bekijkt.

De test voor Must is hard: haal de feature weg en vraag "kan de monteur zijn bon dan nog afsluiten en rolt er nog een factuurregel uit?". Is het antwoord ja, dan is het geen Must. Ook niet als iemand het heel graag wil.

Voorbeeld met getallen. Van 31 wensen op de lijst bleven er 7 over als Must: inloggen met een pincode, klant en werkadres kiezen, uren en materialen invoeren, foto toevoegen, handtekening van de klant, bon afsluiten, conceptregel in het factuurpakket. Should werd 9 items (offerte-koppeling, bon terugsturen bij afkeur, dagoverzicht per monteur). Could werd 11. Won't werd 4, waaronder "monteurs onderling laten ruilen van klus" met de notitie: opnieuw bekijken na drie maanden gebruik.

Klaar wanneer: je Must-bak heeft maximaal tien regels, en in je Won't-bak staat minimaal één ding waar iemand in de organisatie enthousiast over was. Staat er niets pijnlijks in Won't, dan heb je niet afgebakend maar alleen gesorteerd.

4. Prik de Must-bak door op tijd

Handeling: zet achter elke Must een ruwe schatting in dagen bouwwerk. Doe dit samen met degene die gaat bouwen; schat in hele dagen, niet in uren. Tel op en vermenigvuldig met 1,6 — voor testen, aanpassingen na het eerste gebruik, en de dingen die je nu niet ziet. Komt het totaal boven je termijn, dan gaat er iets van Must naar Should. Niet "we werken harder".

Voorbeeld met getallen. De 7 Musts kwamen op 19 dagen bouwwerk. × 1,6 = ruim 30 dagen, oftewel zes tot zeven weken bij één bouwer. Dat paste net. Was het 45 dagen geworden, dan was "foto toevoegen" (3 dagen) en "handtekening van de klant" (4 dagen) naar Should gegaan — vervelend, maar het proces loopt er zonder.

Klaar wanneer: het totaal na de × 1,6 past binnen je termijn, en je kunt per verschoven feature benoemen wat er in de tussentijd gebeurt. "Handtekening doen we tot versie 2 nog op papier" is een antwoord. "Dat zien we dan wel" niet.

5. Kies de randen: wat raakt de eerste versie niet aan

Handeling: schrijf expliciet op met welke systemen de eerste versie wél en niet praat. Koppelingen zijn de grootste verborgen kostenpost. Kies per systeem: volledige koppeling, exportbestand, of handmatig overnemen. Bij twijfel kies je exportbestand — dat kost dagen in plaats van weken en is later te vervangen.

Voorbeeld met getallen. Volledige koppeling met het boekhoudpakket werd geschat op 8 dagen plus onzekerheid over de documentatie. Een dagelijks exportbestand dat de administratie inleest: 1,5 dag. Dat scheelde ruim zes dagen en de administratie kreeg alsnog 4,7 uur per week terug, want overtypen was het probleem, niet het inlezen.

Klaar wanneer: per aangrenzend systeem staat er één woord: koppeling, export of handmatig. En je weet wie de handmatige stap doet en hoe lang die duurt.

6. Zet er een meetpunt onder

Handeling: schrijf op wat je acht weken na livegang meet, met het getal van vandaag ernaast. Eén hoofdgetal, hooguit twee bijgetallen. Meet het nulpunt nú, voordat je bouwt — achteraf schat iedereen te rooskleurig.

Voorbeeld met getallen. Hoofdgetal: doorlooptijd bon-naar-factuur, nu 9 dagen, doel onder de 2. Bijgetal: overtypuren per week, nu 4,7, doel onder de 1. Bijgetal: bonnen die terugmoeten, nu 7 per week, doel onder de 2.

Klaar wanneer: de drie getallen staan op je A4 met de datum van meting erbij, en ze komen uit iets wat je kunt navragen — niet uit een gevoel.

7. Leg het vast op één A4 en laat het tegenspreken

Handeling: zet op één pagina: de kernzin, de Must-lijst met dagen, de Won't-lijst met reden, de systeemkeuzes en de drie meetgetallen. Laat het lezen door iemand die het werk doet en door iemand die het betaalt. Vraag beiden: wat mis je, en accepteer je dat de Won't-lijst er echt niet in zit?

Klaar wanneer: beide mensen hebben ja gezegd op de Won't-lijst. Een "ja, maar dat kan er vast nog wel bij" is een nee — dan ga je terug naar stap 3.

Veelgemaakte fouten

Alles is een Must. Als alles moet, is niets afgebakend en schuift de opleverdatum vanzelf. Vuistregel: maximaal tien Musts, en minstens een kwart van je oorspronkelijke lijst hoort in Could of Won't te landen.

De uitzondering meebouwen. "Ja, maar bij die ene klant gaat het anders." Als die situatie minder dan 15% van de gevallen is, laat je hem in de eerste versie handmatig. Uitzonderingen kosten vaak meer bouwtijd dan de hoofdstroom.

Beginnen bij het scherm dat de directie ziet. Dashboards en rapportages voelen als het product, maar ze leveren pas waarde als er data in zit. Bouw eerst wat de data maakt.

Scope ruilen zonder iets weg te halen. Er komt altijd een wens bij tijdens het bouwen. Regel: erin mag, maar dan gaat er iets van gelijke omvang uit. Schrijf die ruil op, anders verdwijnt hij in de mist.

Bouwen voor de hele organisatie tegelijk. Begin met één ploeg, één vestiging of één type klus. Twaalf monteurs tegelijk laten overstappen op een versie die nog schuurt, kost je het vertrouwen dat je later nodig hebt.

Geen nulmeting. Zonder het getal van vandaag kun je over acht weken niet aantonen dat het werkt, en wordt de discussie een smaakkwestie.

Wat je hierna doet

Plan binnen een week een sessie van een uur met de mensen uit stap 1 en loop de Must-lijst scherm voor scherm langs: wat zien ze, wat typen ze, wat gebeurt er als het misgaat. Dat levert meestal nog twee of drie regels op die van Must naar Should verhuizen.

Zoek daarna één ploeg of vestiging die de eerste versie gaat gebruiken zodra hij er is, en zet de startdatum in de agenda vóór de bouw begint. Een vaste gebruikersgroep met een datum is het enige wat scope-uitbreiding echt tegenhoudt.

Houd tot slot een ruillijst bij naast je A4: elke wens die tijdens de bouw binnenkomt, met datum en wie hem inbracht. Die lijst is je versie 2 — en hij is na acht weken gebruik een stuk waardevoller dan wat je er vandaag over zou bedenken, omdat er dan echte getallen onder staan.

Doe dit voor jouw eigen idee. De scanner voert deze stap uit op jouw probleem: score op zes dimensies, alternatieven, risico's en de experimenten die je als eerste moet doen. Start de gratis probleemanalyse