Een dag in het leven van een developer en product owner

Ik ben Thijs Konst, de Product Owner van het RiskChallenger projects platform. Daarnaast ben ik ook developer en draai ik mee in ons development team. Dit zorgt ervoor dat ik naast mijn contact met klanten, onze risicomanagers en andere stakeholders, goed up-to-date blijf met de voortgang van het development team.

‍

Op een normale dag houd ik mij vooral bezig met kijken naar welke nieuwe dingen wij aan onze applicatie willen toevoegen en hoe we ervoor zorgen dat de kwaliteit van ons product zo hoog mogelijk is. Uniek aan RiskChallenger is dat de klanten die ons product gebruiken ook bij ons intern zitten in de vorm van onze consultants. Hierdoor kan ik met hele korte lijnen door krijgen wat er vanuit het veld nodig is en waar wij ons product kunnen verbeteren. Dit maakt ook het ontwikkelen van onze applicatie erg prettig omdat je direct met de gebruiker aan de lunchtafel kan zitten om te overleggen, zonder dat er hiervoor een aparte meeting ingeschoten moet worden.

‍

Mijn motto is "een dag niet geleerd is een dag niet geleefd" en daar sluit mijn normale dag als Product Owner goed bij aan:

‍

09:00 - De dag begint

Wanneer ik op kantoor aankom plof ik mijn tas met spullen neer op een van onze werkplekken en ga ik direct een bak koffie halen. Ik probeer bij te komen met wat er gisteren geprogrammeerd is en check mijn inbox of er vragen van klanten zijn binnengekomen. Meestal gebruik ik deze tijd om de meetings van de dag voor te bereiden of me nog even snel in te lezen over een onderwerp.

‍

9:30 - Eerste meetings

Mijn eerste meeting vandaag is het bijpraten met Harry (Managing Partner) over een klantgesprek die ik samen met Diederik (Managing Partner) en Pim (Unit Manager Sales & Marketing) heb gehad over een toekomstige feature. Harry is voor mij een hele goede bron van informatie over risicomanagement. Ik ben van mijzelf een softwareontwikkelaar en geen risicomanager, dus hij heeft waardevolle inzichten die voor mij niet altijd vanzelfsprekend zijn. Ik vind het belangrijk om te leren van de kennis en ervaring van andere mensen binnen het vakgebied.

‍

Harry en ik hebben vooral gekeken naar hoe onze software kan aansluiten bij de wensen van de klant en hun huidige manier van werken. Omdat wij een SaaS (Software as a Service) ontwikkelen, moeten wij er rekening mee houden dat de software die wij schrijven voor elke klant een positieve toevoeging is, dit zorgt voor een leuke uitdaging om deze specifieke klant zo goed mogelijk te ondersteunen en te kijken naar hoe onze andere klanten gebruik kunnen maken van die ontwikkelingen.

‍

10:30 - Progress meeting Business Unit Projects

Om up-to-date te blijven met de voortgang en om gewoon even bij te praten heb ik één keer in de week een meeting gepland met Marieke, onze Unit Manager Projects. In deze meeting kijken we naar de backlog van issues die open staan voor onze developers en bespreken we of er iets is opgevallen in de afgelopen week.

We zijn op dit moment bezig met het verbeteren van de manier van werken van de developers, want we zijn in het afgelopen jaar zo gegroeid dat onze oude manieren niet meer voldoende waren. Hiervoor duiken we in onze grote lijst met issues die we de afgelopen jaren hebben opgebouwd en kijken we per issue of het nog relevant is en misschien wel belangrijker, of we het issue wel op willen lossen.

‍

Het is een  balanceer-act tussen de tijd die het development team heeft in een week en de wensen vanuit de markt. Als iets een marginale verbetering is, maar veel tijd kost moeten we ons afvragen of het dat wel waard is.

Dit is een van de leukste meetings van mijn week omdat ik (in overleg) een hele hoop oude issues kan sluiten en onze backlog een stuk schoner achterlaat dan wanneer ik begon.

‍

12:00 - Lunchpauze

Om 12 uur word ik geroepen om te lunchen. Meestal werk ik nog even 10 minuten door omdat ik net ergens op gefocust ben.

‍

12:10 - Echte lunchpauze

