Analisten werken vaak in een te vroeg stadium te veel zaken uit. Dit is niet altijd efficiënt. Een Just in Time en Just Enough benadering is meestal efficiënter. Wij hadden een gesprek met Selmar van Egmond, senior analist bij DiVetro.

Selmar, kun je jezelf kort voorstellen?

Selmar: Jazeker, ik ben Selmar, 40 jaar oud en ik zit inmiddels zo’n 20 jaar in het vak. Ik ben sinds 2014 bij DiVetro. Ik werk voornamelijk op analyseopdrachten en ik houd ervan om mezelf en mijn manier van werken regelmatig te evalueren. Dat ben je als analist aan jezelf, je team en je klanten verplicht.

“Als analist heb je een spilfunctie en daarmee een grote verantwoordelijkheid.”

Hoe bedoel je dat precies?

Selmar: Als analist heb je binnen IT-projecten een spilfunctie, en daarmee een grote verantwoordelijkheid. Enerzijds help je de klant om de eisen en wensen helder te krijgen. Anderzijds geef je input aan het ontwikkelteam en ben je vraagbaak voor inhoudelijke vragen.

Daarom evalueren we bij DiVetro vaak de verantwoordelijkheden van analisten, en dan met name de verantwoordelijkheden bij het opstellen van het primaire analyseproduct: de requirements.

Zijn scherpe requirements nog cruciaal in IT-projecten?

Selmar: Goede vraag! Agile projecten stellen het belang van uitgewerkte requirements steeds meer ter discussie. De focus ligt immers bij werkende oplossingen, meestal software. Dat is belangrijker dan documentatie.

Wij zijn er bij DiVetro van overtuigd dat heldere requirements nog steeds onmisbaar zijn bij (IT) projecten. Maar je moet een balans vinden. Analisten weten vaak van geen ophouden. Ze willen alles uitzoeken en analyseren en alles opschrijven wat ze weten.

Dit is een veelgemaakte denkfout. Wij denken dat het cruciaal is om vanuit de analyserol de principes “Just In Time” en “Just Enough” te hanteren; zeker in agile projecten.

Voor de lezers die hier nog niet mee vertrouwd zijn: wat is “just in time”?

Selmar: Just In Time (JIT) is bekend door Lean SixSigma. Het is een principe dat erop gericht is om precies op het juiste moment de juiste dingen te doen. Het principe wordt veel toegepast in de logistiek en de industrie, maar het kan net zozeer op IT-projecten toegepast worden. Agile is in wezen niets anders dan Lean toegepast op IT-projecten.

“De houdbaarheid van requirements is beperkt.”

Waarom is “Just In Time” zo belangrijk?

Selmar: We zien nog te vaak projecten waarbij vooruit gewerkt wordt om (valse) zekerheid te verschaffen over de volgende sprint of simpelweg om mensen aan het werk te houden. In realiteit levert “vooruit werken” echter niet altijd de gewenste waarde op. Het maakt het project als totaal niet effectiever.

Als je teveel vooruit werkt dan krijg je immers voorraadvorming. Dat is volgens Lean een vorm van verspilling (muda). Dit heeft vervelende gevolgen in productielijnen (opslag van ongebruikte producten is duur), maar voorraadvorming kan ook nadelig zijn voor IT-projecten.

Hoe bedoel je dat precies?

Selmar: Wel… Analisten leveren requirements. Als deze requirements “vooruit gemaakt” worden en te lang op de plank liggen dan worden ze stoffig. Dit houdt verschillende risico’s in.

Requirements die op de plank liggen zijn vaak niet meer actueel op het moment dat ze gebruikt moeten worden. Zeker in een agile aanpak werkt dit niet, want de echte toets van het product vindt plaats in de sprint review (demo), niet alleen op basis van requirements.

Bovendien houden requirements op de plank geen rekening met nieuwe of veranderende inzichten. Dit is vaak het geval wanneer er onvoldoende bij alle stakeholders getoetst wordt en/of als de verwachtingen onvoldoende ingelost worden. De houdbaarheid van requirements is dus beperkt.

Vooruit werken is dus uit den boze?

Selmar: Vooruit werken heeft meer nadelen hebben dan je zou verwachten. Als je teveel vooruit werkt bestaat het risico dat niemand tijd voor je heeft. De basis voor de analyse is dan vaak niet langer afstemming met de stakeholders maar (verouderde) documentatie en aannames.

En als je teveel vooruit werkt dan houd je mensen ook van hun primaire taken af. Je belet hen al snel om focus te leggen (en te houden) op wat het meest belangrijk is.

Wat zou jij adviseren? Hoe moeten analisten te werk gaan?

Selmar: Ik adviseer om niet de analyse centraal te stellen, maar altijd het complete proces. Vraag daarom wat vanuit klant- en projectbelang de prioriteit heeft en lever daaraan een bijdrage, zelfs als dit geen primaire analysetaak is.

In agile omgevingen lijkt Just In Time eenvoudiger omdat de focus op de sprint ligt, maar er is vaak toch nog druk vanuit een projectleider of vanuit het management om de volgende analyseklus alvast op te pakken.

“Als analist moet je sterk in je schoenen staan.”

Dat lijkt me niet eenvoudig.

Selmar: Dat klopt. Als analist moet je sterk in je schoenen kunnen staan en ‘nee’ willen en durven zeggen. En dat is makkelijker gezegd dan gedaan. ‘Nee’ zeggen is moeilijk. Dat hebben we onlangs nog in ons artikel “Een goede analist moet keuzes durven maken” beschreven.

Je sprak daarnet ook over “Just Enough”?

Selmar: Just Enough is ook een veel gebruikt principe in Lean projecten. In ons geval gaat het over de diepgang van requirements.

