Het ontwikkelen van software en het achterhalen van requirements zijn onlosmakelijk met elkaar verbonden. Je kunt daarvoor verschillende technieken gebruiken, zoals bijvoorbeeld interviewen, observeren, prototyping of het onderzoeken van documentatie en klachten. Ook het organiseren van een workshop kan een effectieve manier zijn om snel requirements te achterhalen.
Immers, het organiseren van een workshop kost minder tijd, het stimuleert de onderlinge samenwerking tussen belanghebbenden, het verhoogt de team productiviteit en het leidt tot meer tevredenheid van klanten, gebruikers, ICT leveranciers en andere betrokkenen. Je zou bijna denken dat het alleen nog een kwestie is van doel, proces en deelnemers bepalen, ruimte en materialen regelen en uitnodigingen versturen.
Echter, in de praktijk blijkt het organiseren van een requirements workshop vaak lastiger dan vooraf gedacht. Maar al te vaak eindigt een requirements workshop in een soort ‘Poolse landdag’, waarbij deelnemers na afloop klagen dat ze hun kostbare tijd hebben verspild aan saaie en niet relevante discussies, dat de verkeerde mensen aan tafel zaten zodat er geen beslissingen konden worden genomen, dat steeds dezelfde paar mensen het hoogste woord hadden en/of dat het weinig tot geen nieuwe inzichten heeft opgeleverd.
Requirements workshops die mislukken hebben vaak één ding met elkaar gemeen: ze lijken te veel op een gewone vergadering. Wil je voorkomen dat je volgende requirements workshop opnieuw een gegarandeerde flop wordt? Vermijd dan in ieder geval deze zeven valkuilen:
1. Minimale voorbereiding
Requirements workshops vergen een intensieve voorbereiding en begeleiding door een neutrale facilitator, zodat de deelnemers via een logische volgorde van activiteiten gezamenlijk requirements opleveren met de juiste diepgang en kwaliteit.
2. Geen gezamenlijk doel
Achterhaal en communiceer vooraf duidelijk en expliciet wat de reden is om samen te komen. Welk resultaat moet na afloop van de workshop zijn behaald? Deze reden bepaalt namelijk welke deelnemers noodzakelijk zijn , welke vragen cruciaal zijn, welke discussies relevant zijn, welke activiteiten nodig zijn en welke producten opgeleverd moeten worden.
3. Niet de juiste (mix) deelnemers
Zorg dat alle groepen belanghebbenden evenredig vertegenwoordigd zijn, maar beperk de workshop wel tot zeven tot twaalf deelnemers. Wees dus selectief en kritisch, zodat daadwerkelijk de mensen met de juiste kennis, ervaring en invloed vrijgemaakt worden van hun dagelijkse werk. Dit kan veel tijd kosten. Schakel hiervoor dus tijdig de opdrachtgever van de workshop in.
4. Geen of te weinig tijd voor ‘huiswerk’
Requirements workshops vergen bijna altijd vooraf ‘huiswerk’ van deelnemers, zoals bijvoorbeeld het opstellen of doorlezen van concept documenten en modellen die als input dienen. Geef deelnemers voldoende tijd om zich voor te bereiden en maak hierover afspraken (zowel met de deelnemers als hun leidinggevenden).
5. ‘Veel geschreeuw en weinig wol’
Ontdek nieuwe, ontbrekende, onvolledige of tegenstrijdige requirements door deelnemers tijdens de workshop zowel visuele als tekstuele modellen te laten maken en verifiëren. Diagrammen zorgen voor snelheid en woorden voor nauwkeurigheid.
6. Weinig variatie
Gebruik verschillende werkvormen om de interactie, creativiteit, energie en deelname van iedereen te stimuleren. Varieer tussen activiteiten die deelnemers individueel, in kleine groepjes of met de hele groep uitvoeren. Breng waar mogelijk een spelelement of humor in.
7. Vage, impliciete of helemaal geen beslissingen
Zorg bij elke te nemen beslissing voor een duidelijk proces waarbij alle deelnemers betrokken zijn, én pas een duidelijke regel toe, zoals bijvoorbeeld besluit-na-discussie of consensus. Vergeet ook niet om de beslissing te documenteren: wie heeft wanneer welke beslissing genomen en welke regel is toegepast.
Heb je aanvullende valkuilen en tips voor een succesvolle requirements workshop? Laat dan hieronder een reactie achter. Alvast hartelijk dank daarvoor!
Met alle Respect, hier worden wel flink wat open deuren in getrapt. Ik kan mij nog wel wat kleine trajectjes herinneren, ergens eind jaren tachtig, die met dit onderwerp te maken hadden. We hadden niet eens het woord workshop uitgevonden maar waren o.m. bezig met Russen die ons kwamen uitleggen hoe cyrilisch script en fonts in software konden worden geintergreerd.
Dat waren gewone gesprekken en sessies die voor iedereen duidelijk waren. Het testen ging eenvoudig op afspraak waar een middagje werd getest of het was wat men wenste. Soms werden nog wat zaken bijgesteld.
Het was proces was zeer eenvoudig en iedereen begreep het procesje. Tegenwoordig vind men dat men van alles moet bedenken wat vooral klinkt als Ag(e)il(e) maar wanneer je weer eens naar de basis van het proces van toen gaat kijken er geen moer is veranderd.
Waarom dat zo is? Gewoon omdat de basis van IT, althans, waarop je IT neerzet, niet veranderd. Dat is vaak bediscussieerd en terzijde geschoven om telkens weer tot de conclusie te komen dat eenvoud gewoon toch het sterkkste blijft werken.
Leuk ene lijstje op te stellen waarom iets niet lukt, kom eens met een zeer eenvoudige lijst die de brug legt tussen IT en Non IT. En leg Non IT professionals dan vooral uit waarom je automatiseerd.
Echt… het kan…
De Metaplan techniek lijkt mij hierbij een leuke aanvulling. Door middel van concrete vraagtechnieken divergeren en convergeren. Deelnemers stimuleren, waarbij de voorbereiding (het draaiboek) erg belangrijk is. Leuk om te lezen dat veel van bovengenoemde punten ook gelden voor deze workshopvorm.
Op zich zelf vind ik het een logisch verhaal, tenminste voor het proces. Of product er ook mee verbeterd wordt lijkt me echter nog discutabel. Tenslotte wordt er nog weleens gerefereerd aan oude systeem – wat de boer niet kent dat lust hij niet – terwijl er wel vernieuwing verwacht wordt.
Ik heb nog wel een paar aanvullingen:
1. Zorg ervoor dat key spelers of belanghebbenden van te voren zijn ingelicht over het doel.
2. Zorg ervoor dat je een duidelijk doel hebt ten aanzien van de requirements, ga dus niet bestaande requirements opvragen, maar juist die requirements die aansluiten bij een nieuw of veranderd proces of de business wijziging of marktomstandigheid.
3. Zorg voor input van buiten, dus draag kennis aan van buiten over hoe het ook kan, probeer hiermee iedereen out of te box te laten denken.
4. Zorg voor terugkoppeling, dus organiseer een sessie waarbij de besluiten worden gecommuniceerd.
5. Wees hard voor mensen die zich niet hebben voorbereid, zet deze uit de workshop of verplaats de workshop.
6. Zorg voor een scheiding tussen functionele, business en non-functionele requirements.