Duidelijk toch? Toch maar even vastleggen!

Ik zie het vaak gebeuren en misschien is het wel herkenbaar: er is hard (over)gewerkt om een nieuwe app of website op tijd op te leveren, maar de opdrachtgever is niet eens blij! Bij oplevering blijkt dat er iets heel anders werd verwacht. Dat is vervelend voor de maker en voor de opdrachtgever, maar is er iets te doen om dit een volgende keer te voorkomen?

Misschien is het duidelijk wat er gemaakt moet worden, maar dan is het vast ook niet moeilijk om dat op te schrijven.

Misschien is het duidelijk wat er gemaakt moet
worden, maar dan is het vast ook niet moeilijk om
dat op te schrijven.

Verwachtingen managen
Het voor de hand liggende antwoord is dat je de verwachtingen vooraf moet managen – verwachtingen over tijd, geld en inhoud. In deze blogpost wil ik stilstaan bij het managen van de verwachtingen over de inhoud, hier gebruiken we in de IT meestal requirements voor.

Geanimeerd voorgesprek
Soms hoor ik weleens dat het niet nodig is om de requirements vast te leggen. “Het is toch duidelijk wat je moet maken?”, wordt dan gezegd. Misschien is het inderdaad helemaal duidelijk, maar dan kan het vast ook niet moeilijk zijn om de inhoud even op te schrijven, toch? Vaak genoeg heb ik meegemaakt dat bleek dat we elkaar in dat geanimeerde voorgesprek toch niet helemaal goed hadden begrepen. Vergeet niet dat de kosten van het oplossen van fouten steeds hoger worden, naarmate je verder komt in het ontwikkelproces. Een fout in de requirements is zo aangepast, maar het wordt snel vele malen duurder om dezelfde fout op te lossen als je er pas achter komt bij het testen.

requirements-opschrijven1

Een fout wordt snel vele malen duurder om op te
lossen als je er pas achter komt bij het testen.

Kwaliteit als eis
Inhoud kent nog een andere dimensie. Performance kan bij GIS-systemen door de hoeveelheid data een aandachtspunt zijn, reden om het hier vooraf eens over te hebben. Dit zijn de kwaliteitseisen, ook wel non-functional requirements genoemd. Hoe lang mag het openen van deze kaartlaag duren bij deze extent en op dit schaalniveau? Soms wordt er gemakkelijk vanuit gegaan dat security een verantwoordelijkheid is van de IT-afdeling, maar het is verstandig er op zijn minst eens over te hebben met wat voor user id de gebruikers moeten inloggen. Het klopt, dit zijn vaak moeilijk grijpbare onderwerpen. Maar als bij oplevering blijkt dat de opdrachtgever niet tevreden is met de kwaliteit (performance, security, usability, etc), dan heb je vaak een probleem dat zich veel moeilijker laat oplossen dan een bug in een functie.

Eenvoudig beginnen
Mijn advies is om eenvoudig te beginnen. Kijk wat werkt voor het soort projecten dat u doet. Een ding is zeker: als bij uw volgende project de requirements worden vastgelegd, dan hebben u en uw opdrachtgever alvast een verrassing minder bij de oplevering.

Dit bericht is geplaatst in ArcGIS, Developer en getagged , , , . Bookmark de permalink.

1 Comment

  1. Kan mij volledig vinden in dit artikel en mensen die beweren dat requirements niet nodig zijn en dat het toch duidelijk is zouden eigenlijk verbannen moeten worden uit de ICT wereld of, op zijn minst, niet serieus mogen worden genomen. Heb zelf ooit gebruik gemaakt van een requirement mgmt tool (Caliber) én requirements in detail met een Duitse klant besproken en heb daar oa het volgende geleerd:
    – identificeer je requirement met een unieke identifier zodat je daar altijd op kan terug vallen
    – schrijf je requirements liefst uit tot op het laagste niveau zodat een requirement niet nog kan worden opgesplits in sub-requirements.