POC (Proof of Concept (haalbaarheidsbewijs))

Een POC, of proof of concept, is een korte technische test die één vraag beantwoordt: kan dit idee echt gerealiseerd worden, nog vóór er echt geïnvesteerd wordt.

Wat is een POC?

Een POC, of proof of concept, is een korte en bewust smalle technische test, gebouwd om één precieze vraag met ja of nee te beantwoorden: kan dit idee echt werken, rekening houdend met de echte technologie, de echte gegevens en de echte beperkingen die meespelen, in plaats van de vereenvoudigde versie die in een planningsvergadering besproken werd. TechTarget beschrijft het als een demonstratie die gericht is op het bepalen van de haalbaarheid van een idee, en die beschrijving vat de essentie goed samen: een POC bestaat om twijfel over haalbaarheid weg te nemen, niet om iemand te imponeren.

Het belangrijkste onderscheid in de praktijk is dat tussen een POC en een MVP, want beide worden veel te vaak door elkaar gebruikt. Een POC test of iets technisch mogelijk is. Een MVP test of echte gebruikers het resulterende product willen zodra het mogelijk is. Een POC wordt bijna nooit aan eindgebruikers getoond, terwijl een MVP specifiek voor hen gebouwd wordt. Wie de twee verwart, gaat ofwel een haalbaarheidstest overbouwen, ofwel een producttest onderbouwen, en beide verspillen budget.

Een derde term verdient een plaats op dezelfde kaart: het prototype, dat dichter bij design staat dan de andere twee. Een prototype toont hoe iets eruit zou kunnen zien, een POC bewijst wat iets technisch kan, en een MVP bewijst dat echte mensen het willen zodra het bestaat. Die drie begrippen gescheiden houden, in plaats van ze te behandelen als inwisselbare woorden voor een eerste versie, houdt elk ervan goedkoop en nuttig, in plaats van er een dure kleine versie van het eindproduct van te maken.

Waarom een POC belangrijk is

Drie redenen verklaren waarom het overslaan van deze stap doorgaans meer kost dan ze uit te voeren.

• Het spoort technische doodlopende wegen op voordat ze duur worden. Een integratie die op de website van een leverancier eenvoudig lijkt, kan geblokkeerd blijken door een verouderde API, ontbrekende datavelden of een licentiebeperking, en dat ontdekken nadat een volledige bouw gestart is, kost veel meer dan het ontdekken in twee weken testen.
• Het geeft een duidelijk antwoord, doorgaan of niet, in plaats van een vage indruk. Een POC wordt beoordeeld tegen een precies technisch criterium dat vooraf beslist is, wat een echt antwoord oplevert in plaats van een algemeen gevoel dat iets waarschijnlijk wel werkt.
• Het beschermt de geloofwaardigheid van de bredere beslissing. Een voorstel aan de directie of aan een investeerder dat gestaafd wordt door een werkende technische test, is een fundamenteel ander gesprek dan een voorstel dat alleen steunt op de marketingargumenten van een leverancier of het optimisme van een ontwikkelaar.

Het compromis dat u eerlijk moet aanvaarden: een POC levert wegwerpcode op, geen fundament om op verder te bouwen. De code van een geslaagde POC behandelen als klaar voor productie, is een van de meest voorkomende en duurste fouten na deze stap.

Hoe het werkt

Vier elementen bepalen een goed uitgevoerde POC, ongeacht de betrokken technologie.

Eén enkele, smalle technische vraag. Geen algemene verkenning van een idee, maar een precieze bewering die als waar of onwaar bewezen kan worden, zoals of een bepaalde API de vereiste gegevens kan teruggeven binnen een aanvaardbare responstijd.

Minimale wegwerpcode. Een POC wordt gebouwd om een punt aan te tonen, niet om lang mee te gaan. De codekwaliteit, foutafhandeling en beveiliging die een productiesysteem vraagt, worden bewust overgeslagen, want er tijd in steken gaat in tegen het doel van een snelle test. Een gangbare vuistregel zegt dat als de code zes maanden na het einde van de POC nog draait, er iets fout liep bij het omgaan met het resultaat, en niet dat de code uiteindelijk goed bleek te zijn.

