Het bestaat nog uit aannames
Een voorstel in tekst laat open hoe iets werkt en wie het gebruikt. IT moet dan de gaten zelf invullen, en dat gebeurt voorzichtig. Wat overblijft is een inschatting die alleen maar hoog kan uitvallen.
Je idee is afgekeurd door IT
Het voorstel ging naar IT en kwam terug met geen capaciteit dit jaar, past niet in de architectuur, of te veel risico. Vaak is dat een verdedigbaar oordeel over een plan dat nog uit aannames bestaat. Met iets werkends verandert waar het gesprek over gaat: niet over wat het zou kunnen worden, maar over wat er ligt.
01
/
04
Waarom een idee bij IT stukloopt
Drie afwijzingen die vaker over de vorm gaan dan over het idee zelf.
De vraag komt op het verkeerde moment
De planning ligt vast en jouw idee is geen bekende hoeveelheid werk. Iets ongedefinieerds inpassen tussen toegezegd werk is een risico dat niemand graag neemt, ook als het idee zelf goed is.
Het risico is niet af te bakenen
Zolang onduidelijk is welke data het raakt en waar het in het landschap hangt, is de veiligste reactie nee of later. Dat is geen onwil, dat is hoe je met onbekende risico's omgaat.
02
/
04
Wat wel en niet in een werkdag past
De beperking dwingt tot een keuze, en dat is precies wat het bruikbaar maakt.
Wat we in een dag doen
- De kern-userflow klikbaar maken, van begin tot eind.
- De aannames expliciet opschrijven in plaats van ze te verstoppen.
- Voorbeelddata gebruiken die herkenbaar is voor jullie situatie.
- Een deelbare URL opleveren die je kunt laten zien.
- Benoemen welke koppelingen er voor een vervolg nodig zijn.
Wat er niet in past
- Toegang tot jullie systemen of productiedata.
- Een versie die aan jullie beveiligingseisen voldoet.
- Een architectuurvoorstel of technisch ontwerp.
- Beheer, ondersteuning of een plek in het applicatielandschap.
- Een beslissing namens IT over wat er gebouwd wordt.
03
/
04
Hoe zo'n werkdag verloopt
Een vast ritme, waarbij jij alleen nodig bent als er een keuze ligt.
-
09:00
Context en gebruiker
Welk probleem los je op en voor wie? We bepalen wie het prototype straks moet overtuigen, in dit geval vaak ook iemand van IT.
-
10:00
De kern-userflow
Welk pad vertelt het verhaal? We kiezen de ene flow die klikbaar wordt en zetten de rest op de vervolglijst.
-
11:30
Aannames en raakvlakken
Welke gegevens zijn nodig en waar zouden ze vandaan komen? Dat schrijven we op als vraag, niet als oplossing.
-
13:30
Bouwen
We zetten de flow om in werkende schermen, met tekst en data die herkenbaar zijn voor jullie organisatie.
-
15:30
Doorlopen en aanscherpen
We lopen het door met de vraag waar een collega of IT'er zou afhaken, en passen aan waar dat nodig is.
-
17:00
Overdracht
Je krijgt de werkende URL, een korte walkthrough en de aannames op een rij.
04
/
04
Hoe je hiermee terug naar IT gaat
Het doel is niet gelijk krijgen, maar een beter gesprek voeren.
Een prototype is geen bewijs dat iets gebouwd moet worden. Het is materiaal waarmee IT kan beoordelen wat er werkelijk nodig is. In plaats van een discussie over een voorstel op papier gaat het over concrete schermen: welke gegevens komen hier vandaan, wat gebeurt er als iemand dit invult, wie mag dit zien.
Die vragen zijn preciezer dan wat er in de eerste ronde op tafel lag. Ze leiden meestal ook tot een preciezer antwoord, of dat nu een kleinere scope is, een ander koppelpunt, of alsnog een nee met een duidelijke reden.
Belangrijk: dit werkt alleen als je het openlijk doet. Een prototype dat buiten IT om als voldongen feit wordt gepresenteerd, verhardt het gesprek in plaats van het te openen. Betrek iemand van IT in de intake of laat het resultaat direct zien, ook als de conclusie ongemakkelijk is.
Zit het probleem eerder in capaciteit dan in goedkeuring, kijk dan bij geen development-capaciteit in huis. Moet je vooral collega's meekrijgen, dan sluit intern draagvlak met een tastbare demo beter aan. Twijfel je of jouw geval binnen een dag past, dan geeft kan dit in een dag een eerste indicatie.
05
/
05
Veelgestelde vragen
Gaan jullie om onze IT-afdeling heen?
Nee. Een prototype dat als voldongen feit wordt gepresenteerd maakt het gesprek harder, niet makkelijker. Het werkt het beste als IT weet dat je het laat maken en het resultaat direct te zien krijgt, ook als de uitkomst tegenvalt.
Wat als IT het prototype afkeurt op techniek?
Dan heb je alsnog iets bruikbaars. Een afkeuring op een concreet scherm is specifieker dan een afkeuring op een voorstel: je weet welk onderdeel het probleem is en of er een variant bestaat die wel kan.
Krijgen jullie toegang tot onze systemen of data?
Niet in een prototype-dag. We werken met voorbeelddata die op jullie situatie lijkt. Koppelingen met bestaande systemen horen bij een vervolgtraject, en dat is precies een van de dingen die IT moet beoordelen.
Voldoet het prototype aan onze beveiligingseisen?
Nee, en dat moet het ook niet suggereren. Het is bedoeld om een idee te toetsen, niet om in productie te draaien. Wat er voor een productiewaardige versie nodig is, staat op de vervolglijst.
Kan iemand van IT meedoen die dag?
Dat is vaak nuttig. Een uur meekijken bij de scope-keuze scheelt later discussie, omdat de raakvlakken dan meteen benoemd worden door iemand die het landschap kent.
Wat als het idee na het prototype alsnog niet doorgaat?
Dan heb je dat geleerd voordat er een traject aan hing. Een idee dat sneuvelt op basis van iets werkends is een goedkopere uitkomst dan een idee dat maanden blijft rondzweven.
Wie is eigenaar van wat er gebouwd wordt?
Dat leggen we vooraf vast. In wie is eigenaar van de code staat hoe dat werkt, inclusief de nuance rond code die met AI-hulp is gemaakt.
