Van vooronderzoek naar werkend product: structuur brengen in een complexe softwareopdracht

Bij de start van een nieuwe opdracht was er al veel vooronderzoek gedaan, waren belangrijke processen onderzocht en verschillende datastromen in kaart gebracht.

Wat echter nog ontbrak, was een concreet plan om al die kennis om te zetten in een werkende applicatie.

Als Technical Product Owner kwam ik precies op dat snijvlak terecht. Mijn rol was niet alleen om te bepalen wat er gebouwd moest worden, maar vooral om businesskennis, processen en technische mogelijkheden met elkaar te verbinden.

Dat bleek al snel belangrijker dan alleen het schrijven van een backlog.

Beginnen terwijl nog niet alles klaarstaat

We begonnen de opdracht met een klein team. In eerste instantie werkte ik samen met één front-endontwikkelaar, terwijl een belangrijke interne collega pas een maand later beschikbaar zou zijn.

Wachten totdat het volledige team compleet was, was geen optie. We moesten beginnen met de informatie die er al lag.

Het vooronderzoek gaf ons veel inhoudelijke kennis. We wisten welke informatie belangrijk was en verschillende mappings en processen waren al onderzocht. Alleen was nog niet duidelijk hoe we dit technisch en functioneel konden vertalen naar een applicatie.

Mijn eerste taak werd daarom vooral structuur aanbrengen.

Welke processen willen we ondersteunen? Welke functionaliteit hoort daarbij? Hoe vertalen we die naar iets wat een ontwikkelaar daadwerkelijk kan bouwen? En welke vragen zijn nog onbeantwoord?

Vanuit die vragen ontstonden de eerste functionele uitwerkingen en technische tickets.

Tussen business en development

Naarmate het team groeide, werd mijn rol steeds meer die van verbindende schakel tussen de interne businessspecialisten en het developmentteam.

De business beschikte over veel domeinkennis, maar die kennis moest worden vertaald naar concrete software.

Dat betekende veel gesprekken voeren.

Niet alleen vragen wat iemand wilde hebben, maar vooral doorvragen waarom iets nodig was en hoe een proces in de praktijk werkte.

Vervolgens moest die informatie technisch voldoende concreet worden gemaakt zodat developers ermee verder konden.

Dat betekende onder andere processen uitwerken, requirements structureren, technische tickets beschrijven en samen met Senior Developers nadenken over de technische impact van keuzes.

Juist die combinatie vond ik interessant.

Een requirement kan functioneel logisch klinken, maar technisch grote gevolgen hebben. Andersom kan een technisch elegante oplossing weinig waarde toevoegen wanneer deze niet aansluit op het daadwerkelijke proces.

Als Technical Product Owner probeer je beide werelden te begrijpen.

Een nieuwe manier van samenwerken

Naast de inhoudelijke uitdaging speelde er nog iets anders.

Voor de opdrachtgever was het werken met een extern developmentteam relatief nieuw. Dat betekende dat we niet alleen software moesten bouwen, maar ook vertrouwen en een werkbare manier van samenwerken moesten ontwikkelen.

Daarbij merkte ik dat belangrijke informatie niet altijd goed tussen de verschillende betrokkenen werd gedeeld.

Verschillende mensen beschikten over verschillende delen van de kennis, maar zonder een vast moment om die informatie samen te brengen ontstond het risico dat het developmentteam op aannames zou gaan bouwen.

Daarom hebben we een vast overlegmoment ingericht.

Iedere maandag kwamen de belangrijkste betrokkenen bij elkaar om openstaande onderwerpen en beslissingen te bespreken. We legden vast wat besproken en besloten was en vertaalden dat vervolgens stap voor stap naar de ontwikkeling van het product.

Dat klinkt misschien eenvoudig, maar voor het project maakte het een groot verschil.

Er was niet meer informatie nodig.

We hadden vooral een proces nodig waarmee bestaande informatie consequent kon worden omgezet in beslissingen.

Meer verantwoordelijkheid toen de situatie veranderde

Tijdens het project viel de manager die het traject begeleidde onverwacht uit. Daardoor ontstond opnieuw een gat in de organisatie. Naast mijn rol als Technical Product Owner heb ik daarom ook een groter deel van de projectcoördinatie en teambegeleiding opgepakt.

Mijn belangrijkste doel daarbij was niet om extra processen toe te voegen, maar juist om ervoor te zorgen dat het team richting hetzelfde doel bleef werken. Daar kwamen meerdere vragen bij kijken:

• Wat moet er nu gebeuren?
• Welke beslissingen blokkeren development?
• Wie moet daarbij betrokken worden?
• Ligt de planning nog in lijn met wat we daadwerkelijk proberen te bouwen?

