Design thinking: maatwerk is helemaal terug
open source innovatie design thinking
1 maart 2018
Ontwikkelmethoden als agile development en lean startup onderschrijven het belang van de rol van de eindgebruiker, door deze vroeg en vaak te betrekken bij het ontwikkelen van software. Design thinking gaat daarin nog verder: de beoogde gebruikers worden niet alleen betrokken om gemaakte software te testen, maar ook om te bedenken wat voor software nodig is. Of zelfs om te beslissen óf er software nodig is.
(Lees het originele artikel op AG Connect)
“One size fits none. Overheden moeten weer meer zelf gaan ontwikkelen. Ze hebben gekke processen,” stelt Maarten Geraets. Hij zette drie jaar geleden op verzoek van de gemeente Amsterdam het Datalab op. Zijn opdracht was om met een innovatief team datagedreven toepassingen te zoeken voor een aantal zeurende problemen in de stad. Geraets ontwikkelde daarvoor samen met zijn zakenpartner Johan Groenen de FIXXX-methode, ofwel Fast Innovation Amsterdam. Inmiddels zijn al verschillende projecten met succes afgerond.

De aanpak heeft veel weg van bekende agile development- en lean startup-projecten. In kortcyclische iteraties wordt binnen enkele weken een werkend programma opgeleverd dat in een concrete behoefte voorziet. Het verschil tussen FIXXX en de voornoemde methoden zit hem in de rol van de eindgebruiker. Geraets: “Het moet kneiter human-centered zijn.”
Daarmee zet hij zich krachtig af tegen de trend bij vooral grote organisaties om zoveel mogelijk over te gaan op standaardsoftware. In elk standaardprogramma zit een proces ingebakken. Eigenlijk sluit dat nooit aan bij de processen van de organisatie. Het idee is dat de organisatie de processen aanpast aan de standaardsoftware. Maar dat gaat altijd wringen. Voor Geraets staan dan ook de werkprocessen centraal. “Je kunt niet aan tafel bedenken wat werkt. Dus ‘get out of the building’.”
En dat is wat hem betreft ook menens. Dat betekende in het eerste project: programmeren op een marktkraam tussen de schreeuwende marktkooplieden. Er moest een oplossing komen voor een probleem bij de markttoezichthouders die de marktkramen toedelen aan kooplieden. De gemeente vond het niet van deze tijd dat de marktkooplieden elke ochtend bij elkaar moesten komen om te horen of zij een kraam konden krijgen. De reden is dat de indeling op papier plaatsvindt. De vraag aan het Datalab was dus of daar niet een ander systeem voor in de plaats kon komen.
De markt op
Het team van Geraets ging dagenlang met de toezichthouders de markt op om het werkproces te observeren en met de ambtenaren samen naar oplossingen te zoeken. Ze ontdekten dat de aannames van de gemeente over het probleem niet klopten.
Geraets: “Kooplieden zijn er de hele week mee bezig. De indeling is belangrijk voor ze, ook omdat niet elke plek op de markt hetzelfde is. Een plek op de hoek levert meer zichtbaarheid. Een boom achter de kraam is beroerd, want dan kun je de bestelbus met voorraad niet goed kwijt. Bovendien leeft het bijgeloof sterk onder de ondernemers op de markt. Daarom praten en bellen ze voortdurend met elkaar. Ze weten precies: als die komt, hoef ik niet te gaan, want dan maak ik geen kans. Er was nooit iemand die ‘s ochtends vloekend terug naar huis moest.” De conclusie was dus dat het indelen niet het probleem was, en echt het best op papier kon. De markttoezichthouders zijn daar zo efficiënt mee, dat wanneer je daar software voor zou inzetten, het alleen maar vertraging zou introduceren. Dat was al eerder geprobeerd, en op een drama uitgelopen.
Verkeerde aanname
Het échte probleem bleek een slecht werkend administratiesysteem. Dat was het gevolg van een maatregel van de gemeente een aantal jaar geleden, waarbij het toezicht op de markten in de verschillende stadsdelen werd samengevoegd. “We kwamen allemaal gekke situaties tegen. In stadsdeel Zuid maakte we mee dat je de administratie alleen kon inzien op een oude Windows 95-bak. De enige manier die men had om informatie daaruit te krijgen, was door het over te schrijven. In stadsdeel Centrum was er een scansysteem zonder database. De administratie werd daar al jaren niet meer opgeslagen. Alle scanners bliepten netjes bij elke scan, dus niemand die het doorhad. Voor ons was het snel duidelijk wat we moesten doen. We konden een app maken die het scannen en afrekenen mogelijk maakt, en die aan een backend koppelen voor de centrale administratie. Dat hebben we dus met vier man aan een kraampje zitten programmeren.”
In korte tijd was er een werkend prototype voor het maken van een ‘scan’. “De eerste versie was echt alleen een invoerveld.” Daarna zijn incrementeel functies toegevoegd en praktische problemen opgelost terwijl de toezichthouders over de schouders van de programmeurs meekeken. “Hoe het kan weet ik niet, maar de markttoezichthouders hebben heel grote handen. Dus vormen standaardknoppen een probleem. De volgende dag hadden we al een nieuwe versie met grotere knoppen. We vroegen voortdurend feedback of ons werk voldeed aan hun verwachtingen.”
Product owner moet zelf verder kunnen
Nadat de app kon scannen, registreren hoeveel meter de kraam besloeg, berekenen hoeveel reclamegeld er moest worden geïnd en met de app kon worden afgerekend en deze een bon kon produceren, was het project af. Ondertussen werd de product owner meegenomen in de ontwikkeling zodat deze autonoom verder kon om meer functionaliteit toe te voegen, zoals de koppeling met een backendapplicatie. “De doorontwikkeling kan bij het Datalab, maar ook bij een andere softwarebouwer. De software die wij maken is altijd open source.”
De nieuwe visie op het belang van maatwerk betekent dat de gemeente weer mensen moet gaan aannemen die dat kunnen. “Er moet samenhang zijn via het gebruik van standaarden, maar die moeten niet rigide zijn”, concludeert Geraets. Hij pleit ervoor dat de overheden microservices gaan ontwikkelen op basis van application programming interfaces (api’s). Die kunnen dan verschillende applicaties voeden met actuele informatie. “Zo ontwikkelen nieuwe diensten zich net zoals het internet zich ontwikkelde. Dat is ook een bolwerk op basis van standaarden.”
Andere aantekeningen
Open Samenwerken, hoe doe je dat?
14 juni 2021
Je project open stellen voor open samenwerking met andere organisaties, teams of "de community" is niet altijd eenvoudig. Toch is het de wens van veel overheidsprojecten om meer open te gaan werken. Code for NL organiseerde een meetup waarin vanuit drie projecten ervaringen werden gedeeld.
Ik wil geen 'clean desk'. Ik wil samenwerken.
30 januari 2026
Op veel plekken geldt een clean desk policy. Onder het mom van de flexibele werkplek worden gebouwen er volledig op ingericht: lege bureaus, lockers, generieke stoelen, en vooral niks op muren of ramen. Dat lijkt onschuldig. Efficiënt zelfs. Maar het heeft structurele effecten op hoe werk wordt gedaan en ervaren, en ook vooral op hoe samenwerken werkt (of beter: niet werkt).
Single Point of Failure
31 augustus 2025
We vrezen vaak het single point of failure — één plek waar alles kan vastlopen of lekken. Maar juist daar zit ook de sleutel: één plek om te sturen, te beveiligen en fouten te herstellen. Of het nu gaat om een AI-gateway die digitale autonomie waarborgt, of een centraal administratiekantoor voor medisch onderzoek dat privacy en toestemming strak beheert: kwetsbaarheid en mitigatie vallen samen. De crux is niet óf je centraliseert, maar hóe je dat ene punt zo inricht dat het een bron van vertrouwen wordt.