Het klinkt wel leuk, complexe vraagstukken omzetten naar eenvoudige oplossingen, maar wat betekent dat nou eigenlijk in de praktijk? Voor mijzelf, als developer die al een behoorlijk tijdje mee loopt, is dat eigenlijk een soort tweede natuur geworden. Ik denk er zelden over na en heb me ook zelden afgevraagd hoe het process nu feitelijk verloopt. Toch krijg ik regelmatig terug dat mijn bijdrage in een dergelijk vraagstuk, zeer gewaardeerd wordt. Een interessant gegeven om eens onder de loep te nemen dus.

Orde scheppen in de chaos

Als er een organisatie langskomt om de ontwikkeling van een webapplicatie, platform of website te bespreken, dan is er daar intern hoogstwaarschijnlijk al veel overleg geweest. Men probeert meestal eerst zo goed mogelijk in kaart te brengen wat de wensen zijn voordat ze bij ons komen met een vraag. Die wensen zijn dan veelal gebaseerd op eigen (gebruikers)ervaringen of wat elders gezien is. Allemaal zaken waarvan gedacht wordt dat deze zeer belangrijk zijn en dus onmisbaar bij de ontwikkeling van een nieuw product zijn. De lijst met “must have’s” en “want to have’s” is veelal zeer divers. Dat varieert dan van design / vormgeving tot functionele wensen. Hoe dit gerealiseerd zal moeten worden is iets dat bij ons ligt en hier begint feitelijk direct al onze eerste opgave: het ordenen en wegen van alle wensen. We nemen de opdrachtgever hierbij aan de hand. We bespreken de mogelijkheden vanuit user-stories, de “do’s” en “dont’s”, de verschillende opties, en in mijn developers hoofd beginnen zich al voorzichtig de contouren van een nieuwe applicatie te vormen.

Iets wat nogal complex lijkt wordt opeens duidelijk en lijkt een stuk eenvoudiger!

Haalbaarheid

Een belangrijk punt bij ieder project is de haalbaarheid. Dit geldt vooral voor de planning en budget. De opdrachtgever wil zo veel mogelijk van zijn plannen realiseren, maar als daar ook een vastomlijnd budget bij gegeven wordt moeten er keuzes gemaakt worden. We kunnen van een opdrachtgever niet verwachten dat deze keuzes helemaal zelfstandig gemaakt worden, omdat sommige vragen eenvoudig lijken maar lastig te realiseren zijn en sommige vragen ingewikkeld lijken maar relatief eenvoudig te bouwen zijn. Wij komen in de voorgesprekken dan met voorstellen om onderdelen wel of niet te op te pakken en kunnen vaak bepaalde zaken net iets anders / eenvoudiger doen. Hierdoor kan het opeens een stuk haalbaarder worden en toch dicht bij de gewenste functionaliteit blijven. 

Ons doel is altijd om zo veel mogelijk van wat de opdrachtgever wil ook te ontwikkelen binnen de tijd en het budget dat gegeven is.

Al deze communicatie in het voortraject leidt uiteindelijk tot een begrijpelijk functioneel ontwerp, een grafisch ontwerp, een planning en een uiteindelijk budget. Dit is dan de “blauwdruk”, ofwel “scope”, van de nieuwe applicatie. Het bouwen kan beginnen!

De regels veranderen tijdens het spel

Je eerste gedachte als developer is natuurlijk dat je liever niet wil dat er tijdens het project te veel veranderd. Als er iets veranderd aan de scope van het project dan heeft dat meestal ook zijn effect in de planning en vaak ook in het budget. Het is echter gebleken dat er toch altijd van alles tijdens de ontwikkelfase veranderd wordt, daar doe je niet veel aan. 

Doordat een opdrachtgever aan het begin van een traject vaak wat minder goed de gehele “scope” van het project kan overzien, gebeurt het soms dat hij of zij, zodra de applicatie wat vorm begint te krijgen, meer nieuwe inzichten krijgt tijdens het bouwen. Van het één komt dan het ander en de ideeën komen dan ook op gang. Voortschrijdend inzicht noemen we dat. Andersom komt dat natuurlijk ook voor, ik kan vooraf gedacht hebben dat het handig is om iets op een bepaalde manier te ontwikkelen maar gedurende het process kom ik er achter dat ik het toch beter net wat anders kan aanpakken. In deze fase is het dus heel belangrijk om open en transparant te blijven overleggen, want hoe minder verrassingen, hoe positiever iedereen tijdens het hele process blijft!

Het is heel belangrijk dat wij, tijdens het ontwikkelen van een applicatie, het overzicht bewaren, de “scope” bewaken en steeds weer analyseren of we aan het ontwikkelen zijn wat oorspronkelijk ook de bedoeling was. Het voortschrijdend inzicht moet dus altijd gewogen worden ten opzichte van het gehele project. Soms is voortschrijdend inzicht ook gewoon hartstikke goed en hoewel het duurder zou kunnen worden en langer kan gaan duren is het mogelijk dat er dan toch door de opdrachtgever besloten wordt om zo’n aanpassing mee te nemen.

Communicatie is belangrijk, joh… echt? 

Wat is nou mijn conclusie eigenlijk?

Mijn ervaring is dat met goed luisteren en begrijpen wat een opdrachtgever vraagt, de oplossing vaak net anders kan zijn dan aanvankelijk gedacht. Op het moment dat ik als developer denk dat ik een onmogelijke vraag krijg, dan weet ik inmiddels dat ik eerst nog eens beter moet luisteren. Hoewel de opdrachtgever wellicht niet zo’n technisch inzicht heeft als ik, zijn de vragen meestal zeer legitiem. Flexibiliteit, meedenken en elkaar proberen te begrijpen is feitelijk de basis van een “eenvoudige oplossing” en leidt niet zelden tot een beter eindresultaat. Mocht je het onverhoopt toch een keer echt niet eens zijn met de inzichten van een ander dan moet je zorgen dat je jouw gelijk goed kunt onderbouwen en dan blijkt het toch meestal weer te lukken om op één lijn te komen. Het gemeenschappelijk doel blijft altijd om een perfect product op te leveren. Een product waar de opdrachtgever blij mee is, en waar wij trots op zijn dat we het gemaakt hebben!

Geschreven door Niels Meijer, Lead Developer bij Eenvoud