Echte omstandigheden, geen vereenvoudigde. Testen op een proper, klein datastaal in plaats van op de echte, rommelige gegevens is de meest voorkomende manier waarop een POC een vals positief resultaat oplevert dat in elkaar zakt zodra de echte ontwikkeling begint.

Een strikte termijn. De meeste nuttige POC’s duren één tot vier weken. Een POC die duidelijk langer uitloopt, is doorgaans opgehouden een smalle haalbaarheidstest te zijn en een ongeplande eerste versie van de echte bouw geworden.

Implementatie

De volgorde hieronder zet de beslissingen vooraan die een POC smal en nuttig houden in plaats van een open verkenning.

1. Schrijf de technische vraag op als één toetsbare zin. Vage doelstellingen zoals een nieuwe technologie verkennen leveren vage, weinig overtuigende resultaten op, een precieze bewering levert een precies antwoord op.
2. Leg de termijn vast voordat u begint, niet zodra het werk loopt. Een vaste deadline voorkomt dat een POC stilletjes uitgroeit tot een volledige bouw zonder vastgelegd succescriterium.
3. Gebruik echte gegevens, of het dichtst beschikbare alternatief. Een test die slaagt op opgeschoonde voorbeeldgegevens en faalt tegenover de rommelige realiteit van productie, heeft de vraag waarvoor hij gebouwd werd niet echt beantwoord.
4. Sla alles over wat niet nodig is om de vraag te beantwoorden. Geen foutafhandeling op productieniveau, geen verzorgde interface, geen schaalbaarheidstests: dat hoort allemaal bij een latere fase, niet bij de haalbaarheidstest.
5. Documenteer het resultaat eerlijk, ook gedeeltelijke mislukkingen. Een POC die half werkte onder precieze omstandigheden, is nuttiger als dat nauwkeurig gedocumenteerd wordt dan als het afgerond wordt tot een proper ja.
6. Beslis expliciet wat er daarna met de code gebeurt. Ofwel wordt ze weggegooid en begint een echte bouw van nul, ofwel wordt bewust beslist om ze te verstevigen, maar die beslissing mag nooit bij gebrek aan beter vallen, uit inertie.

Wat kost het

Een gerichte POC, uitgevoerd door een professioneel ontwikkelteam, kost voor een Belgische kmo doorgaans tussen 5.000 en 30.000 euro, afhankelijk van het aantal betrokken systemen of technologieën en de toegang tot echte gegevens die de test vereist. Eén enkele, smalle integratievraag zit eerder onderaan die vork, terwijl een POC met verschillende onbekende technologieën of complexe toegang tot gegevens eerder bovenaan zit.

De kost die teams verrast, is niet de POC zelf, maar de valse besparing door hem over te slaan. Een volledige bouw die pas na maanden ontwikkeling op een fundamentele technische blokkade botst, kost veel meer dan de haalbaarheidstest die ze in enkele weken had opgespoord, en dat verschil is op zich het volledige economische argument voor een POC.

Een kleinere maar terugkerende kost om op te anticiperen, is wat er gebeurt zodra het antwoord bekend is. Een idee waarvan bevestigd is dat het haalbaar is, heeft daarna nog steeds een correct afgebakende en gebudgetteerde bouw nodig. De POC bewijst alleen dat de deur niet op slot zit, hij bouwt de kamer erachter niet. Die latere budgetteringsstap overslaan, en aannemen dat de lage kostprijs van de POC de toon zet voor het echte project, is een andere veelgemaakte fout die de cijfers later vertekent.

Conclusie

Een POC is een kleine wegwerpgok die specifiek bedoeld is om het risico van een veel grotere gok te verkleinen. Zijn waarde komt volledig voort uit smal en eerlijk blijven (één precieze vraag, echte omstandigheden, een vaste deadline en een gedocumenteerd antwoord) in plaats van stilletjes uit te groeien tot een ongeplande eerste bouw.

De bedrijven die echte waarde halen uit een POC, zijn de bedrijven die de neiging weerstaan om hem presentabel te maken, hem afgebakend houden op de enige technische vraag die het risico echt draagt, en een weloverwogen beslissing nemen over wat er met de code gebeurt zodra het antwoord er is, in plaats van een wegwerptest per ongeluk naar productie te laten afglijden.