Perceptie

In deze blog staat productanalyse centraal. Hieronder verstaan we de werkzaamheden die een analist uitvoert om te komen tot een informatiesysteem dat zo goed mogelijk aansluit bij de wensen van de business en/of de klant. De term productanalyse is afgeleid van de term ‘Product owner’, een rol die veel gebruikt wordt in moderne agile ontwikkelaanpakken (waaronder Scrum, LeSS, SAFe en DAD). Business analisten vormen een belangrijke bijdrage aan de ontwikkeling van kwalitatief hoogwaardige informatiesystemen (als onderdeel van een organisatie-verbetering) en een sleutelrol als het gaat om teameffectiviteit (dit is zo cruciaal dat hieraan een aparte blog zal worden besteed). Ze doen dit (als product owner dan wel als team member, ook hierop zal ik uitgebreid terugkomen) enerzijds door ervoor te zorgen dat de belanghebbenden (stakeholders) allemaal op één lijn liggen met betrekking tot het nieuwe product en anderzijds door de requirements in detail uit te werken. In deze blog concentreren we ons op het eerste punt.   

Het is belangrijk dat een analist zich realiseert dat verschillende mensen een verschillende perceptie (kunnen) hebben van de werkelijkheid en dus ook van een nieuw product. De plaatjes hieronder laten daarvan voorbeelden zien. Je kunt in een plaatje verschillende dingen zien; de ene perceptie is niet beter dan de andere!

Met betrekking tot het (te bouwen of kopen) product is het van groot belang dat de analist zich realiseert dat verschillende gebruikers(groepen) er anders tegenaan kijken dan andere gebruikers(groepen). Bijvoorbeeld: de ene persoon ziet in het linker plaatje eerst een leeuw of andere katachtige en ziet na enige tijd pas een aap. Bij de andere persoon is het precies andersom. In het rechter plaatje kun je ook twee dingen zien: een indiaan of een eskimo die een donkere ruimte instapt. Het meest leerzame van deze oefeningen vind ik de gedachte dat als je eenmaal het andere plaatje ziet het eigenlijk onmogelijk wordt om het niet meer te zien! Johan Cruijff zei hierover: "Je gaat het pas zien als je het door hebt“.

En zo gaat het ook bij percepties van andere mensen: als je eenmaal doorhebt hoe een ander kijkt naar een product of situatie dan wordt het lastiger om dit los te laten. Als je het vermogen hebt om vanuit verschillende invalshoeken naar een product of situatie te kijken, dan kun je als analist een betere rol spelen bij bemiddelingen en onderhandelingen tussen stakeholders. Het belangrijkste doel is dat ze uiteindelijk hetzelfde plaatje gaan zien en dat daarover afspraken gemaakt kunnen worden! Een heldere communicatie van duidelijke productspecificaties leidt tot een goed verwachtingsmanagement richting de stakeholders en die is weer nodig om het project te laten slagen! In de eerste plaats moet het doel zijn om de belangrijkste stakeholders (niet iedere stakeholder is even belangrijk, meer in een latere blog) tevreden te stellen; het product moet voldoen aan hun behoeften. Indien niet aan hun verwachtingen voldaan kan worden, dan moet dit zo snel mogelijk gecommuniceerd worden.

Heel bekend zijn de verwachtingen van diverse stakeholders zoals die in projectcartoon.com zijn geschetst. Iedereen heeft zijn eigen perceptie (en dus verwachtingen!) van wat het product gaat doen en ze lopen enorm uiteen. Het is een van de taken van de analist om duidelijke verwachtingen te schetsen richting alle stakeholders in het project.

Bron: projectcartoon.com

Olifant

Een ander voorbeeld is het Soefi-verhaal van de groep blinde mannen die allemaal een deel van een olifant voelen en op basis daarvan hun eigen conclusie trekken welk voorwerp of dier ze denken dat ze voor zich hebben. De man die aan de poot voelt denkt dat het om een boomstam gaat, de man die aan de slagtand voelt stelt zich een speer voor, etc. Allemaal hebben ze gelijk op basis van wat ze voelen, maar ze zitten er allemaal naast omdat hun ‘onderzoeksgebied' (en daarmee hun scope) te beperkt is!