Juist die laatste vraag werd steeds belangrijker.

Een realistische planning is ook een productbeslissing

De oorspronkelijke doelstelling was om het product binnen ongeveer zes maanden op te leveren. Toen we beter begrepen wat er daadwerkelijk nodig was, vond ik die planning niet realistisch. In zo'n situatie kun je twee dingen doen:

1. Je kunt vasthouden aan de oorspronkelijke datum en hopen dat het onderweg goedkomt.
2. Of je kunt opnieuw kijken naar scope, capaciteit, afhankelijkheden en kwaliteit en daar een realistische verwachting tegenover zetten.

Samen met de betrokkenen hebben we daarom opnieuw naar de planning gekeken. Op basis daarvan kwamen we uit op ongeveer negen maanden. Dat gaf het team voldoende ruimte om niet alleen functionaliteit te ontwikkelen, maar ook integraties goed uit te denken, te testen en het product daadwerkelijk bruikbaar achter te laten.

Uiteindelijk konden we binnen die nieuwe planning opleveren.

Sterker nog: het resultaat ging verder dan de MVP die oorspronkelijk voor ogen was en er was zelfs nog ruimte binnen de planning voor aanvullende werkzaamheden en testen.

Voor mij bevestigde dat iets belangrijks:

Een goede planning gaat niet over zo snel mogelijk een datum noemen, het gaat over begrijpen wat je werkelijk moet bouwen en vervolgens eerlijk zijn over wat daarvoor nodig is.

Techniek begrijpen zonder alles zelf te bouwen

Een van de technisch interessantste onderdelen van de opdracht was de samenhang tussen de nieuwe applicatie en bestaande systemen. De applicatie stond niet op zichzelf. Data, statussen en processen moesten op verschillende plaatsen consistent blijven en veranderingen in het ene systeem konden gevolgen hebben voor het andere.

Daarom heb ik veel gespard met de Senior Developers over de architectuur en de manier waarop de verschillende onderdelen met elkaar moesten samenwerken. Ik hoefde daarbij niet degene te zijn die iedere technische oplossing zelf implementeerde. Mijn verantwoordelijkheid was vooral om voldoende technisch begrip te hebben om de juiste vragen te kunnen stellen, zoals:

• Wat gebeurt er wanneer een status verandert?
• Waar is welke informatie leidend?
• Hoe voorkomen we tegenstrijdige data?
• Wat gebeurt er wanneer een afhankelijk systeem tijdelijk niet beschikbaar is?
• En hoe zorgen we ervoor dat een oplossing niet alleen vandaag werkt, maar ook later nog te onderhouden is?

Voor mij is dat een belangrijk onderdeel van Technical Product Ownership.

Je hoeft niet de beste developer in het team te zijn. Maar je moet technisch genoeg begrijpen wat er gebeurt om samen met developers goede productbeslissingen te kunnen nemen.

Niet alleen opleveren, maar ook goed achterlaten

Aan het einde van de opdracht stond er een werkend product waar zowel het team als de betrokken interne stakeholders tevreden over waren.

Maar een succesvolle oplevering was voor mij niet het moment waarop ons externe team simpelweg kon vertrekken. Daarom hebben we ook aandacht besteed aan overdracht, waar we de volgende vragen hebben beantwoord:

• Welke keuzes hebben we gemaakt?
• Welke onderdelen verdienen in de toekomst extra aandacht?
• Waar zitten afhankelijkheden?
• En wat moet een volgend team weten om verder te kunnen bouwen zonder opnieuw dezelfde vragen te hoeven beantwoorden?

Een goed product moet uiteindelijk zonder zijn oorspronkelijke makers verder kunnen.

Wat ik uit deze opdracht heb meegenomen

Deze opdracht heeft voor mij duidelijk gemaakt dat mijn rol als Technical Product Owner veel verder gaat dan een backlog beheren of tickets schrijven.

Mijn grootste toegevoegde waarde zat juist in het gebied daartussen. Denk hierbij aan:

• De dusinesskennis begrijpen.
• Complexiteit terugbrengen tot concrete problemen.
• Structuur creëren wanneer die nog ontbreekt.
• Met developers technische oplossingen onderzoeken.
• Planning bespreekbaar maken wanneer aannames niet meer kloppen.
• Ervoor zorgen dat verschillende mensen uiteindelijk aan hetzelfde product werken.

Technologie was daarbij belangrijk, maar de techniek alleen was nooit het grootste probleem. De echte uitdaging was om van veel losse kennis, verschillende belangen en technische mogelijkheden één duidelijke richting te maken.

En juist daar ligt voor mij de kracht van een technische productrol:

niet alleen begrijpen hoe iets gebouwd kan worden, maar zorgen dat het team uiteindelijk het juiste product bouwt.