Ik bouw een tosti en wacht op een plek in het tosti-ijzer. In deze tijd kan ik even lekker tot rust komen en met mijn collega's praten. Soms hebben we het over ontwikkelingen binnen de IT of het risicomanagement, maar vaak gaat het gewoon over koetjes en kalfjes.

‍

13:00 - Stand-up time

Sinds we zijn begonnen met het implementeren van onze nieuwe manier van werken hebben we ervoor gekozen om elke dag een stand-up met het team te plannen. Hierin bespreken we de voortgang en checken we of iedereen nog genoeg heeft om door te werken.

Het is de bedoeling dat aan het eind van deze meetings iedereen weet wat er nog moet gebeuren en wat hun verantwoordelijkheden zijn. Dit is ook een moment om te bespreken of je geblokkeerd wordt of wacht op de code van iemand anders.

‍

13:15 - Tijd om te programmeren

Deze tijd wordt steeds zeldzamer in mijn (als maar drukker wordende) kalender, maar ik krijg het toch voor elkaar om op een normale dag nog een paar uur te ontwikkelen.

‍

Ik ben vandaag aan het werk aan onze nieuwe vote-app. Ik bouw een manier om informatie over onze risico’s vanuit onze "main" applicatie naar de nieuwe vote-app te sturen en te laten zien aan de gebruiker. We moeten erop letten dat wij als ontwikkelaars dezelfde "taal" gebruiken over al onze producten, voor zowel de frontend (gebruiker gericht) en de backend (developer gericht).

In de frontend doen we dat zodat de gebruikers weten wat ze van ons kunnen verwachten en zonder verdere training weten hoe de applicatie werkt. In de backend is dat belangrijk zodat ontwikkelaars niet in stoffige documentatie hoeven te duiken, maar direct bezig kunnen gaan met het ontwikkelen van nieuwe features.

‍

Om ervoor te zorgen dat onze code kwaliteit zo hoog mogelijk blijft, reviewen we elkaars code. Dit is in mijn ervaring een van de beste manieren om jezelf als developer te ontwikkelen, omdat je direct naar de code kijkt die iemand anders geschreven heeft en je vragen kan stellen.

‍

Ik verwerk wat comments op mijn code die achter zijn gelaten door mijn collega's, pas onze geautomatiseerde tests aan en push mijn veranderingen.

‍

Een groot deel van ons team bestaat uit "full-stack" developers en zijn dus verantwoordelijk voor de ontwikkeling van onze volledige applicatie. Dit zorgt ervoor dat iedereen de kennis heeft om alle issues op te pakken en waar er kennis ontbreekt van andere ontwikkelaars te leren en een betere developer te worden.

‍

15:30 - Overleg met een klant

Om te zorgen dat we de juiste requirements hebben voor het development team heb ik regelmatig overleggen gepland met onze klanten.

‍

Als ik hoor dat een klant een bepaalde wens heeft voor een feature in onze applicatie kijk ik zorgvuldig naar wat deze wens inhoudt, of dit binnen onze visie voor het product past en of er niet een andere mogelijkheid is om het probleem op te lossen. Vaak gebeurt het dat een klant een wens heeft om een probleem op te lossen, zonder duidelijk te maken wat het onderliggende probleem is.

‍

Dit is een van de meest leuke en voldoening gevende uitdagingen binnen mijn takenpakket. Ik kan namelijk met deze klant in gesprek om te achterhalen welk probleem er opgelost kan worden en we kunnen er samen achter komen welke oplossing voor ons beiden het beste werkt.

‍

Soms gebeurt het ook dat ik gebruik maak van de expertise van onze klanten op het gebied van risicomanagement om erachter te komen wat we nodig hebben voor een nieuwe feature, zoals vandaag het geval is. Deze klant heeft op dit moment een proces dat handmatig moet worden uitgevoerd en wat redelijk veel (kostbare) tijd in beslag neemt. We kijken samen naar hoe onze applicatie kan helpen om dit proces te versoepelen of zelfs volledig kan automatiseren.

‍

17:00 - Afronden en plannen

Ik maak nog even het stuk code wat ik aan het maken was af en push mijn veranderingen. Ik probeer alles af te krijgen wat ik had gepland, maar soms gaat het even anders dan verwacht. Ik bekijk mijn agenda om te kijken wat voor meetings ik morgen heb staan en sluit mijn laptop, tijd om naar huis te gaan.

‍