Vanuit een procesgedachte zouden requirements precies voldoende moeten zijn om de vervolgstappen succesvol te laten verlopen. Wat pakken we als team in deze sprint op, en wat is daarvoor nodig? De diepgang van requirements is afhankelijk van de beschikbare kennis en het beoogde doel.

Wanneer geven requirements “Just Enough” informatie?

Selmar: Dat is zoals gezegd afhankelijk van het doel van de requirements. Voor impact- en prioriteitbepaling dienen de requirements overzicht en scope te geven, met precies voldoende details zodat een outline van de gewenste oplossing ontstaat.

Op basis van deze outline kunnen we vervolgens, bijvoorbeeld door het opstellen van user stories, inschatten hoeveel werk er te verzetten valt en welke delen het meeste voor de klant toevoegen.

Voor impactbepaling is weinig diepgang nodig. Voor impactbepaling hebben we vooral overzicht en voldoende informatie nodig zodat de product owner prioriteiten kan stellen voor het ontwikkelteam.

Hoe uitgebreid moeten requirements tijdens het ontwikkelproces zijn?

Selmar: Voor het ontwikkelproces is in veel gevallen meer diepgang in de requirements nodig. Er volgt dan een verdieping op de outline zodat er precies voldoende informatie is om te weten wat de klant wil en zodat de ontwikkelaar kan bouwen.

Meer informatie is niet nodig. Meer informatie kan zelfs ballast zijn; het kan het proces vertragen. Niemand zit nog te wachten op uitgebreide (wollige) verhalen.

“Een belangrijke vraag is: “Wie gaat dit lezen?”

Daar kan ik me iets bij voorstellen…

Selmar: Een belangrijke toetsvraag is: “wie gaat dit lezen?” Als analisten stappen we vaak in dezelfde valkuil: we schrijven op wat we weten, ook als dat nu niet de prioriteit heeft.

De personen na jou zullen hier om- of doorheen moeten lezen, want het is niet de kern. Dit kost alleen maar extra tijd en het leidt mogelijk tot fouten omdat de essentie verdoezeld is. Parkeer dingen daarom altijd op een backlog, en neem extra toelichtingen die je niet wilt verliezen in een apart document of een bijlage op.

Je vertelde ook dat de diepgang van requirements afhankelijk is van de beschikbare kennis?

Selmar: Inderdaad. De mate waarin kennis beschikbaar is binnen het ontwikkel- en beheerteam bepaalt in grote mate hoe uitgebreid de requirements moeten zijn. Immers, als er al veel kennis aanwezig is, en als deze informatie in het hele team gedeeld is, dan lijkt veel opschrijven niet nodig.

Let wel: iedereen moet op de hoogte zijn van informatie die voor hen belangrijk is. Ook externe stakeholders! Bij een hoog gedeeld kennisniveau is ons advies om ‘Spartaanse’ ofwel beknopte documentatie op te leveren. De details die ertoe doen staan hier uiteraard in vermeld, maar zonder alle uitleg die je mag verwachten van mensen die in het domein bekend zijn.

Niet iedere behoefte van een stakeholder hoeft direct gevolgd te worden, maar er is een breder draagvlak nodig. Een eventueel ‘gat’ in kennis van een bepaalde stakeholder kan eventueel met maatwerk worden opgelost, bijvoorbeeld door een opleiding of betere interactie.

En wat als er in een project minder kennis aanwezig is?

Selmar: Als er onvoldoende kennis en begrip van de oplossing is, dan moeten we extra context en toelichting leveren. Dit is vaak het geval bij offshore ontwikkeling, waar de ontwikkelaars precies doen wat er op papier staat en interpretatie (in principe) ongewenst is. Hierbij zullen de requirements onder andere alle uitzonderingen moeten beschrijven omdat er geen rekening wordt gehouden met wat niet is opgeschreven.

“De praktijk is natuurlijk nooit zwart wit.”

Zijn “Just In Time” en “Just Enough” overal even noodzakelijk?

Selmar: De praktijk is natuurlijk nooit zo zwart en wit als hier geschetst. Iedere organisatie en ieder project zijn weer anders. Het begint daarom altijd met het maken van heldere afspraken over het niveau en diepgang van de requirements.

Wij adviseren bij Divetro om als team voldoende tijd te besteden aan het doordenken van je documentatiestandaarden en het afstemmen van de behoeften en de verwachtingen van alle stakeholders.

Hierbij kan het helpen om bestaande standaarden van de organisatie als startpunt te gebruiken en op basis hiervan een voorbeeld uit te werken of guidelines op te stellen.

Uiteraard mag het volgen van een standaard of guideline geen doel op zich worden. Het moet in de specifieke projectsituatie passen. Ga dus nooit van start zonder goede afstemming met de stakeholders. De behoeften van de stakeholders moeten altijd helder zijn.

Kunnen we stellen dat requirements toch nog belangrijk zijn?

Selmar: Zeker! Requirements bepalen in grote mate het succes van (IT) projecten, en daar heb je als analist een cruciale rol en verantwoordelijkheid in.

Lever als analist de requirements op het juiste moment en met de juiste diepgang voor jouw stakeholders om succesvol te kunnen zijn.

Neem daarbij niet alleen tijd voor het maken van de requirements, maar investeer ook tijd in het afstemmen van de informatiebehoefte van je stakeholders en je team.

Dat lijkt me een mooie conclusie om mee af te sluiten Selmar. Waar kunnen de lezers meer informatie vinden?

Selmar: We hebben een duidelijke website waarop regelmatig artikelen, onder andere over analyse worden gepubliceerd. Heb je vragen over analyse, requirements of vragen over jouw project dan kun je altijd contact opnemen. We beantwoorden je vragen graag via info@divetro.nl of via +31 (0) 88 000 54 00.