Tegenwoordig ben ik Product Owner (P.O.). Vroeger niet, toen was ik ontwikkelaar. Soms helpt dat in mijn huidige vak, maar meestal heb ik er nu niets aan, omdat ik me van mijn team niet met de techniek mag bemoeien. Ik wil niet melodramatisch doen, maar als ontwikkelaar had ik het makkelijker. Ik kreeg altijd perfecte specificaties aangeleverd van wat ik moest bouwen en waar het aan moest voldoen. Ik hoefde het alleen maar uit te tikken. Wat een luizenleventje was dat.

Maar nu dan, wat een gedoe allemaal om die perfecte specificaties aan te kunnen leveren aan het team. Ik zal eens even uitleggen hoe zwaar ik het heb.

Wat is het probleem?

Als eerste moet ik natuurlijk weten wat het probleem is dat opgelost moet worden. Ik gebruik expres deze woorden, want mijn klanten komen meestal met oplossingen. “Ik wil een lijst kunnen printen van …”. Doorvragen waarom ze dat precies willen is dan de kunst. Soms blijkt dan dat ze echt wel met de juiste oplossing zijn gekomen, maar best vaak blijkt dat hun echte probleem ergens anders begonnen is en dus ook anders (slimmer, goedkoper) opgelost kan worden. Misschien hebben ze die lijst helemaal niet nodig als op strategische plekken op het scherm wat meer informatie wordt toegevoegd. Daarom moet ik dus het achterliggende probleem kennen.

Dat doorvragen heeft nog een ander doel. Ik moet als P.O. begrijpen wat het werk van mijn klant inhoudt, hoe dat werk gedaan wordt en aan welke wetten en regels dat gebonden is. Die Domeinkennis heb ik als ik bij een klant kom nog helemaal niet. Ik weet alleen maar hoe je software moet bouwen. Als ik wat langer bij dezelfde klant zit dan komt die Domeinkennis enigszins, maar mijn klant blijft een zeer belangrijke partner voor het verstrekken van die kennis.

Hoe willen we dit oplossen?

Als ik het probleem ken dan kan ik gaan werken aan een oplossing. Die oplossing bedenk ik natuurlijk niet zelf, ik moet al zoveel doen. Nee, ik maak een zogenaamde “User Story” en bespreek dat met het team. Voor de leken: Een User Story beschrijft op een bepaalde manier wat het probleem is, en wanneer we dat probleem als opgelost beschouwen. Bij complexe problemen gaat hier veel werk in zitten, dan moet ik diagrammetjes etc. maken om het probleem duidelijk te kunnen uitleggen. En de meeste problemen worden ook niet met slechts 1 User Story opgelost. In die gevallen wordt een serie van gerelateerde User Stories gemaakt, die elk een deel van het probleem oplossen.

Het team en ik bespreken dus tijdens een zogenaamde “Refinement sessie” de User Story om samen te bedenken wat we gaan opleveren om het probleem te tackelen. Dit vind ik een van de leukste onderdelen van mijn vak: het sparren met het team hoe we iets slim oplossen. Hier merk je ook de grootste verschillen tussen teams: sommige teams willen gewoon van mij horen wat ze moeten doen, en sommige teams denken actief mee met het vinden van de beste oplossing. Je snapt dat ik dat laatste het liefste heb. Dat is minder werk voor mij.

Hoe bewijzen we dat het opgelost is?

Ik geloof het ontwikkelteam natuurlijk niet zomaar op hun mooie blauwe (of bruine) ogen als ze zeggen dat het opgelost is. Ze moeten dat aan mij, en de klant, kunnen bewijzen a.d.h.v. zogenaamde “acceptatiecriteria” die ik bij de voorbereiding al aan de User Story had toegevoegd. Tijdens een live demo door het team checken de klant en ik of aan alle acceptatiecriteria voldaan is. Als dat zo is dan is het probleem opgelost. Als dat niet zo is dan is er nog werk aan de winkel voor het team.

Die acceptatiecriteria zijn best belangrijk, want die geven voor een groot deel de scope van zo’n oplossing aan. En vaak gaan ze niet alleen over het probleem, maar ook over randvoorwaarden zoals beveiliging of gebruikerservaring, dat soort zaken.

Hou het team in toom!

Ontwikkelaars zijn kenniswerkers, vaak halen ze hun voldoening uit het ontdekken van nieuwe frameworks, technieken of toepassingen. Het is belangrijk voor hen om bij te blijven in hun vak, maar soms ontaard dat in een oplossing die te ver is doorontwikkeld of veel te ingewikkeld is gemaakt. Daarom specificeer ik in een User Story ook wanneer het goed genoeg is. Dat doe ik m.b.v. de “Out of scope” specificaties die aan de ontwikkelaars duidelijk maken wat ik te ver vind gaan. Zo hoop ik te voorkomen dat mijn probleem opgelost zou zijn met een fiets, maar een auto geleverd krijg. Dat doe ik niet om het team te pesten, maar om te zorgen dat de tijd van de ontwikkelaars zinnig besteed wordt. Goed is goed genoeg, perfect is zonde van de tijd.

