01
De vraag
Een PoC vraagt 'kan het'. Een bouwdag vraagt 'werkt het bij ons, met onze gegevens, voor onze mensen'. Dat zijn verschillende vragen.
OneDayBuild, het bouwdagmerk van Appfront
Proof of concept-traject of eerst een dag bouwen?
Een proof of concept is bedoeld om te bewijzen dat iets technisch kan. In de praktijk wordt het vaak een traject met een team, een plan en een eindrapport, en de code die eruit komt is niet bedoeld om te houden. Een bouwdag stelt dezelfde vraag, maar kleiner: één onzekerheid, één dag, werkende code in je eigen repository. Welke van de twee past, hangt af van wat je eigenlijk wilt weten.
- Eén werkdag
- Werkend prototype
- Code in je eigen repository
01/06
Waar de twee routes uit elkaar lopen
Een PoC beantwoordt 'kan het'; de vraag is of dat je echte vraag is.
Een proof of concept begint met een goede reden: een organisatie wil weten of iets technisch mogelijk is voordat ze erin investeert. Daarna groeit het. Er komt een projectleider, een plan van aanpak, werksessies en aan het eind een rapport met een advies. De code die onderweg is geschreven, is wegwerpcode; dat stond ook zo in het plan. Daarna begint het echte bouwen opnieuw.
Dat is niet per se fout. Zit de onzekerheid in iets zwaars, zoals de koppeling met een kernsysteem, prestaties op grote volumes of de beveiliging van een architectuur, dan is een PoC-traject de juiste vorm. Maar veel PoC-vragen zijn kleiner: werkt dit model op onze documenten, snappen gebruikers dit scherm, is deze gegevensbron bruikbaar. Voor die vragen is het traject zwaarder dan de vraag.
Een bouwdag pakt precies die kleinere vraag. Eén onzekerheid, één dag, en aan het eind iets dat werkt op echte gegevens, op een live URL, met de code in jullie eigen repository. Geen rapport, maar iets dat je aan een stuurgroep of een klant laat zien. Werkt het, dan is het de eerste steen in plaats van een bewijs dat je weggooit. Werkt het niet, dan weet je dat na één dag.
02
De code
PoC-code is wegwerp, en zo wordt hij ook geschreven. Bouwdagcode staat in je eigen repository en is de basis voor wat volgt.
03
De doorlooptijd
Een PoC heeft een plan, sessies en een rapport. Een bouwdag heeft een ochtend, een middag en een live URL.
04
Het gesprek erna
Een rapport wordt gelezen door wie tijd heeft. Iets dat werkt, wordt geklikt door wie beslist.
02/06
Wat valt binnen en buiten de bouwdag
Binnen scope
- De ene onzekerheid die je PoC-traject zou moeten beantwoorden, werkend gemaakt.
- Werken met jullie eigen gegevens, of een realistische set als die niet beschikbaar zijn.
- Een live URL die je aan een stuurgroep, een klant of een investeerder laat zien.
- De code in je eigen repository, geschreven om op door te bouwen.
Buiten scope
- Een eindrapport met architectuuradvies en risicoanalyse.
- Onderzoek naar prestaties op grote volumes of naar beveiliging van een architectuur.
- Koppelingen met kernsystemen die een eigen aansluit- en testtraject hebben.
- Een besluit over leverancierskeuze of platformkeuze.
03/06
Hoe de bouwdag verloopt
- Stap 1
De onzekerheid benoemen
Wat moet het PoC eigenlijk bewijzen, in één zin.
- Stap 2
Het kleinste bewijs kiezen
Niet het hele idee, maar het deel dat die zin beantwoordt.
- Stap 3
Bouwen
Werkend, op jullie eigen gegevens of een set die er genoeg op lijkt.
- Stap 4
Meten wat het doet
Wat het oplevert of scheelt, voor zover dat in een dag te zien is.
- Stap 5
Klaarzetten voor het gesprek
In welke volgorde je het laat zien en wat je erbij vertelt.
- Stap 6
Opleveren
Live URL, code in je eigen repository en een eerlijke lijst met wat er nog niet in zit.
Volgende stap
Twijfel je of je PoC eigenlijk een bouwdag is?
Vertel wat het PoC moet bewijzen en wie het rapport gaat lezen. In een korte intake bepalen we of die vraag in één dag te beantwoorden is, of dat je echt een traject nodig hebt.
04/06
Eerlijk over deze vergelijking
- Soms is een PoC-traject de juiste keuze. Als de vraag over infrastructuur, volumes of beveiliging gaat, past een dag niet. Dan is een traject met de juiste mensen erbij de kortste weg.
- Een bouwdag levert geen rapport. Wie een document nodig heeft voor een formeel besluit, moet dat zelf schrijven. Wat je meekrijgt, is het bewijs en een lijst met wat er nog niet in zit.
- Bouwdagcode is een begin, geen product. Hij is geschreven om te houden, maar hij is één dag oud. Beveiliging, beheer en schaal komen in het traject daarna.
- Beide routes kunnen nee opleveren. Dat is geen mislukking. Een nee na één dag is goedkoper dan een nee na een traject, en dat is het hele argument.
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 PoC-vraag gaat over of iets werkt bij jullie, met jullie gegevens en jullie mensen.
- Aan het eind van de dag heb je iets werkends dat je aan de beslissers laat zien.
- Één dag, vaste prijs, code in je eigen repository.
Volledig traject, Appfront
- Het werkt en je wilt het echt in gebruik nemen, met koppelingen, beveiliging en beheer.
- Of je vraag gaat over infrastructuur en volumes; dan is een traject vanaf het begin de juiste vorm.
- Een traject bij Appfront, met beheer en doorontwikkeling.
06/06
Veelgestelde vragen
Wat is het verschil tussen een proof of concept en een bouwdag?
Een proof of concept is een traject dat bewijst dat iets technisch kan, meestal met een team, een plan en een rapport, en met code die daarna wordt weggegooid. Een bouwdag beantwoordt één onzekerheid in één dag, met werkende code in je eigen repository. Het verschil zit in de omvang van de vraag en in wat je overhoudt.
Wanneer is een PoC-traject wél de juiste keuze?
Als de onzekerheid zwaar is: een koppeling met een kernsysteem, prestaties op grote volumes, de beveiliging van een architectuur, of een leverancierskeuze met langlopende gevolgen. Die vragen hebben de juiste specialisten en een gedocumenteerd antwoord nodig. Een dag is daar te kort voor, en dat zeggen we dan ook.
Kan een bouwdag als PoC gelden voor onze stuurgroep?
Vaak wel, als de stuurgroep wil weten of het werkt en niet alleen of het kan. Iets werkends op een live URL, met echte gegevens, overtuigt meestal meer dan een rapport. De tekst voor het formele besluit schrijf je zelf.
Is de code van een bouwdag echt bruikbaar?
Ja, dat is het uitgangspunt. Hij staat in jullie repository, is geschreven om op door te bouwen en draait op een live URL. Hij is wel één dag oud: beveiliging, beheer en schaal zijn nog niet gedaan. Je hoeft niet opnieuw te beginnen, maar je bent ook nog niet klaar.
Wat als de bouwdag laat zien dat het niet werkt?
Dan weet je dat na één dag, met de reden erbij. Dat is de goedkoopste nee die je kunt krijgen, en precies waar een PoC voor bedoeld was. Vaak blijkt de reden oplosbaar, en dan is een tweede dag gerichter dan de eerste.
Kunnen we een bouwdag doen en daarna alsnog een PoC-traject?
Ja, en dat is een goede volgorde als je vraag uit twee delen bestaat. De bouwdag beantwoordt eerst of het bij jullie werkt. Daarna kan een traject de zware vragen oppakken, en dat begint dan met iets werkends in plaats van met een leeg document.
