Neem contact met ons op
+31 (0) 88 000 54 00
info@divetro.nl
Volg ons op LinkedIn
DiVetro BV
Villa de Reehorst
Hoofdstraat 20A
3972 LA Driebergen-Rijsenburg
The Netherlands
Een goede analist moet keuzes durven maken

Een goede analist moet keuzes durven maken

Richard Hilekes en Dennis Geluk

Binnen DiVetro hebben we de afgelopen 10 jaar verschillende trends gezien en veel inzichten opgedaan op gebied van analyse.

Een van deze trends is dat analisten voortdurend meer documentatie voor interne en externe stakeholders moeten verzorgen. Dit wordt althans van ons verwacht.

Een van onze inzichten is dat je hier als analist voorzichtig mee moet omspringen. Je kunt het immers niet iedereen naar de zin maken. Een interessant en actueel spagaat!

Een analist is geen documentalist

Wanneer er in een software-ontwikkeltraject over documentatie wordt gesproken dan wordt er vaak direct naar de analist gekeken. Wij zien dat analisten geregeld “misbruikt” worden als documentalisten.

Zo roept de architect dat zijn eisen ook opgenomen moeten worden in de requirements. De tester wil een activity diagram om mogelijke flows te herkennen. De programmeur heeft voor een specifieke implementatie gekozen en wil deze gedocumenteerd zien. En uiteraard wil de product owner dat zijn wensen tot user stories worden verwerkt.

“Scope creep” bij de analist

De verwachtingen ten opzichte van het takenpakket van analisten lijken altijd verder te gaan. De verantwoordelijkheden van analisten bijgevolg ook.

Wij merken dat analisten ook steeds vaker (bewust of onbewust) de rol van documentalist toegeschoven krijgen. Steeds meer partijen verwachten dat wij als analisten meteen ook alle belangrijke informatie van een project vastleggen in verschillende vormen van documentatie.

Analisten zijn de schakel tussen diverse disciplines op gebied van functionaliteit en techniek. Analisten, zo wordt verwacht, kunnen deze twee werelden verenigen met informatie en begrijpelijke modellen.

En analisten, zo blijkt, kunnen meestal moeilijk nee zeggen tegen dergelijke verzoeken.

Hoe bewaak je als analist je verantwoordelijkheden?

Stel: in je volgende project wordt er van je verwacht dat je alle documentatie voor de verschillende stakeholders verzorgt. Vanuit je vakgebied behoort dit echter niet tot je primaire takenpakket. Sterker nog: door deze extra taken zouden je analyse werkzaamheden wel eens negatief beïnvloed kunnen worden door de hoeveelheid tijd die je als documentalist moet gaan besteden.

Hoe ga je als analist om met het verzoek om extra (niet analyse gerelateerde) documentatie te leveren? Wij zien twee belangrijke factoren die je als analist kunnen helpen om de juiste keuze te maken:

1.   Zoek houvast bij de ontwikkelmethodiek en verantwoordelijkheden

De uitgangspunten van een ontwikkelmethodiek kunnen je helpen bij je afweging om al dan niet bepaalde documentatie te maken. Het kan je ook helpen om te bepalen tot welk detailniveau je eventuele documentatie wilt uitwerken.

Wanneer je als analist deel uitmaakt van een Agile/Scrum ontwikkelteam dan gaat het er niet om dat er allerlei soorten documentatie gemaakt moet worden. Bij Agile/Scrum is het vooral belangrijk om op het juiste moment de juiste documentatie met de juiste diepgang te maken. Informatie dus waar je team op dat moment behoefte aan heeft en waar je team op dat moment mee uit de voeten kan.

De verantwoordelijkheden binnen de methodiek kunnen je helpen om te bepalen wie in eerste instantie verantwoordelijk is voor welk stukje informatie. Zo is de product owner verantwoordelijk voor het opstellen van de user stories, de scrum master voor de eventuele voortgangsinformatie/verslaglegging richting management, testers voor het uitwerken van testscenario’s en analisten voor het vastleggen van functionele (en niet functionele) requirements. In de finetuning van deze documentatie kun je als analist uiteraard wel een rol spelen. Dat versterkt het begrip in het team alleen maar.

Bij een traditioneel watervalproject zijn er vooraf vastgestelde deliverables die je als analist moet opleveren. De verantwoordlijkheden van alle disciplines zijn dan vaak duidelijker afgebakend dan bij een Agile project. Tevens wordt er serieel gewerkt en niet parallel. Eerst wordt de architectuur uitgewerkt, vervolgens het functioneel ontwerp, technisch ontwerp en test. Wanneer dit allemaal is afgestemd volgt pas de ontwikkeling.

Ons advies: Houd vast aan de verantwoordelijkheden tussen de verschillende disciplines van je projectteam. De opsplitsing en fasering van deze verantwoordelijkheden kan variëren op basis van de ontwikkelmethodiek die binnen het project gehanteerd wordt. Verzorg de documentatie die je als analist moet verzorgen en help je teamleden waar je kunt wanneer je je primaire taken naar tevredenheid uitgevoerd hebt.

2.   Bekijk de oorsprong van de vraag

Wanneer iemand je als analist de vraag stelt om extra documentatie te voorzien dan is het altijd verstandig om te kijken of het om een persoonlijke wens gaat of een wens die door het team gedragen wordt.

