Wat is een proof of concept? Een kleine test om te bewijzen dat iets technisch kan. Nog geen product. Waarom een PoC zonder vervolgplan vaak strandt.
Een proof of concept is een kleine, afgebakende test die één vraag beantwoordt: kan dit technisch? Hij bewijst haalbaarheid, geen productwaarde. Het resultaat is een antwoord, geen werkend systeem voor je dagelijkse praktijk. Een PoC die zijn vraag beantwoordt en dan gewoon verdwijnt, heeft zijn werk gedaan.
De vraag die een PoC beantwoordt is smal en precies: lukt het om dit document automatisch te vatten in dit formaat? Kan dit model deze beelden herkennen met deze betrouwbaarheid? Lukt de koppeling tussen dit ene oude pakket en dit nieuwe? Zo'n vraag kan niet uit een brochure worden beantwoord, en heel vaak niet eens uit documentatie. Hij vraagt een poging. De PoC is die poging, bewust klein gehouden: los van je systemen, met proefmateriaal, zonder koppelingen naar productie.
Wat een PoC onderscheidt van een eerste versie is de wet op het weggegooide werk: de code is wegwerpbaar, de kennis is de opbrengst. Een PoC die netjes geschreven moet blijven is een tegenspraak, want het doel is de grens vinden, niet een product neerzetten. Het afgesproken eindpunt is een antwoord (ja met deze voorwaarden, nee tenzij dit verandert, of ja maar alleen met deze beperkingen) en niet een softwareopbrengst die je door moet zetten.
Eerlijk is ook dit: het PoC-kerkhof bestaat. In bureaus en IT-afdelingen liggen talloze haalbaarheidsproeven die bewezen dat het kon, en toen stopten. Niet omdat het antwoord negatief was, maar omdat niemand had vastgelegd wat er ná het bewijs hoort te komen. Een PoC zonder vooraf afgesproken vervolg is dus geen voorzichtigheid maar uitstel: het bewijs wordt wel verzameld, het besluit wordt alleen niet genomen.
De moeite waard is een PoC wanneer de technische onzekerheid het zwaarst weegt in een plan: als het vraagstuk nooit eerder is uitgevoerd, als het model het misschien niet redt, of als de koppeling met een ouder systeem onzeker is. Ook loont hij wanneer een heel traject op dat ene vraagpunt staat of valt. Beter een kleine test dan een grote bouw op een aanname. En hij is goedkoop als de vraag smal geformuleerd is.
Het loont niet wanneer de techniek al bewezen is en de echte vraag ergens anders ligt. Bij de adoptie, bij het proces, bij de kosten. Wie een haalbaarheidsproef aanschaft om een besluit uit te stellen, koopt drie maanden uitstel en geen antwoord. En wie er meerdere achter elkaar laat volgen zonder ooit een besluit te trekken, herkent zich misschien in het kerkhof hierboven: het bewijs lag er al.
Wij gebruiken een PoC als kleinste onderdeel van een grotere lijn: een smalle vraag uit de discovery, een korte proef, een schriftelijke uitkomst, en dan een besluit over doorgaan, aanpassen of stoppen. Met de vervolgstappen van tevoren afgesproken, zodat het bewijs niet op een plank belandt. Waar het kan slagen loont daarna een pilot in de praktijk. Elke fase wordt afzonderlijk gescopet en op nacalculatie afgerekend.
Er is geen gemiddelde die ergens op slaat, want de omvang volgt uit de vraag: een vraag over één documenttype is een andere opdracht dan een vraag over tien typen. Wat we wel kunnen zeggen: een goede PoC is bewust klein gehouden, los van je systemen en met proefmateriaal, en daarmee een fractie van een volledige bouw. We stellen de vraag vooraf scherp, offert de proef op nacalculatie en trekt het vervolg bewust mee. Zodat je geen uitstel koopt maar een besluit.
Korter dan een bouw, dat is het punt. Maar hoe lang precies hangt van de vraag af, en eerlijk gezegd ook van hoe snel het antwoord nee blijkt te zijn. Een smalle technische vraag over één documenttype of één koppeling is typisch een korte, begrensde opdracht. Wij spreken vooraf een eindpunt af: welke vraag beantwoord wordt en wanneer de proef stopt. Zo wordt het geen open einde waarbij een proef ongemerkt een half product wordt.
De PoC toetst een vraag; het prototype toont een vorm. Een PoC bewijst of het model het documenttype aankan, los van schermen en uiterlijk. Een prototype laat zien hoe het scherm eruitziet en hoe gebruikers het lopen. Klikbaar, maar vaak zonder echte gegevens of koppelingen. In een traject gaat de PoC meestal vooraf, het prototype loopt ernaast of erna, en de eerste echte versie komt pas als beide vragen beantwoord zijn.
Meestal niets: hij verdient zijn geld in kennis, niet in hergebruik. De proefcode is op snelheid geschreven en op productie-eisen als veiligheid en beheer niet getoetst; die mee slepen in een echte bouw is vaak duurder dan vers opnieuw beginnen met de opgedane inzichten. Soms blijft een fragment overeind (een koppeling die bleek te werken, een berekening die klopte) en die nemen we als referentie mee. Het bewijs reist mee, de code niet per se.
EIGHTY8