Requirements, nah…

Vaak - sterker nog: eigenlijk altijd - kwam ik erachter dat wat de developer gemaakt had, helemaal niet zo goed was. Dat lag zeker niet aan hem. Hij had keurig overgenomen wat ik met veel pijn en moeite in Word had geklopt. Maar wat ik op papier had gezet en nu in werkelijkheid zag, was eigenlijk niet wat ik wilde. Dat realiseerde ik vaak pas als ik het uiteindelijke resultaat zag, wat betekende dat er weer een aanpassing nodig was. En zo kon het hele riedeltje weer van voor af aan beginnen.

Ik durf nu toe te geven dat ik misschien wel een hele slechte FO'er was. Ik vond er in ieder geval niet veel aan. Ik ben gewoon niet zo goed in het exact van te voren bedenken wat ik wil. In grote lijnen zie ik het precies voor me, Maar de kleine details, die zijn lastig.

Ik denk dat heel veel mensen dit herkennen. We denken lang na over specificaties en requirements, vullen backlogs, maken prachtige user stories en verfijnen deze in gezamenlijke sessies zodat we het allemaal eens zijn over wat we willen. Pas als het gebouwd is zien we of het ook echt is wat we voor ogen hadden. 

Goede specificaties maken is lastig, feedback geven op iets waar je op kan klikken is veel eenvoudiger. Wij, als gemiddelde mens, zijn gewoon niet goed in het vooraf precies bedenken wat we willen om dat vervolgens door iemand anders te laten bouwen. En toch is dat onze standaard aanpak.

Als we kijken naar innovatie en het ontwikkelen van nieuwe businessmodellen, dan zie je dat de traditionele aanpak nogal eens faalt. In de trajecten waar ik aan gewerkt heb, is eigenlijk nooit helemaal precies bekend wat je wil gaan maken. Vaak moet je eerst maar eens zien dat wat je bedacht hebt ook echt gaat werken. Dat moet in een zo kort mogelijke tijd, tegen lage kosten en met de flexibiliteit om eenvoudig aanpassingen te doen. Dan kun je je helemaal niet de luxe veroorloven om heel lang over allerlei requirements na te denken. Je wil zo snel mogelijk resultaat om je idee te valideren. Fail fast, learn fast.

Bij mijn eerste project met no-code zag ik dat je met deze tooling op een hele andere manier kon werken. In plaats van lang zweten op requirements zaten we met z’n drieën in een hok op het whiteboard te schetsen en te bedenken wat we wilden. Terwijl we aan het praten waren, zat de no-code developer  al onze suggesties uit te werken en konden we direct feedback krijgen op hetgeen we net hadden bedacht. Soms was het goed,  soms niet, Maar dan waren de aanpassingen ook zo gemaakt. 
Op deze manier hadden we in no-time een Minimal Viable Product staan, exact naar onze wensen gemaakt, en konden we dit in de praktijk  gaan testen. 

Mijn oude onderbuurman zei altijd: “Al doende leert men.” Ik denk dat hij daar volkomen gelijk in heeft. Hoe sneller we nieuwe initiatieven kunnen realiseren, hoe beter we kunnen leren of ze dat doen wat we voor ogen hebben. Met no-/low-code-platformen krijg je de tools in handen die het je mogelijk maken om veel sneller resultaten te kunnen boeken. Op deze manier krijg je sneller feedback op hetgeen je bedacht hebt, in de vorm van een echte applicatie, website of app. En dat kunnen we als normale mensen veel beter beoordelen dan een user story op een backlog of een plat Word-document geschreven door een middelmatige Functioneel Ontwerper.