Hierbij kun je altijd voorrang geven aan verzoeken die vanuit het team gedragen worden. Persoonlijke wensen kunnen immers wel eens uit gemakzucht of een verkeerde focus van de desbetreffende persoon voortkomen.

Als een software-architect je bijvoorbeeld vraagt om een praatplaat te maken van het te ontwikkelen systeem in ‘zijn’ landschap, dan had deze er vaak al lang moeten liggen. De praatplaat (of andere documentatie zoals technische weergaves van het systeem) is en blijft de verantwoordelijkheid van de software-architect.

Ook ontwikkelaars die de gekozen implementatie vastgelegd willen hebben zouden dit gewoon in het technisch ontwerp moeten doen en niet in de requirements. Het gaat hier immers om een gekozen technische oplossing en niet om een oplossing die gevraagd is door de eindgebruikers.

Ons advies: Krijg je de vraag om extra informatie te verzorgen? Ga dan meteen na of het een om persoonlijke wens of een wens van het team gaat. Gaat het om een wens van het team? Tracht je team dan zo goed mogelijk te helpen nadat je je primaire taken vervuld hebt. Zorg er ook altijd voor dat het duidelijk blijft wie welke taken en verantwoordelijkheden heeft.

Is het verkeerd om altijd “ja” te zeggen?

Je kunt het als een groot compliment beschouwen wanneer verschillende disciplines je verzoeken om (extra) documentatie te maken. Dit betekent dat men vertrouwen in je heeft en dat jij een begrijpelijk verhaal hebt. Het kan echter ook zijn dat men onzeker is over de kwaliteit die men zelf kan opleveren.

In al deze gevallen raden wij aan om je als sparringspartner op te stellen. Zo leg je de bal in het kamp van de vragende partij: je vraagt om zelf met een voorstel te komen dat je vervolgens samen kunt nalopen. Zo voorkom je als analist dat je (al dan niet bewust) de taken en verantwoordelijkheden van een ander overneemt.

Ons advies: Neem niet zomaar de taken en verantwoordelijkheden van andere projectleden over. Help je projectleden liever als sparringspartner. Leg het initiatief bij je collega en bespreek zijn of haar voorstel op basis van jouw kennis, ervaring en inzichten. Zo help je je projectleden terwijl de taken en verantwoordelijkheden gescheiden blijven.

Welke documentatie verzorgen de analisten van DiVetro?

De analisten van DiVetro leggen de functionele werking van het gewenste systeem vaak vast in een use case. Deze use case ontstaat meestal uit een specifieke need of feature vanuit de klantorganisatie.

In agile projecten maken we ook zogenaamde use case slices / stories (planningseenheden gebaseerd op stukjes use case, volgens de UC2.0 methode). Wij ondersteunen en verdiepen indien nodig de use case met een termenlijst, een domeinmodel en bedrijfsregels.

Vervolgens maken wij modellen om de use case te visualiseren. Hier gebruiken wij modelleertechnieken zoals UML voor. Wij gebruiken vaak use case modellen, class -, activity -, sequence – en state diagrammen.

De hoeveelheid details in de documentatie is hierbij afhankelijk van de volwassenheid en domeinkennis van de teamleden. Deze vaste werkwijze geeft ons als analisten veel houvast bij het opstellen van gestructureerde functionele documentatie. Documentatie waar het team en later de beheerorganisatie écht wat aan heeft.

Herken jij je in dit verhaal?

Herken jij je in dit verhaal? En heb jij een duidelijke visie op analyse en bijbehorende noodzakelijke documentatie? Dan zijn wij mogelijk op zoek naar jou! Wij zoeken op dit moment analisten om ons team bij DiVetro verder te komen versterken. Is dit wat voor jou? Aarzel niet en neem meteen contact met ons op.

Heb je verdere vragen?

Heb je vragen, opmerkingen of inzichten naar aanleiding van dit artikel? Aarzel niet en deel ze met ons via het reactieformulier hieronder of via info@divetro.nl of +31 (0) 88 000 54 00.

Blijf op de hoogte

Wilt u meer van dit soort blog posts lezen? Meld u dan aan voor onze nieuwsbrief. U ontvangt onze blog posts dan in uw mailbox zodra ze op onze website verschijnen.

DiVetro Team - Richard Hilekes

Richard Hilekes is een informatie analist van DiVetro. Hij heeft zo’n 10 jaar ervaring binnen dit vakgebied bij verschillende organisaties. De laatste jaren vooral in een Agile/Scrum omgeving. Richard is een gecertificeerd Use-Case 2.0 master. Momenteel is Richard informatie analist bij Wigo4it .

DiVetro Team - Dennis Geluk

Dennis Geluk is een senior informatie analist en partner van DiVetro. Hij heeft meer dan 15 jaar IT ervaring. Dennis is een gecertificeerd Use-Case 2.0 coach. Hij heeft bij verschillende organisaties een spilfunctie vervuld bij het implementeren van UC2.0, het invoeren van Agile werken en het verbeteren van requirements standaarden. Momenteel is Dennis als coach en informatie analist voor de NS bezig UC2.0 te implementeren. Lees hier meer over de NS-case.

Hoe kunnen wij u helpen?

Villa de Reehorst
Hoofdstraat 20A
3972 LA Driebergen-Rijsenburg
Nederland

Stuur ons een bericht

  • Wij behandelen uw gegevens vertrouwelijk en vragen graag uw toestemming om u via e-mail informatie te bezorgen. Lees hier ons privacybeleid.