Hoewel T-shaped de term is van de laatste jaren (iedere professional van developer tot marketeer moet naast specialistische kennis en vaardigheden ook breed inzetbaar zijn), blijf je als ontwikkelaar en mens vaak een voorkeur of affiniteit houden met een bepaald aspect van het werk. En dat geldt niet alleen voor ontwikkelaars, ook Product Owners hebben hier mee te maken. In dit blog een inkijkje in het Product Ownen van een backend applicatie.
Een Product Owner (PO) van een app of web applicatie heeft doorgaans te maken met andere aspecten, klantwensen en discussies dan een Product Owner van een backend applicatie zonder interface. In plaats van verdiepende gesprekken over de technische afhandeling van business logica bij een backend applicatie heb je bij een customer-facing web applicatie het meer over UX, design en bijvoorbeeld security.
Veel van de werkzaamheden van deze PO’s zijn gelijk. Het managen van de backlog en het managen van stakeholders. Het monitoren van de voortgang in de sprint en het ontwikkelen en bijschaven van de productvisie behoren bij beide tot hun dagelijkse werkpakket. Maar er zijn toch echt verschillen. Als PO van een backend applicatie heb je de nodige specifieke uitdagingen te tackelen.
Klantcommunicatie
Hoewel de requirements voor de applicatie komen van de klant en zij dus echt wel weten wat de applicatie moet doen, kan het soms lastig zijn om kenbaar te maken wat er allemaal moet gebeuren om dit te realiseren. Zeker als de feature technisch vrij groot blijkt te zijn. Wat wij zelf erg prettig vinden is om de klant / stakeholder op zo’n manier mee te nemen in het proces dat hij echt begrijpt wat er allemaal bij komt kijken. We gaan je dus niet overdonderen met een technisch verhaal.
Hoe doen we dat dan wel?
1. Het gebruik van metaforen.
Door een metafoor te gebruiken krijg je de stakeholder mee. Ga bijvoorbeeld voor de vergelijking met mailverkeer of zelfs verkeerssituaties. Hiermee kweek je begrip voor de situatie en begrip van het probleem wat opgelost dient te worden. De truc is om dit metafoor dan ook structureel te gebruiken en terug te laten komen in gesprekken en demo’s. Ga echter niet teveel in detail in de metaforen want je zult zien; op hoofdlijnen gaat de vergelijking goed op, maar hoe dieper in detail de vergelijking gemaakt wordt hoe meer deze gaat afwijken. En probeer dicht bij de realiteit te blijven. Dit maakt de vertaling en de stap naar de realiteit makkelijker te maken. Voorbeeld: Als er via een API Json data verstuurd wordt vanuit de applicatie naar een derde partij, gebruik dan geen postduiven als metafoor maar “een bericht in een specifiek formaat” of “sms” als metafoor of analogie.
2. Maak dingen visueel.
Het cliché is waar; A picture says more than a thousand words. Naast in het taalgebruik een vertaling te maken naar metaforen en een versimpelde weergave te schetsen van de werkelijkheid, is het gebruik maken van plaatjes en afbeeldingen een hele goede manier om dingen uit te leggen. Ik merk dat het extra krachtig wordt als je dit samen met je stakeholder vorm geeft, bijvoorbeeld op een whiteboard. Door middel van het verwerken van de antwoorden op de vragen van de stakeholder in de weergave kan deze direct het antwoord zien en duiden in het grotere geheel! Dit verklaart ook meteen waarom ik altijd direct begin te tekenen als we een meeting beginnen.
3. Vermijd niet koste wat kost de technische termen.
Gebruik van metaforen wil niet zeggen dat je geen technische termen mag of kan gebruiken. Het weglaten ervan kan juist tot verwarring leiden. Het enige wat de stakeholder dan meekrijgt zijn de metaforen en daarmee ook het begrip voor de complexiteit van het geheel. Daarbij geef je de stakeholder ook de ruimte om dingen te leren. Op termijn kan hij daar weer zijn voordeel mee doen. En jij als PO dus ook.
4. Weet wat je zegt als Product owner.
Om de zaken goed uit te kunnen leggen aan je stakeholder is het absoluut een pré als je als Product Owner ook echt begrijpt wat een feature exact inhoud. Uiteraard op functioneel vlak maar in geval van een backend applicatie ook technisch. Mijn technische achtergrond helpt mij hier enorm bij. Hoe beter ik het zelf begrijp hoe beter ik het aan anderen kan uitleggen. Heb je zelf geen technische achtergrond dan is het belangrijk om de tijd te nemen om je door het team goed voor te laten lichten wat er exact moet gebeuren en waarom. En uiteraard is er altijd de mogelijkheid om een van de developers mee te nemen in een gesprek. Hij kan de stakeholder technische zaken uitleggen en verhelderen. Sommige Product Owners zijn hier wat huiverig voor maar mijn ervaring is dat dit alleen maar het wederzijds begrip versterkt!
Een Product owner heeft product vision nodig
Een ander aspect wat belangrijk is als Product Owner is het ontwikkelen en onderhouden van een product visie; waar moet het product zich naartoe ontwikkelen? Bij een backend applicatie is al snel sprake van vrij technische ontwikkelingen. Ook hier is het fijn als je als Product Owner een technische achtergrond hebt. Zodat je zelf een goed beeld kunt vormen en sparren met het team en ideeën kunt challengen.
Een van de belangrijkste aspecten hierin is; neem de lange termijn wensen van de stakeholders mee als input en… vertrouw je team. Zij zijn de experts op het gebied van techniek. Zij weten als beste hoe de lange termijn wensen van de stakeholders gerealiseerd kunnen worden. Het is fijn als je het team ook op technisch vlak kunt challengen, maar de expertise zit bij de mensen die het ook daadwerkelijk moeten gaan realiseren! Onze ervaring is dat de product vision bij een applicatie als deze voor een groter deel gevormd wordt door het team als geheel.
Hoe demo je het increment?
De sprint review en demo van een backend applicatie kan soms uitdagend zijn want.. wat ga je laten zien? Je wil je publiek niet teveel afleiden met ingewikkelde technische interfaces die op zichzelf weinig te maken hebben met de gevraagde en ontwikkelde feature. De ervaring die wij hebben is dat de volgende dingen hier goed bij kunnen helpen;
- Use powerpoint! Als aanvulling, niet in plaats van. Uiteraard wil je zoveel mogelijk features van het opgeleverde increment live demo-en. Maar het kan best van toegevoegde waarde zijn om bijvoorbeeld een animatie in powerpoint te gebruiken. Om eerst uit te leggen wat de stakeholders gaan zien. Geef ze eerst wat context zodat ze daarna gericht kunnen kijken naar iets wat aan hun (bijgestelde) verwachting voldoet. Ook als een feature uit vele stories bestaat kan het waardevol zijn om vooraf aan te geven welk gedeelte van de uiteindelijke feature er gedemo-ed wordt in een gevisualiseerd overzicht.
- Bouw interfaces voor demo & testing. Het kan voor de applicatie zelf niet nodig zijn om een interface te hebben voor een bepaalde feature. Maar het kan zeker de moeite waard zijn om hier toch een (simpele) interface voor te maken. Deze kan het team zelf gebruiken om mee te testen. Maar je kunt er ook de feature mee demo-en. Bijvoorbeeld door middel van het tonen van het resultaat (in welke vorm dan ook). Dit maakt het ook mogelijk om delen van de feature te testen en te tonen zonder dat de feature in zijn geheel af is. Daarnaast is dit ook een manier om de klant zelf acceptatietesten te kunnen laten doen.
Klinkt goed?
Heb je een backend vraagstuk? Ben je op zoek naar een betrokken partner die met je meedenkt en hoogwaardige kwaliteit software bouwt? Enrise is een betrouwbare partner met veel ervaring op dit gebied. Zie bijvoorbeeld ook de klant-case van Simpel.nl.
