Van een idee naar een IT-oplossing: 'Faal snel en faal vaak'

In veel organisaties waar software of IT-diensten worden geleverd, is het een bekende uitdaging: iemand komt binnenlopen met grootse plannen, een baanbrekend idee, een plan dat de toekomst gaat veranderen. Echter, de bedenker weet nog niet precies hoe dit idee tot een werkend product gevormd moet worden.

Een projectmanager begeleidt de bedenker in dit traject, weet de juiste vragen te stellen tijdens de oriëntatiefase en denkt mee over de oplevering. Zo ook Jason Schot, solutions architect bij Betty Blocks. Hij is gespecialiseerd in het vertalen van concepten naar concrete softwareoplossingen.

In dit artikel deelt Schot zes handige tips voor hoe bedenkers en projectmanagers samen kunnen optrekken om een idee succesvol tot wasdom te kunnen brengen. 

Les 1: Je herkent een goed idee aan de reacties

In de meeste gevallen wordt een goed idee gekenmerkt door herkenning bij de doelgroep. Dat begint bij het herkennen van het pijnpunt dat je probeert weg te nemen, maar er moet ook aansluiting zijn bij de oplossing. Wanneer oplossingen zeer complex zijn, is het de truc om de propositie eenvoudiger uit te leggen.

Indicaties van een goed idee zijn vaak sterke (emotionele) reacties, zowel positief als negatief, of wanneer mensen na uitleg van de propositie direct beginnen met meedenken aan de oplossing. Dit bevestigt namelijk dat het idee een bepaalde snaar heeft geraakt. 

Les 2: Vraag altijd door

Als solutions architect is het dus eerst van belang om tot de kern van het idee te komen. Een goede tactiek hiervoor? Je gedraagt je eigenlijk als een klein kind van vier. Dus je vraagt een heleboel keer ‘waarom?’ Er is een ongeschreven regel die stelt dat, als je zo’n vijf keer hebt gevraagd waarom, je pas tot de echte reden komt.

Vaak heeft de bedenker allerlei motivaties die zich onder het oppervlak bevinden. De ene klant heeft er meer moeite mee dan de ander om deze redenen kenbaar te maken. Soms moet je zelf met concrete voorbeelden komen om iemand aan het denken te zetten, om uiteindelijk tot de juiste conclusie te komen. Het belangrijkst is dat je een raakvlak vindt waarop je samen kunt voortborduren. 

Les 3: Begin bij het grote plaatje

Voor software geldt de regel: als je genoeg tijd en geld hebt, kan alles. Helaas is dit in de realiteit nooit het geval. Maar de limitaties zitten vaker in tijd en geld dan de techniek zelf.

Iedereen wil natuurlijk zo min mogelijk uitgeven en toch zoveel mogelijk bereiken. Vraag klanten daarom altijd eerst om al hun wensen en hun droomscenario te schetsen. Vervolgens kan worden gestript. Dan moeten er harde keuzes gemaakt worden. Maar idealiter begin je met ‘het grote plaatje’ en schaaft het vervolgens bij. 

Les 4: Visualiseer alles

Een plaatje zegt meer dan duizend woorden. Dat is helemaal het geval bij het ontwikkelproces. Visualisaties zijn essentieel om het idee voor een applicatie duidelijk te communiceren naar alle betrokkenen. Waar het het vaakst fout gaat is namelijk de communicatie – om te begrijpen wat de bedenker nou precies wil. 

De praktijk leert dat deelnemers tijdens hun eerste sessies heel goed denken te weten wat ze willen. Tijdens het verbeelden blijkt het echter nog knap lastig te zijn om te achterhalen wat ze precies voor zich zien. Begin daarom meestal met het uitwerken van flowcharts en wireframes:

Een flowchart behelst alle stappen die je kunt nemen binnen een applicatie. Het visualiseert hoe iemand zich door een applicatie beweegt. Op basis hiervan krijgt het idee iets meer gestalte en kunnen er wireframes worden gemaakt.

Wireframes zijn schematische tekeningen van hoe de applicatie er daadwerkelijk uit komt te zien. De wireframes halen een abstractielaag weg, die voor nog meer verheldering zorgt. Zo valt ineens alles op z’n plek en zie je waar de aanpassingen nodig zijn. 

Les 5: Wees open en transparant

Een solutions architect moet een brede kennis hebben van alle facetten van softwareontwikkeling – van het design en de techniek tot de zakelijke aspecten – en als schakel kunnen optreden tussen de verschillende stakeholders. De solutions architect moet kritisch zijn en (vervelende) vragen durven stellen, een groot verbeeldend vermogen hebben en snel kunnen schakelen. 

Elke afdeling heeft zijn eigen werkwijze, eigen jargon, en eigen stereotypes (die vaak waar blijken te zijn). Door jezelf te verdiepen en open te staan tegenover deze verschillende groepen, vergemakkelijk je de communicatie. Ook van belang is het behouden van transparantie tussen de projectmanager en de initiatiefnemer. 

Les 6: Faal snel en vaak

Check in elke fase van het project of je op de goede weg zit, of het klopt dat ze dit willen hebben, en itereer op je project. Verwacht niet dat je na de eerste bijeenkomst precies weet wat de bedenker wil. Dit proces betreft een continue feedback-loop. Want wat je anders krijgt, is dat je veel tijd en moeite steekt in iets dat uiteindelijk niet helemaal naar wens van de ‘klant’ is. 

Je kunt dus beter zo vroeg mogelijk met het feedbackproces beginnen. Het is een kwestie van vallen en opstaan, maar anders leidt het misschien tot kostbare fouten. Het is altijd eng om je ideeën te toetsen, maar het is beter dat je het vaak doet. 

Zoals wel eens wordt gezegd: ‘Fail fast and fail often.’ Van fouten maken leer je immers het meest. En je wilt dit zo snel mogelijk in het proces doen, want het gaat sowieso gebeuren – en dan liever te vroeg dan te laat.