Wat & Hoe
Dat waren ooit, ver voor de tijd van de vertaal-apps, handige boekjes voor op vakantie. Toen ik bezig was met ideeën voor een eerste blog over requirements, bedacht ik me dat het daar bij requirements eigenlijk om gaat. WAT hebben we nodig (functionele requirements), en HOE moet dat dan werken (niet-functionele requirements), niet meer en niet minder. Het probleem is alleen om er, op tijd, achter te komen en het zo te verwoorden dat het voor iedereen duidelijk is. Een vertaaldingetje dus! De business analist is al op diverse manieren getypeerd, maar zelf heb ik altijd wel een lichte voorkeur voor de rol van tolk gehad. Je spreekt de taal van de business en je kunt dat vertalen naar de taal van de IT-ers; met andere woorden je begrijpt WAT er nodig is en je weet HOE je dat moet doorgeven.
Daarbij zijn een aantal zaken van belang, die taal van de business, die is opgebouwd uit domeinkennis, jargon, mensenkennis én vakkennis. Je moet namelijk weten, hoe je ervoor zorgt dat je met de juiste mensen om tafel zit, hoe je van hen de juiste antwoorden krijgt en hoe je hen betrekt bij het project. Ook hier is wat en hoe weer de kern, WAT moet je weten en HOE krijg je dat voor elkaar. Een van de vragen die het meest worden gesteld bij requirements trainingen is: Wanneer zijn mijn requirements goed genoeg. Het antwoord daarop is helaas niet zo eenduidig als gehoopt; er is geen template voor. Hiervoor is het van belang dat de business analist de juiste ‘taal’ beheerst. In mijn ‘Wat en Hoe lijstje’ staan hiervoor wel wat tips.
- Doe een stapje terug en kijk holistisch naar de gestelde vraag; wat is er naast IT nodig, hoe zit het met de processen, de organisatie, de mensen; maar ook: over welke data gaat het, op welk platform moet het werken, waar past dit binnen de architectuur.
- Doe sessies in de vorm van gefaciliteerde workshops, waarbij alle betrokken partijen (business, gebruikers, design/development, testen) betrokken zijn. Door meerdere partijen te betrekken, is het risico op verrassingen achteraf een stuk kleiner.
- Werk in iteraties; het is een illusie dat je alles in één keer kunt verzamelen en zo op papier zetten, dat je er daarna nooit meer op terug hoeft te komen. Maak per iteratie, of per sprint, duidelijk wat er op dat moment de meeste waarde heeft, en zorg dat je dat volledig uitwerkt.
- Gebruik een tool, en liever niet Excel of zo, want je wilt van je requirements hun gehele lifecycle vastleggen, van het eerste idee, dat ooit als een schets tijdens een workshop is getekend, tot de gehele set aan (non-)functionals die nodig is voor realisatie. Door een tool te gebruiken, die niet alleen de historie van het requirement bijhoudt, maar waarmee je ook nog eenvoudig relaties kunt leggen, tussen requirements, tekeningen, modellen, software, tests, voorkom je dubbel werk, kun je eenvoudig controleren of je volledig bent, kun je de scope bewaken, kortom dit bespaart je veel gezoek en gedoe.
- Modelleer; teken, schets en maak uiteindelijk modellen die begrijpelijk zijn. Door functionaliteit beeldend te maken, door bijvoorbeeld processen te tekenen of door een scherm te schetsen, zien mensen fouten, omissies of verbeteringen veel sneller, dan wanneer dit is beschreven in tekst. Betrek hierbij ook de ontwerpers en de testers, zij kunnen waardevolle toevoegingen doen. Daarnaast helpen modellen ook als input voor het ontwerp, het is een ideaal vertaalmiddel. Let hierbij wel op, zorg dat je de modellen toont in de juiste taal; geen volledig uitgewerkte datamodellen voor de business, zij hebben voldoende aan een logisch datamodel en geen losse schetsjes voor de designers, zij hebben behoefte aan meer informatie.
In een vogelvlucht staan hier wat ‘vertaaltips’ op het gebied van requirements. Over WAT je hiermee bereikt en HOE je dit in de praktijk kunt toepassen meer in een volgend blog.
