01
Een aanname in een plan is een belofte
Ze klinkt als een feit omdat ze in een document staat. Dat verandert niets aan haar status.
OneDayBuild, het bouwdagmerk van Appfront
Aanname over haalbaarheid of eerst een dag bouwen?
Elk plan voor een app begint met een aanname over haalbaarheid: dat het model onze documenten aankan, dat de koppeling met het oude systeem lukt, dat gebruikers het snappen. Op die aanname wordt een traject begroot en gestart. Blijkt hij niet te kloppen, dan blijkt dat halverwege. Een bouwdag toetst de aanname eerst, in één dag, voordat er een traject op wordt gebouwd.
- Eén werkdag
- Werkend prototype
- Code in je eigen repository
01/06
Waar de twee routes uit elkaar lopen
Een plan kan een aanname niet toetsen. Een prototype kan niets anders.
Een projectplan voor een app bevat altijd een zin die begint met 'we gaan ervan uit dat'. Dat het model de scans van onze facturen goed leest. Dat het zaaksysteem een bruikbaar koppelvlak heeft. Dat medewerkers een telefoon willen gebruiken op de werkvloer. Die zin is het fundament van de begroting, en niemand heeft hem gecontroleerd, omdat dat pas kan als er iets is gebouwd.
Zo ontstaat de klem. Het traject wordt begroot alsof de aanname klopt. Wordt hij halverwege onderuitgehaald, dan is het geld voor de helft op en is de keuze: doorgaan met een slechtere oplossing, of stoppen met een half product. Beide waren te voorkomen door de aanname als eerste te toetsen in plaats van als laatste.
Een bouwdag doet precies dat. Niet het hele product, maar het ene deel dat de aanname draagt: het model op honderd echte scans, de koppeling op een echte export, het scherm bij drie echte gebruikers. Aan het eind van de dag is de aanname een meting. Klopt hij, dan begint het traject op vaste grond. Klopt hij niet, dan is dat na één dag bekend, met de reden erbij, en vaak met een alternatief.
02
De duurste aanname staat vooraan
Meestal is het er één: het model, de koppeling of de gebruiker. Die bepaalt of het traject klein of groot wordt.
03
Toetsen kan alleen door te bouwen
Een onderzoek of een offerte van een leverancier toetst niets. Een werkend deel op jullie gegevens wel.
04
Een nee is ook een uitkomst
Een aanname die niet klopt, is na één dag goedkoper dan na een half traject. Dat is de hele reden.
02/06
Wat valt binnen en buiten de bouwdag
Binnen scope
- De ene aanname waar het plan op rust, gebouwd en gemeten op jullie eigen gegevens.
- De uitkomst als cijfer waar dat kan: hoeveel scans goed, hoeveel velden gevuld, hoeveel gebruikers door de flow.
- Een eerlijke lijst met wat de meting wel en niet zegt over de rest van het plan.
- Een live URL en de code in je eigen repository.
Buiten scope
- Het projectplan en de begroting zelf; die pas je aan op wat de dag oplevert.
- De overige aannames, tenzij ze in dezelfde dag passen; meestal is er één die telt.
- Onderzoek naar prestaties op grote volumes of beveiliging; dat vraagt een ander traject.
- Het traject zelf, bij welke bouwer dan ook.
03/06
Hoe de bouwdag verloopt
- Stap 1
De aannames op een rij
Elke zin uit het plan die begint met 'we gaan ervan uit'. Meestal zijn het er drie tot vijf.
- Stap 2
De duurste kiezen
Welke aanname maakt, als hij niet klopt, het traject twee keer zo groot of zinloos.
- Stap 3
De toets ontwerpen
Wat moet er werken, op welke gegevens, en wat is de meetlat voor 'klopt'.
- Stap 4
Bouwen
Alleen het deel dat de aanname draagt, op jullie eigen gegevens.
- Stap 5
Meten
Het cijfer, en de gevallen waarin het misging, met de reden erbij.
- Stap 6
Opleveren
Live URL, code in je eigen repository en de meting als bijlage bij het plan.
Volgende stap
Staat je plan op een aanname die niemand heeft getoetst?
Stuur ons het plan of de opzet, dan wijzen we de zin aan die het traject draagt. In een korte intake bepalen we of die in één dag te toetsen is en wat de meetlat moet zijn.
04/06
Eerlijk over deze vergelijking
- Niet elke aanname hoeft getoetst. Als iets al tien keer elders is gebouwd, is het geen aanname meer. Toets wat specifiek is voor jullie gegevens, jullie systemen of jullie mensen.
- Een toets op een steekproef is geen garantie. Honderd scans zeggen veel, niet alles. De dag levert een cijfer met een spreiding, geen zekerheid. Dat is nog altijd meer dan een zin in een plan.
- Soms is de aanname te groot voor een dag. Prestaties bij duizend gelijktijdige gebruikers of de beveiliging van een architectuur toets je niet in een dag. Dan zeggen we dat, en past een ander traject.
- Een 'ja, mits' is de meest voorkomende uitkomst. Het werkt, maar alleen als de scans scherper zijn, als het koppelvlak wordt opengezet, als de gebruiker een grotere knop krijgt. Die 'mits' hoort in het plan, en dat is winst.
05/06
Twee manieren om verder te gaan
De bouwdag maakt je idee aantoonbaar. Wil je daarna doorbouwen naar een volwaardige applicatie, dan doet Appfront dat traject.
Eén bouwdag, OneDayBuild
- Je plan rust op één aanname en je wilt die getoetst hebben voordat het traject start.
- Aan het eind van de dag is de aanname een meting op jullie eigen gegevens.
- Één dag, vaste prijs, code in je eigen repository.
Volledig traject, Appfront
- De aanname klopt en je wilt het traject starten op wat er nu al werkt.
- De overige onderdelen, koppelingen, beveiliging, beheer en de uitrol.
- Een traject bij Appfront, met beheer en doorontwikkeling.
06/06
Veelgestelde vragen
Hoe weet ik welke aanname ik moet toetsen?
Kijk welke zin in het plan, als hij niet klopt, het traject twee keer zo groot maakt of zinloos. Meestal is het er één: het model op jullie gegevens, de koppeling met een bestaand systeem, of de gebruiker. Die ene is de bouwdag waard; de rest kan in het traject.
Is een offerte van een leverancier geen toets?
Nee. Een leverancier die zegt dat zijn model jullie documenten aankan, doet een belofte, geen meting. De toets is het model op honderd van jullie scans laten draaien en tellen. Dat kan in een dag, en de uitkomst is van jullie, niet van de leverancier.
Wat als de aanname niet klopt?
Dan weet je dat na één dag, met de reden erbij. Vaak is de reden oplosbaar: andere scans, een ander koppelvlak, een ander scherm. Soms niet, en dan is het plan van tafel voordat er een traject op is gebouwd. Beide uitkomsten zijn goedkoper dan dezelfde ontdekking halverwege.
Kan de bouwdag meerdere aannames toetsen?
Soms twee, als ze in hetzelfde deel zitten. Meestal is het verstandiger één aanname goed te toetsen dan drie half. Meerdere grote aannames zijn op zichzelf een signaal dat het plan te groot is voor één traject.
Wat als het plan al is goedgekeurd en begroot?
Dan is de bouwdag alsnog de goedkoopste eerste stap van het traject. Een goedgekeurd plan met een getoetste aanname loopt beter dan een met een ongetoetste. En als de aanname niet klopt, hoort de stuurgroep dat liever aan het begin dan halverwege.
Is dit hetzelfde als een proof of concept?
Het lijkt erop, maar kleiner en met code die je houdt. Een proof of concept is vaak een traject met een rapport en wegwerpcode. Een bouwdag toetst één aanname in één dag, op jullie gegevens, met code die het begin van het traject is.
