5 fouten om te vermijden als functioneel analist

De belangrijkste taak van een functioneel analist? Goede requirements opstellen. Maar laat dat nu net niet zo gemakkelijk zijn. Requirements veranderen, of evolueren mee met de wensen van stakeholders, verschillende teams gaan ermee aan de slag… Het is een hele uitdaging om hiermee om te gaan en om je project tot een goed einde te brengen. Daarom wijzen we je op 5 situaties waar het vaak fout loopt, en hoe je deze valkuilen kan vermijden.

1. Essentiële requirements missen

De klant wil natuurlijk dat een app of software een echte meerwaarde vormt voor gebruikers, maar hoe precies, daar heeft hij het soms moeilijker mee. De klant kan moeite hebben met het doel in woorden om te zetten, of erger nog, halverwege het project het doel veranderen. Als functioneel analist moet je vóór de development fase de functionele en niet-functionele requirements vastleggen. Definieer duidelijk het probleem en hoe je dat op een effectieve manier gaat oplossen.

2. Stakeholders zijn niet akkoord

Druk, druk, druk… zo gaat het nu eenmaal vaak. Al je stakeholders ervan overtuigen om meerdere vergaderingen bij te wonen is niet gemakkelijk. Nochtans is het essentieel dat de stakeholders feedback geven over de requirements en hun akkoord geven aan het begin van het project. Anders riskeer je dat je met verkeerde requirements van start gaat.

3. Nuttige informatie gaat verloren

Afhankelijk van de grootte en de complexiteit van je project, werk je samen met (grote) teams van functioneel analisten en businessanalisten om de nodige informatie te verzamelen. Als iedereen een verschillende aanpak heeft, of als er geen consistentie bestaat in het opslaan van informatie, is het moeilijk om het overzicht te bewaren. Zorg dus dat je hier op een goed georganiseerde manier mee omgaat. Anders riskeer je de foute prioriteiten te kiezen, wat ook invloed heeft op je requirements.

4. Te veel informatie

Requirements in de vorm van ellenlange tekst komen hopelijk niet al te vaak meer voor. Lange teksten naar stakeholders sturen is vaak contraproductief. Het nodigt niet uit om te beginnen lezen, en als er niet aandachtig naar de inhoud gekeken wordt, kan het leiden tot misverstanden. Zorg er dus voor dat iedereen die betrokken is bij je project toegang heeft tot duidelijke, behapbare informatie.

5. Slechte communicatie

Om het best mogelijke eindresultaat te behalen moet je helder communiceren met alle betrokken partijen, van developers tot testers tot eindgebruikers. Visualiseer workflows en requirements om er tweezijdige conversaties over te kunnen hebben met de stakeholders. Verzamel feedback en maak deze toegankelijk voor iedereen die bij het optimalisatieproces betrokken is. En tot slot, stroomlijn alle onderlinge communicatie zodat er geen informatie verloren gaat in het proces.

De oplossing? Een prototype!

Door gebruik te maken van een prototype kan je deze valkuilen vermijden. Als je het goed gebruikt, kan een prototype namelijk een sleutelrol spelen om je project tot een goed einde te brengen. De voordelen?

• Een prototype biedt ondersteuning bij het opstellen van de requirements omdat je specifieke functies kan visualiseren. Bovendien helpt het je om ontbrekende requirements te identificeren en herhalingen van dezelfde functies te voorkomen.
• Stakeholders kunnen zelf aan de slag met het prototype. Zo krijgen ze een beter begrip van de requirements zonder tijd te verliezen met vergaderen.
• Dankzij een werkend prototype kan je problemen in de beginfase van je project opsporen en aanpakken. Dat resulteert in nauwkeurige requirements.
• Al je requirements zijn opgenomen in je prototype, en je kan er eenvoudig nieuwe aan toevoegen. Het is dus een manier om georganiseerd te werk te gaan.
• Een werkend prototype is de ideale manier om met zowel de klant als testers en stakeholders te communiceren. Je kan er feedback opslaan in de vorm van comments en workflows visualiseren.

Bron: businessanalystlearnings.com