Realistisch ontwikkelen

Te vaak gaan web-projecten mis in de late fase van ontwikkeling, vaak zelfs terwijl het eindstation in zicht is en alle betrokken partijen de beste intenties hebben. Hoe kunnen dergelijke problemen voorkomen worden? Dat is de vraag die in dit artikel centraal staat. De basis van het probleem is naar mijn mening terug te voeren op twee verschillende onvolkomenheden:

1) Bugs: dit zijn fouten waardoor een applicatie niet werkt als ontworpen.

2) Afspraken: dit zijn fouten waardoor een applicatie niet werkt zoals de klant het in gedachte had (managen van verwachtingen).

Het is de tweede soort die ik hier wil bespreken. Een klant gaat een ontwikkelingstraject in met een bepaalde gedachte/verwachtingen. De applicatie moet iets kunnen, mensen activeren, moet op een andere applicatie lijken, moet een bepaalde doelgroep aanspreken of moet een bedrijfsproces veranderen. In een ideaal geval zou de klant deze wensen perfect aan de programmeur kunnen communiceren en zou deze de kennis bezitten om dit alles in een applicatie te zetten.

Er zijn echter een aantal problemen, de eerste en misschien wel de belangrijkste is puur psychologisch. Een klant weet waarschijnlijk niet precies wat hij wil en kan pas duidelijk aangeven wat hij niet wil bij het zien van een voltooide applicatie.

Een tweede probleem is de communicatie van de wensen van de klant naar de personen die verantwoordelijk zijn voor de ontwikkeling van de software om zo afspraken te maken. Ook hier speelt psychologie een belangrijke rol; het gaat niet om communicatie van keiharde afspraken. Voor veel webapplicaties zijn gevoel en uitstraling van belang, dit is lastig over te brengen en af te spreken.

De laatste stap is het omzetten van de afspraken naar een werkelijke applicatie, fouten die in dit proces optreden zijn in principe bugs en worden hier niet besproken.

Het voorkomen van onduidelijke afspraken is dus alleen mogelijk als een klant goed bewust wordt van wat zijn wensen echt zijn en als deze wensen goed omgezet worden in afspraken. Omdat niet elk softwarebedrijf een psycholoog in dienst heeft om deze geestes-processen te leiden, moeten er andere oplossingen gezocht worden. Hieronder staan een aantal suggesties die ik als nuttig heb ervaren en die samen wellicht niet een compleet beeld van de wensen van de klant geven, maar in ieder geval een realistisch beeld geven van hoe het beter kan.

In de ontwerpfase is je gulden een daalder waard

Besteed genoeg tijd aan het praten met klanten en het overleggen van de applicatie. Het lijkt soms dat dit teveel tijd in beslag neemt maar bedenk dat elk uur dat je hieraan besteed het risico verkleint op ellenlange vertragingen aan het eind van het project waar onduidelijke afspraken voor tientallen uren (of meer) overleg kunnen opleveren. Het gaat om beeldvorming en pas als zeker is dat klant en leverancier hetzelfde beeld hebben kan de volgende fase gestart worden. Tevens pleit ik voor een ontwerpfase die losgekoppeld is van de rest van de opdracht. Mocht er uit deze fase blijken dat iets duurder wordt, niet kan of juist goedkoper wordt, dan hebben beide partijen nog de mogelijkheid om de relatie te beëindigen.

Duidelijkheid boven geld

Meer tijd besteden aan de ontwerpfase is moeilijk te verkopen, het klinkt nou eenmaal niet logisch om een klant te vertellen dat je denkt een applicatie te kunnen ontwikkelen maar dat hij eerst maar eens moet betalen om het zeker te weten. Geld moet rollen en de wereld van een verkoper is snel en dynamisch, zeker als er concurrentie is. Toch moet een offerte zorgvuldig worden opgesteld maar boven dat moet een ontwerpfase ten allen tijden apart in een dergelijke offerte staan. Als een klant hier niet mee akkoord kan gaan is deze niet op zoek naar een serieuze applicatie. Breng je zelf te snel een offerte uit of plan je geen ontwerpfase in dan verkoop je iets zonder dat je weet of je het voor die prijs kan leveren.

Het gevaar van de vanzelfsprekendheid

Ik merk maar al te vaak dat ik in het contact met een klant wel denk te weten wat hij of zij wil. De klant denkt op zijn of haar beurt dat het wel goed komt. Dit is waar het grote gevaar ligt, met geen mogelijkheid kan je op zo’n moment bedenken waar de afspraken nog niet waterdicht zijn. Als je echter om de tafel gaat zitten en de details van het project gaat bespreken, blijkt dat de gedachtes niet zo op een lijn liggen als men dacht. Dit is wat mij betreft het gevaar waar de projecten in de eindfase op falen. Waarom zou je nog verder ingaan op afspraken als beide partijen tevreden zijn? Het antwoord moge voor zich spreken.

De virtuele applicatie

In mijn ervaring is meestal voldoende gedocumenteerd hoe een applicatie gaat werken en er uit komt te zien. Het probleem is echter dat een klant aan de hand van die documentatie geen beeld kan vormen van de applicatie die geleverd gaat worden. Kennelijk zijn de huidige middelen dus niet toereikend genoeg om goede afspraken met klanten te maken. Dit betekent niet dat functionele en technische ontwerpen niet nuttig zijn, maar als basis voor het vastleggen van de afspraak tussen klant en leverancier zijn ze niet voldoende.

De functie van de leverancier is het prikkelen van de klant tot nadenken over de applicatie die ontwikkeld moet worden. Er moet een proces ontstaan waarin de klant wordt aangezet tot het echt verwoorden van de visies, verwachtingen en doelen. In samenspraak met de leverancier moeten de randvoorwaarden voor de applicatie gesteld worden. Bedenk hierbij dat de wensen van de klant redelijk diep kunnen zitten en niet altijd makkelijk uitgesproken worden.

De methode om dergelijke verlangens boven tafel te krijgen is lastig en niet eenduidig, maar vraag een klant bijvoorbeeld hoe een typische gebruiker de applicatie moet doorlopen of wat hun wensen niet zijn. Stel scenario’s voor waarvan je weet dat ze te duur zijn. Wees creatief, het proces gaat om het begrijpen van elkaar. Pas als duidelijk is hoe de applicatie er in het hoofd van de klant uitziet kan deze bekaderd worden door technische en budgettaire beperkingen.

Out of scope

Aan het eind van een ontwerpfase is vaak wel ongeveer duidelijk wat een klant wil en waar de knelpunten liggen. Het blijkt echter dat deze dan niet meer het hele functionele ontwerp door zal lezen. “Het is toch al besproken”. Vermeld daarom duidelijk in de communicatie over een uiteindelijk ontwerp wat er niet gaat gebeuren, wat buiten de scope van het project ligt. Dit komt soms hard aan maar is de enige manier om zeker te weten dat er geen misverstanden ontstaan.

Het bovenstaande proces lijkt ingewikkeld en is slechts een manier van de zaken regelen. Het is echter goed om hierover na te denken. Er gaat niet alleen veel geld en frustratie zitten in misgelopen projecten, er kan zoveel meer bereikt worden als er maar even de tijd voor genomen wordt.

Willem Bongers

Voor meer informatie over dit artikel; neem contact >> met ons op.