Wendbaarheid gevraagd

Tot nu toe lijkt het alsof ik een luizenleventje heb. Maar de klussen waarvoor ik ingehuurd word gaan natuurlijk niet over simpele problemen. Het zijn altijd complexe, grote vraagstukken waar een klant zelf niet meer uitkomt, of geen capaciteit voor heeft. En die los je niet op met een paar User Stories. Om dit soort oplossingen te bouwen moet ik, in samenwerking met de klant en het team, het probleem opdelen in grote brokken (Epics) die weer onderverdeeld zijn in gerelateerde onderdelen (Features). De Features vallen dan weer uiteen in verschillende User Stories. Het kost veel tijd en doorvragen om dat allemaal inzichtelijk te maken, en ondertussen willen de ontwikkelaars wel aan de slag. Dat lossen we op door “Agile” te werken: we beginnen met wat we weten, en terwijl ik en het team steeds meer kennis opdoen werken we toe naar de uiteindelijke oplossing.

Soms blijkt dat we eerder in de ontwikkeling iets gebouwd hebben wat niet afdoende is. Dan nemen we de tijd om het te verbeteren totdat het goed genoeg is. En soms hadden we een onderdeel wel goed genoeg gebouwd, maar is de klant van mening veranderd. Ook dan kunnen we het veranderen. Geen probleem, de klant is immers Koning. Belangrijk is wel dat ik dan aan de klant duidelijk maak dat elk nieuw inzicht ook extra werk, dus extra kosten betekent.

“Is het al af?”

Werkelijk elke klant wil weten wanneer het af is. Maar het antwoord op die vraag is niet zo simpel bij het soort grote klussen wat is doe. In het begin van het traject is er nog heel veel onduidelijk, dus zijn de schattingen van de benodigde hoeveelheid werk ook onnauwkeurig. Maar hoe meer er duidelijk wordt, hoe beter deze schattingen worden. Die schattingen maak ik natuurlijk niet, die laat ik het team opstellen op basis van de deelproblemen die ik ondertussen boven water heb weten te doorvragen.

Ik ben wel degene die aan de klant moet vertellen wat de totale schatting is en hoe ver we schatten dat we zijn. Dat vereist altijd tact, iets dat ik niet in ruime mate bezit. Dit faken maakt mijn werk echt zwaar. Af en toe een schouderklopje zou best welkom zijn.

Het is vrij gebruikelijk dat de schattingen ruimer zijn dan het budget. In die gevallen wordt in overleg met de klant bepaald wat de minimum requirements zijn om een basis versie (MVP) van de oplossing van het probleem op te leveren. De Epics, Features en User Stories die toewerken naar die MVP krijgen dan bij de planning van alles prioriteit. De onderdelen die niet-MVP zijn komen dan aan het einde, als er nog tijd en budget over is. En anders maar niet.

Soms gaat het om serieus groot probleem, waar meerdere teams tegelijkertijd aan werken. Dan komt er nog een heel niveau van overleg bij: afstemming tussen de teams onderling. Op zich is dat wel leuk, want dan kan je overleggen met collega P.O.’s die snappen waarom je het zo zwaar hebt. Maar ja, die afstemming maakt het natuurlijk nog wat zwaarder. Van de regen in de drup dus.

Ten slotte

Tot nu toe zijn mijn klanten altijd blij geweest met mijn inzet en het opgeleverde resultaat. Uiteraard claim ik alle verantwoordelijkheid voor succesvolle oplossingen. Mocht er in de toekomst een klant niet tevreden zijn met het resultaat, dan kan dat alleen maar aan de ontwikkelaars liggen.

Je vraagt je misschien af waarom ik in hemelsnaam dit werk doe, als het allemaal zo moeilijk is. Maar dat is precies ook het antwoord: hoe groter de moeilijkheidsfactor, hoe groter de bevrediging als het allemaal tot een goed resultaat leidt. Tel daarbij op het sociale aspect van het overleggen met de klant, het team, solution architecten, beheerders, customer support en de overige P.O.’s. Ik leer allerlei verschillende leuke mensen kennen, en ik weet steeds een beetje meer af van hoe zaken werken in deze wereld.

Je kan het vergelijken met het krijgen van kinderen: je zit er de rest van je leven aan vast maar je krijgt er zoveel voor terug.

Zonder wrijving geen glans.

Zonder dalen geen toppen.

Enfin, je snapt het wel. O… en ik heb in dit artikel misschien een paar keer de draak gestoken met de rol van product owner. Het is een prachtig vak waar je zo links en rechts wel de nodige vooroordelen van terug hoort komen 😊.

Jeroen Wernsen