Business analyse-deliverables spelen een essentiële rol in het slagen van projecten en succes van organisaties. Ze geven inzicht in behoeften, vormen richtlijnen voor beslissingen, documenteren, doen aan scope-beheer, zijn een meetlat voor kwaliteit, en ga zo maar door! We willen onze BA-deliverables naar een zo hoog mogelijk niveau tillen. En als het kan, door slimmer te werken en niet harder.
Dit doen we aan de hand van 4 lenzen. Dit was ook de leidraad van de webinar Optimaliseren van BA-deliverables.
De belangrijkste vragen en antwoorden die tijdens de Q&A-sessie aan bod kwamen, vatten we hieronder samen.
“
Hoe kijken jullie aan tegen de shift left-beweging waarbij developers & testers meer betrokken worden bij analyse?
“
Sorella
Test Team Lead
Eerst een toelichting naar wat de shift left-beweging in business analyse verwijst. Dit is een strategische benadering waarbij activiteiten en verantwoordelijkheden die traditioneel later in het project- of ontwikkelingsproces worden uitgevoerd, naar een eerder stadium in het proces worden verplaatst.
Antwoord
Ik kijk hier positief tegenaan omdat het volgens mij de algemene samenwerking bevordert. Iedereen heeft een eigen, specifieke rol in een organisatie en het doel van een shift left-beweging is niet om van een tester of developer plots een analist te maken. Maar ik ben wel overtuigd van de voordelen van T-profielen binnen een organisatie.
Een T-profiel is iemand die meer kennis heeft dan enkel diepgaande kennis van één expertisedomein. Een T-profiel combineert verregaande expertise in één of meerdere domeinen met een brede kennis van andere domein binnen het vakgebied. Zo heb ik als ontwikkelaar leren testen. Dit was in mijn eigen periode als ontwikkelaar, toen er nog software werd geschreven voor mobiele telefoons en er nog geen iOS of Android bestond. In die tijd mocht ik af en toe een basis analyse-taak uitvoeren en heb ik ook dingen getest. Op die manier leer je elkaars skills kennen en zorgt dit ook voor meer inzicht in elkaars werkveld, workload en time management.
Conclusie: ik ben fan van deze shift left-beweging. Op voorwaarde dat dit de samenwerking bevordert zonder dat medewerkers hun primaire skills niet meer kunnen onderhouden.
(Bert Heymans – senior business analyst)
“
Kunnen user stories als documentatie dienen? Ik zie dit deels als documentatie.
“
veronique
Functioneel Analist
Antwoord
Dit vind ik enkel het geval als er aan enkele voorwaarden voldaan wordt:
-
Het werk is effectief uitgevoerd zoals het is gedefinieerd in de user story.
-
De user story moet gekopieerd worden naar de plaats van je documentatie met een duidelijke context (zoals een datum, release of versie).
Wanneer een user story heel precies is, dan kan je twijfelen of het uberhaupt wel een user story is of eerder een taak.
Wanneer een user story heel uitgebreid is, dan kan het ook documentatie zijn die je aan het schrijven bent.
Daarom is het belangrijk dat bij de start van een project alle neuzen in dezelfde richting wijzen en iedereen hetzelfde verstaat onder een user story. Een user story is in deze context iets wat precies genoeg is maar ook niet te specifiek zodat er nog ruimte is voor de nodige creativiteit van de ontwikkelaar.
Een concreet voorbeeld van hoe je een user story kan inkleuren wanneer je eentje ontwikkelt voor een kortingscode:
· Zorg dat er een manier is om korting toe te voegen.
· Vermijd de kortingscode in detail te bepalen: in welk veld, op welke positie, in welk formaat, …
Dit is mijn advies wat betreft business analyse. Bij functionele analyse kan je meer in detail gaan. Om terug te komen op de initiële vraag of een user story als documentatie kan gebruikt worden, ook hier is het enkel zo als deze 100% is uitgevoerd zoals gedefinieerd. Dit kan bij een release bijvoorbeeld. Wanneer je een release gepackaged hebt en je zegt ‘dit zat in de release’. In dit geval kunnen die user stories voor een stuk als documentatie gebruikt worden.
(Bert Heymans – senior business analyst)
“
Die balans van Just enough persistente documentatie, zijn daar best practices van?
“
Sorella
Test Team Lead
Wat vooraf ging aan deze vraag:
Persistente documentatie is documentatie die aangepast is aan de werkelijke situatie nadat deze zich gestabiliseerd heeft. Bijvoorbeeld een proces dat werkelijk geïmplementeerd is.
Persistente documentatie moet ‘fit for purpose’ en weinig tijd kosten om te maken en onderhouden. Denk bij het maken vooral naar wie documentatie gaat, of zou kunnen lezen. Zo krijg je een scherp beeld van documentatie.
Nu, hoe weet je wat je persistent moet maken?
De vuistregel is om alleen die elementen persistent te maken die niet direct gerelateerd zijn aan de taakverdeling. Dus bijvoorbeeld user stories, taken en bugs maak je niet persistent.
Vanaf het moment dat je documentatie voor gebruikers maakt, kan je documentatie ook persistent maken. Dat is zo’n typische situatie waar ik al veel voordeel heb gehaald door te wachten op het gedrag van de gebruikers van het product. Daarna kijk ik waar de zwakke plekken zijn en dan ga ik die documenteren.
Dit is vaak het geval bij service requests voor een stuk software of wanneer er klachten zijn.
Een concreet voorbeeld hiervan: een interface waar je allerlei informatie moet invullen en als je niet op ‘save’ klikt, is het niet opgeslagen. Terwijl gebruikers ondertussen gewoon zijn dat ingevulde velden automatisch worden opgeslagen. Dat soort frustraties kwamen in een recent project naar boven. Toen zijn er warning signs geplaatst in de documentatie om op tijd op ‘save’ te klikken. De afweging die ik hier maakte, was snel een stuk documenteren voor alle gebruikers zodat er zich geen problemen voor deden. De betere optie is software optimaliseren maar dat kost veel middelen die we toen niet hadden.
(Bert Heymans – senior business analyst)
“
Wat als de klant moeite heeft om de wireframe of de mock-up toe te passen of requirements door te geven?
“
Philip
Functioneel Analist
Het komt inderdaad voor dat je input uit klanten moet sleuren. Onzekerheid ligt vaak aan de basis hiervan. Klanten weten niet goed hoever ze mogen gaan met hun vragen en feedback. Ze kunnen ook onzeker zijn over hetgeen ze aan het creëren zijn. De twijfel kan ook toeslaan over de uitvoerbaarheid van hun ideeën. Wanneer ik een situatie met deze insteek benader dan gebruik ik visualisering als oplossing.
Ik blijf in gesprek gaan met de klant, met een open houding. Ik stel de klanten op hun gemak en vraag door. Wanneer mogelijk toon ik de verschillende opties, dit helpt! Dit kan door te tekenen, wat ik heel graag doe. Maar het is ook bewezen dat het visualiseren van een concept of idee helpt om sneller concrete feedback te krijgen.
Wanneer je vlot kan werken met een wireframing tool dan kan je die gebruiken terwijl je in gesprek bent. Enkele wireframing tools waar ik fan van ben:
· Figma
· Axure
· Balsamiq
· Pencil
Tijdens het schetsen kan je meteen feedback vragen aan de klant en toepassen in het ontwerp, heel efficiënt! Het ontwerp hoeft daarom geen definitief ontwerp te worden, het gaat eerder om de informatie die het losweekt.
Een gouden tip, stel de vraag: “Staat hier iets in waar jij het niet mee eens bent?” In plaats van een open vraag te stellen zoals “Wat vind je hiervan?”. Door de vraag omgekeerd te stellen kunnen we werken op basis van uitsluiting en vermijden we antwoorden als ‘ziet er goed uit’. Net zoals een slotenmaker een slot probeert te openen, proberen we op verschillende plaatsen te kijken waar het klikt. En visueel werken is iets wat heel goed werkt hierbij.
(Bert Heymans – senior business analyst)
Nog vragen? Feedback? Get in touch!
Of volg ons via Linkedin om op de hoogte te blijven van upcoming webinars.
Our services
Uw ambitie? Een versnelling hoger schakelen. The Business Analysts geeft u een flinke duw in de rug.