Zoals in het soefi-verhaal is in de praktijk meestal niet helder hoe een nieuw software-product er precies uit moet gaan zien en wat het voor stakeholders gaat betekenen. In de onderstaande figuur worden de vage contouren van het product aangeduid met stippellijntjes; in projecten heten ze vaak features of epics.

Maar onthoud: een olifant is geen doel op zich!

Zoals ook is onderstreept in de vorige blog is een informatiesysteem an sich niets waard. Het gaat om de waarde van het informatiesysteem voor zijn toekomstige gebruikers. Stel je voor dat een stam in de rimboe van Indonesië geld wil gaan verdienen in de houthandel. Ze hebben als ‘businessdoel’ het vervoeren en verhandelen van bomen. In dat geval is de olifant een middel dat dit vervoer mogelijk maakt. De olifant wordt als lastdier ingezet en gaat boomstammen vervoeren van het bos naar het strand op 10 km afstand. Je kunt dit letterlijk opvatten, maar in deze blog wordt de olifant in overdrachtelijke zin gebruikt: de ‘olifant’ staat voor een informatiesysteem dat de business moet ondersteunen met het behalen van de organisatiedoelen (zie ook de vorige blog). We hebben dan een business die belang heeft bij de olifant en een ontwikkelteam die de ‘olifant’ moet gaan maken of kopen. En we hebben te maken met stakeholders die over een ‘speer’ praten, een ‘boomstam’ of een ‘slang’. Waar begin je dan mee? Je hebt niet van het ene op het andere moment een ‘olifant’ gebouwd of gekocht!

Je zou kunnen starten met een workshop waarin je de belangrijkste stakeholders uitnodigt en waarbij het doel is te komen tot een beschrijving van Olifant 1.0 (we gaan er even vanuit dat een hele olifant niet zomaar is aan te schaffen) dat bijvoorbeeld slechts bestaat uit een paar poten en een rug waarop spullen vervoerd kunnen worden. Deze kan eventueel al worden ingezet in de business. Maar omdat de olifant nog geen ogen heeft, zul je zelf nog tijdelijk als ‘ogen’ moeten fungeren. De gekozen oplossing dient natuurlijk goed gecommuniceerd te worden richting alle stakeholders (ook degene die niet bij de workshop aanwezig zijn geweest). Ze krijgen dan dezelfde perceptie van het product. En ze weten dat die ‘speer’ of ‘boomstam’ er niet komt of pas op een later moment. Bij onenigheid wordt hierover gediscussieerd. Het doel moet zijn te komen tot consensus met betrekking tot de wijze waarop het product tot stand komt en welke features er wel en welke niet worden opgenomen, zodat niemand op een later moment voor verrassingen komt te staan. Laat vooral zien dat de business doelstellingen (business requirements) voorop staan en niet de requirements van sommige stakeholders. Alleen de belangrijkste stakeholder requirements die in lijn liggen met de business doelstellingen worden in eerste instantie opgepakt.

Belangrijke competenties

Scherp krijgen wat de eigenschappen zijn van een softwareproduct en hierover consensus bewerkstelligen onder de stakeholders (met andere woorden het creëren van een gemeenschappelijke perceptie van het toekomstige product) is een zeer belangrijke competentie voor de (business) analist.

Een andere belangrijke competentie is het scherp detailleren van de eigenschappen opdat het ontwikkelteam efficiënt te werk kan gaan. Op het moment dat gekozen wordt om bijvoorbeeld de poten te ontwikkelen, zal scherper bepaald moeten worden hoe die 'poten' er precies uit gaan zien. Bestaan ze uit drie of vier 'tenen'? Hoelang moeten de 'poten' minimaal zijn? Hoe gaan de 'lichaamsdelen' met elkaar communiceren? Het zijn allemaal requirements die door de analist worden uitgewerkt alvorens overgegaan kan worden tot de bouw van het component. Ik zal in toekomstige blogs uitgebreid terugkomen op de wijze waarop de requirements het best gedetailleerd kunnen worden.