Business Analist: de ongeziene, maar cruciale ‘linking pin’
‘Je gaat het pas zien als je het doorhebt’
Deze Cruijffiaanse uitspraak geldt ook voor de meerwaarde van een Business Analist. Vaak wordt pas gedurende projecten of achteraf duidelijk wat de rol kan betekenen en hoe Business Analisten zelfs cruciaal kunnen zijn voor een succesvol resultaat en helpen om dure fouten te voorkomen. Onze Business Analisten Rick en Yonas gaan in op hun positie als ‘linking pin’, delen praktijkervaringen en vertellen waarom nieuwsgierigheid een onmisbare eigenschap is voor deze functie.
Kloof tussen Business en IT
“Als voorheen een technische oplossing moest worden gebouwd werd over het algemeen al snel naar de IT-afdeling gekeken”, begint Rick. “Vanuit de business werd aangegeven wat nodig was en IT ging op z’n eigen eilandje aan de slag. Vaak met een resultaat dat niet of slechts gedeeltelijk voldeed aan wat de business had gevraagd. Niet vanuit onwil, maar puur omdat beide werelden te ver uit elkaar lagen en er geen adequate vertaling was van de wensen naar een concrete vraag aan IT. Ook was er tijdens het ontwikkelen van de oplossing weinig interactie en dus geen bijsturing op het resultaat.”
Om deze kloof tussen IT en de business te overbruggen wordt nu bij projecten voor software-ontwikkeling regelmatig een Business Analist ingezet. Volgens Yonas is het in deze rol belangrijk om helemaal open een project in te gaan, niet te snel naar een oplossing te gaan en vooral veel vragen te stellen. “Zelfs als er concrete vraag is, kan de bedachte oplossing niet het beste antwoord op het probleem zijn. Daarom is het essentieel mensen uitgebreid te bevragen over het waarom.”
Five Times Why
Rick werkt daarvoor met de ‘Five Times Why-methode’: “Daarmee kom je pas tot de kern van het probleem en achter de echte beweegredenen. Veel projecten beginnen met een doel dat onduidelijk is. Zo kan er in beginsel behoefte zijn aan een app, maar kun je tot de conclusie komen dat er eigenlijk eerst een procesverbetering nodig is om de juiste oplossing te kunnen bouwen. Je moet dus nieuwsgierig zijn, altijd dingen blijven bevragen en niet uitgaan van de status quo. Dit is een belangrijke meerwaarde die je vanuit je rol levert. Ook helpt het hebben van ervaring en domeinkennis om in deze fase de juiste vragen te kunnen stellen.”
Yonas: “Als het centrale doel duidelijk is, ga je in gesprek met verschillende stakeholders om user stories te formuleren. Wie gebruiken de oplossing allemaal, welke wensen hebben deze gebruikers of welke wensen zouden zij nog meer kunnen hebben? Ook wordt hierin een prioritering aangebracht. Wat zijn must-haves en wat zijn nice-to-haves? Vervolgens ga je aan de slag om de vereiste functionaliteiten (requirements) te analyseren en concreter te maken. Omdat je als Business Analist ook technische kennis hebt, kun je heel goed meedenken wat realistisch is. Het gaat dus niet alleen om het ophalen van de functionele eisen, maar je probeert direct te bedenken of het technisch ook mogelijk is.”
Download het een workshop template!
Fundament onder het succes
“De eerste stappen van het uitvragen en het vaststellen van de behoeften is het fundament onder het succes van ieder project”, vindt Rick. “Ik heb dikwijls gezien wat de gevolgen zijn als je dit niet of te snel doet. Als Business Analist word je dan pas later in het traject ingeschakeld en moet je het ontspoorde project weer op de rails krijgen. Dit terwijl je idealiter direct vanaf de start deel uitmaakt van het Scrumteam van een project.”
Yonas: “Ik werd eens betrokken bij een project voor een platform dat al was opgeleverd, maar niet aansloot bij hoe het proces in de praktijk werkte. De flows vanuit de gebruikers liepen niet en er mistten essentiële zaken. De user stories waren niet goed beschreven en ook waren de juiste mensen niet betrokken, waardoor de belangen van alle stakeholders niet voldoende werden behartigd. Het vereiste veel extra werk en extra budget om functies toe te voegen en het platform alsnog passend te maken. Dit is een situatie die je natuurlijk het liefst wil voorkomen.”
“Onze rol is redelijk onbekend en dus ook vaak onbemind”, zegt Rick. “Het is dan ook niet vanzelfsprekend dat een Business Analist wordt ingeschakeld, omdat men simpelweg (nog) niet inziet wat deze persoon zou kunnen betekenen. Doorgaans wordt ook pas achteraf duidelijk wat de meerwaarde was en hoe we hebben geholpen om op een gedegen en gestroomlijnde manier binnen de gestelde planning een product op te leveren dat naadloos aansluit bij de wensen. Hiermee verdien je jezelf al snel terug voor een organisatie. Daarom loont het om in het begin van een traject te investeren, zodat je niet onderweg alsnog struikelt en het project zowel de deadline als het budget overschrijdt.”
Het houdt niet op bij de requirements
Na het vaststellen van de behoefte en opstellen van de requirements aan de ontwikkelaars zit de taak van een Business Analist er nog niet op. “Het is juist het spel van bedenken en corrigeren. Je blijft dus continu betrokken bij het proces”, benadrukt Yonas. “Zo kunnen er issues zijn tijdens het ontwikkeltraject. Het is dan de verantwoordelijkheid van de Business Analist om dit te communiceren en om alternatieven voor te stellen. Je moet zorgen dat de trein blijft rijden en ontwikkelaars en de business op hetzelfde spoor blijven. Waarbij hetgeen dat wordt opgeleverd aansluit bij hetgeen dat wordt verwacht.”
“De rol van Business Analist is juist zo aantrekkelijk, omdat je zo nauw betrokken bent en echt een sleutelrol vervult in projecten. Je kiest geen kant, maar zit ertussen om te zorgen dat er een zo goed mogelijk antwoord ligt op het probleem waar iedereen blij mee is. Dit is voor mij nog steeds magisch”, besluit Rick.
Wil je meer weten over requirements engineering of wat onze Business Analisten voor jou kunnen betekenen? Ik vertel je graag meer!
