De twijfel zit bij gebruikers
Je wilt weten of mensen de flow snappen, hem gebruiken zoals bedoeld of er iets voor over hebben. Daarvoor heb je iets nodig dat werkt, niet iets dat compleet is.
Een proof of concept in een week of in een dag?
Het verschil tussen een week en een dag is geen kwestie van kwaliteit maar van onzekerheid. Hoe meer er uitgezocht moet worden voordat je kunt bouwen, hoe meer tijd je nodig hebt. Hieronder staat waar die grens ligt, welke vragen in een dag te beantwoorden zijn en welke niet, zodat je vooraf de goede vorm kiest.
01
/
06
De vraag bepaalt de vorm
Niet de omvang van het idee, maar de aard van de onzekerheid bepaalt hoeveel tijd nodig is.
Mensen kiezen de duur vaak op gevoel voor hoe groot het idee is. Dat is niet de goede maatstaf. Een omvangrijk idee kan in een dag te toetsen zijn als de twijfel bij één flow zit. Een klein idee kan een week vragen als er iets technisch onbekends in zit dat eerst uitgezocht moet worden.
De bruikbare vraag is dus: wat weet je nog niet, en wat is er nodig om daar achter te komen? Als het antwoord ligt bij hoe gebruikers reageren, heb je iets klikbaars nodig en niet veel meer. Als het antwoord ligt bij of twee systemen met elkaar kunnen praten, heb je toegang, testdata en tijd nodig.
De begrippen lopen daarbij door elkaar. Wat het verschil is tussen de gangbare termen staat op prototype, MVP en proof of concept.
02
/
06
Wat in een dag past
Drie situaties waarin een werkdag doorgaans volstaat.
De techniek is bekend
Er zit geen onderdeel in waarvan onduidelijk is of het kan. Je bouwt met patronen die vaker zijn gebruikt, waardoor de tijd naar de flow gaat in plaats van naar uitzoekwerk.
Er is iets te laten zien
Een gesprek, een stuurgroep of een pitch waarvoor iets tastbaars nodig is. De deadline is hier vaak leidend, en dan is een dag niet alleen genoeg maar ook het enige dat past.
03
/
06
Wanneer een week realistischer is
Bij deze onderwerpen loopt de tijd op buiten het bouwen om.
Zodra er een koppeling met een bestaand systeem in zit, verschuift het zwaartepunt. Toegang regelen, rechten krijgen en testdata bemachtigen loopt via mensen en procedures, en dat kost doorlooptijd die je niet kunt inhalen door harder te werken.
Hetzelfde geldt voor technische onzekerheid. Als de kernvraag is of iets kan, bijvoorbeeld of een bepaalde verwerking snel genoeg is of een bepaald model bruikbaar is voor jouw gegevens, dan is uitzoeken het werk. Dat laat zich moeilijk in een dag plannen omdat je vooraf niet weet wat je tegenkomt.
Een derde geval is een idee met meerdere gebruikersrollen die elk een eigen flow hebben, waarbij het samenspel tussen die rollen juist de vraag is. Dat is meer dan één flow, en dus meer dan een dag.
04
/
06
Een dag of een week
Een indeling om je eigen vraag tegen te leggen.
Een werkdag volstaat
- Eén flow van begin tot eind, voor één type gebruiker.
- Bekende techniek, zonder onderdeel waarvan onduidelijk is of het kan.
- Voorbeeldgegevens die het verhaal geloofwaardig maken.
- Een deadline waarvoor iets tastbaars nodig is.
Reken op meer tijd
- Een werkende koppeling met een systeem waar je nog geen toegang toe hebt.
- Een technische vraag waarvan het antwoord echt uitgezocht moet worden.
- Meerdere rollen waarvan het samenspel de kern van de vraag is.
- Verwerking van bestaande gegevens uit een lopend systeem.
05
/
06
Beginnen bij het kleinste antwoord
Bij twijfel is de kortere vorm meestal de verstandigere eerste stap.
Als je niet zeker weet welke vorm je nodig hebt, is beginnen bij de kleinste versie doorgaans het verstandigst. Je koopt er informatie mee waarmee je de vervolgkeuze beter kunt maken, en je hebt de langere variant nog steeds als optie.
Andersom werkt minder goed. Een week besteden aan een vraag die in een dag te beantwoorden was, geeft geen beter antwoord maar een later antwoord, en meestal ook een breder gebouwd resultaat dan nodig was.
Loop bij twijfel de kan-dit-in-1-dag-check na. Gaat het meer om het scherp krijgen van de richting dan om bouwen, dan past een discovery-sprint beter, en de aanpak van een bouwdag beschrijft hoe zo'n dag verloopt.
06
/
06
Veelgestelde vragen
Wanneer heb ik een week nodig in plaats van een dag?
Als er technische onzekerheid in het spel is die uitgezocht moet worden, als er meerdere gebruikersrollen met verschillende flows nodig zijn, of als er een koppeling met een bestaand systeem in zit waarvoor toegang en testdata geregeld moeten worden. Die dingen laten zich niet in een dag samenpersen.
Wanneer is een dag genoeg?
Als de vraag over één flow gaat, de techniek bekend is en het doel is om iets te kunnen laten zien of testen. Dat dekt een groot deel van de gevallen waarin mensen een proof of concept willen: ze willen weten of het idee werkt voor gebruikers, niet of het technisch mogelijk is.
Wat is het verschil tussen een proof of concept en een prototype?
Een proof of concept beantwoordt de vraag of iets kan, meestal technisch. Een prototype laat zien hoe iets werkt en is bedoeld om te toetsen bij mensen. In de praktijk lopen de termen door elkaar, dus is het nuttiger om te vragen welke vraag beantwoord moet worden dan welk woord erop past.
Kan ik met een dag beginnen en later uitbreiden?
Dat is een gebruikelijke volgorde. Je begint bij het onderdeel waar de meeste twijfel zit en breidt uit als dat standhoudt. Het voordeel is dat je na een dag al informatie hebt waarmee je de vervolgkeuze beter kunt maken.
Wat als ik vooraf niet weet welke van de twee ik nodig heb?
Dan is dat de eerste vraag in de intake. Meestal blijkt uit het gesprek vanzelf waar de onzekerheid zit. Zit die bij gebruikers, dan volstaat een dag. Zit die in de techniek of in een koppeling, dan is meer tijd realistischer.
Is een week altijd beter dan een dag?
Nee. Meer tijd betekent alleen iets als je die tijd nodig hebt voor onzekerheid die er echt is. Een week besteden aan een vraag die in een dag te beantwoorden was, levert geen beter antwoord op, alleen een later antwoord.
Wat gebeurt er als een dag halverwege te kort blijkt?
Dan is dat een uitkomst en geen mislukking: je weet dan dat het onderdeel complexer is dan gedacht. In de praktijk komt dat weinig voor als de scope vooraf goed is bepaald, wat precies de reden is dat de intake bestaat.
