Vereisten perfect beheersen (met Kelly Suter van BI Worldwide)

Lees het transcript:

We proberen onze podcasts te transcriberen met behulp van een softwareprogramma. Vergeef ons eventuele typfouten, want de bot is niet altijd 100% correct.

Ben Aston:

Welkom bij de DPM-podcast, waar we verder gaan dan theorie om deskundig PM-advies te geven voor het leiden van betere digitale projecten. Bedankt voor het luisteren. Ik ben Ben Aston, oprichter van The Digital Project Manager. Wees eerlijk: heeft je klant zich ooit aan het einde van je project omgedraaid en gezegd: “Hé, je hebt dit absoluut perfect gedaan. Het is precies wat we wilden, het is precies wat je aan het begin van het project zei dat je zou doen, en het is geweldig hoe je alles hebt weten vast te leggen zonder onderweg dingen te laten vallen.”

Nou, ik vermoed dat dit niet is gebeurd. En dat komt waarschijnlijk doordat je vereisten niet goed waren vastgelegd. Dus hoe beheer je vereisten zo dat je jezelf later in het project niet volledig in de problemen brengt, maar de klant en de ontwikkelaar wel geven wat ze nodig hebben om de klus te klaren? Daar gaat de podcast van vandaag over: projectvereisten.

De manier waarop we een project en functionaliteiten voor onze klanten definiëren, zodat iedereen weet wat er wordt opgeleverd. In wezen zijn vereisten volgens mij een communicatiemiddel, maar het is erg moeilijk om dit goed te doen. Als we de vereisten te losjes definiëren, geven we onszelf weliswaar meer flexibiliteit, maar krijgen we misschien niet precies terug wat we wilden. En als we ze te strak definiëren, zullen we merken dat er misschien veel dingen ontbreken. Hoe vinden we dus de juiste balans?

Vandaag praat ik met Kelly Suter. Kelly is technisch projectmanager bij BI Worldwide en een van onze vaste Deakin-experts bij The Digital Project Manager. Hoi Kelly.

Kelly Suter:

Hallo, bedankt dat ik er mag zijn, Ben.

Ben Aston:

Nee, geweldig dat je er bent. Volgens mij is dit onze tweede podcast, toch?

Kelly Suter:

Ja, dat klopt.

Ben Aston:

We hebben lang geleden een podcast gedaan. Voor de mensen die zijn vergeten wie je bent: wil je ons een overzicht geven? Hoe ben je in projectmanagement terechtgekomen? Je hebt volgens mij een interessante route gevolgd, zoals de meeste projectmanagers. We waren niet van plan om projectmanager te worden toen we opgroeiden. Vertel ons dus iets over je verhaal. Hoe komt het dat je nu een digitale PM bent?

Kelly Suter:

Ja, ik begon mijn professionele loopbaan eigenlijk als sportverslaggever. Ik had Communicatie gestudeerd met een focus op public relations en media. Toen ik besefte dat kranten niet langer een groeimarkt waren, besloot ik naar de publiciteitssector over te stappen. Ik was ongeveer drie jaar publicist voor één merk: Sesame Street Live. Daarna kende ik iemand die bij een maatwerk-e-commercebedrijf werkte, een digitaal bureau dat volledige diensten leverde en zich uitsluitend op e-commerce richtte.

Ze zei: “We hebben hier geen afdeling projectmanagement. Wil je projectmanager worden?” Ik zei: “Wat is dat?” Mijn vader had een grafisch ontwerpbureau, dus ik was van jongs af aan voldoende bekend met bureauprocessen om te weten dat het er hectisch en voortdurend druk was. Maar ik dacht: “Ja, ik wil het proberen. Laten we kijken wat jullie daar doen.” Ik ging er werken en het eerste boek dat ik ooit las was van Meghan McInerny: People, Pixels, and Process. Ik weet niet of ik het in de juiste volgorde zei, maar ik las het en paste het toe—

Ben Aston:

Ik weet welk boek je bedoelt, ja.

Kelly Suter:

Ja. Ik—

Ben Aston:

People, Pixels… Volgens mij is het People, Pixels, and Process, ja.

Kelly Suter:

Precies. Ik paste het zo goed mogelijk toe op het bureau dat ik voor me zag. Destijds waren we met twaalf mensen. Zoals ik zei, maakten we maatwerkbrochurewebsites en e-commercesites. Vier jaar later had ik een team van zeven projectmanagers opgebouwd. We konden een proces toepassen dat voortdurend bleef evolueren. Daarna dacht ik: ik voel me erg op mijn gemak met Magento, Drupal, Cantego, WordPress en dergelijke, maar ik wil mijn technische kennis uitbreiden. Er kwam een functie voor technisch projectmanagement beschikbaar bij mijn huidige werkgever, BI Worldwide. Ik stapte dus over, omdat ik weer midden in de PM-wereld wilde zitten, dichter op projecten wilde werken en mijn technische vaardigheden wilde aanscherpen. Daar ben ik nu. Het is echt spannend geweest. Het lijkt voorbij te zijn gevlogen, maar ik vind het geweldig.

Ben Aston:

Ik ben altijd nieuwsgierig: is dit nu je droombaan? Het klinkt alsof je een traject hebt afgelegd van sportverslaggever naar Sesame Street en nu naar technologie als projectmanager. Maar wat wil je worden als je later groot bent?

Kelly Suter:

Dat is een goede vraag. Wat ik het leukst vind aan mijn huidige werk en aan mijn vorige baan bij Irish Titan, een ander ontwikkelingsbedrijf, is dat ik graag terechtkom in situaties waarin een proces nog niet echt bestaat of net begint te ontstaan. Niet omdat het team niet getalenteerd is of geen goed werk levert, maar omdat ik het geweldig vind om uitdagingen rechtstreeks aan te pakken: kijken waar processen kunnen worden ingevoerd, uitzoeken wat werkt en teams de opluchting geven van “We hebben iets om mee te werken, iets om op te steunen.” Ik denk dus dat mijn droombaan is om als een soort brandweerman te werken voor opkomende bedrijven, misschien start-ups, en binnen te komen met de boodschap: “Goed, we hebben dit proces ingevoerd. Laten we kijken of jullie het ook hiermee en hiermee kunnen doen.” Ik houd namelijk van een flinke uitdaging.

Ben Aston:

Mooi. Vertel eens: met welke uitdagingen houd je je momenteel bezig? Je probeert processen glad te strijken en vast te leggen. Wat zijn de dagelijkse uitdagingen, of is er een specifieke uitdaging waar je nu aan werkt?

Kelly Suter:

Op dit moment is mijn grootste uitdaging, naast alle andere uitdagingen waar we altijd mee te maken hebben, om op een niet-saaie manier draagvlak in het team te creëren voor documentatie. Het is moeilijk wanneer je een enthousiaste klant en een enthousiast team hebt om volledige steun te krijgen voor: “We hoeven niet te vertragen en geen momentum te verliezen, maar we moeten wel documenteren.” Vervolgens moet je die documentatie in sjablonen gieten en je basis voldoende afdekken. Het hoeft niet zo pijnlijk te zijn als het kan worden, maar je moet genoeg documenteren zodat er niets verloren gaat wanneer je naar een ander team overstapt, promotie maakt of een andere rol krijgt. Ik heb teams gezien die voortdurend het wiel opnieuw uitvinden, bij het bouwen van hun product of bij hun documentatie. Ze maken iets dat eenvoudig in een sjabloon zou kunnen worden gezet onnodig ingewikkeld.

Op dit moment maak ik documentatie voor iets waarvan de meest recente versie uit 2014 komt. Het heeft voor iedereen gewerkt, ook voor de klant, maar we willen het niet zo laten. Later, bij een audit, is het prettig als alles netjes is vastgelegd.

Ben Aston:

Je houdt je dus bezig met het definiëren en verfijnen van processen en het maken van documentatie. Gebruik je daar bepaalde hulpmiddelen voor? Wat maakt je leven momenteel gemakkelijker?

Kelly Suter:

Voor documentatie geldt: ik repareer niet wat niet kapot is. Ik gebruik Google Suite. Als klanten geen beveiligings- of privacyproblemen hebben met de informatie die je formaliseert, zijn Google Suite, Google Docs en een gedeelde werkruimte erg handig. Je kunt instellen wie alleen mag bekijken, wie mag reageren en wat alleen intern gedeeld wordt.

Je hoeft dan niet na te denken over versiebeheer en kunt het later als pdf exporteren om er een formeel ondertekenbaar document van te maken. Voor het daadwerkelijk schrijven van documentatie gebruiken wij dat. InVision is een geweldig hulpmiddel voor creatieve controles en feedback wanneer je het creatieve onderdeel samenstelt. Ontwerpers plaatsen er hun ontwerpen of wireframes in. Vervolgens kun je je klant of belanghebbende laten reageren. Zodra ontwerpen definitief zijn, kun je ze in InVision annoteren en exporteren voor je documentatie. Visuele elementen zijn daarbij erg nuttig. Als je geen InVision hebt omdat je ervoor moet betalen en het duur kan worden, kun je Sketch gebruiken. Sketch is een gratis hulpmiddel van Evernote waarmee je ontwerpen eenvoudig en mooi kunt annoteren. Je uploadt je ontwerpen, voegt nummers of letters toe en werkt er zo mee.

Ik maak het dus niet onnodig ingewikkeld. Ik heb alleen een manier nodig om ontwerpen te importeren, ze te annoteren, ze in documentatie te zetten en vervolgens de tekst te schrijven.

Ben Aston:

Ik wil nog wat dieper ingaan op je ontwikkeling als digitale projectmanager. Je bent nu technisch PM, maar je draagt verschillende petten: projectmanager, BA, bedrijfsanalist en SCRUM-master. Waarin verschilt een technisch PM van een DPM? Is het hetzelfde? En hoe werkt het voor jou om die verschillende rollen te combineren?

Kelly Suter:

Dat is een goede vraag. In mijn huidige functie heb ik geluk omdat die uniek is. Bij BIW doe ik zowel technisch projectmanagement als traditioneel projectmanagement. Ik werk aan live-evenementen en aan content en cursusmateriaal. Dat is ongeveer een kwart van mijn werk. De overige driekwart bestaat uit technisch projectmanagement. Het verschilt per organisatie.

Je ziet woorden als digitaal, technisch en agile vóór projectmanagement staan. Het grootste verschil tussen mijn vorige rol als DPM en mijn huidige rol als TPM is volgens mij het vereiste inzicht in het digitale werk dat je uitvoert. Hoe technisch wordt dat digitale werk? Als digitale projectmanager hield ik me bezig met alle bewegende onderdelen. Ik werkte op een wat hoger niveau, maar wist dat ik contentstrategie, sitestructuur, wireframes en creatief werk moest begrijpen. Bij ontwikkeling dacht ik eerder: “Ik weet dat jullie deze gegevens moeten controleren en moeten bepalen hoe de export voor de voorraad eruitziet. Laat me weten wanneer jullie klaar zijn.”

In mijn huidige rol als technisch PM zit ik veel dieper in de ontwikkeling. Ik beheer nog steeds de opleveringen van creatie, digitale strategie en kwaliteitscontrole, maar bij ontwikkeling werk ik nauwer samen met de hoofdontwikkelaar. Tijdens codebeoordelingen en releases zeg ik bijvoorbeeld: “Dit zijn de vereisten die ik heb geschreven. Hoe verhouden die zich tot de code die je ziet voordat we dit van de lijst afvinken?” Een ander verschil is dat ik de technische vereisten schrijf. Hoe dichter je bij de vereisten zit, hoe groter je verantwoordelijkheid en hoe dichter je betrokken moet blijven wanneer er later vragen ontstaan.

Als digitale PM beheerde ik de vereisten, vertelde ik de juiste mensen wat ze moesten doen en zorgde ik dat het gebeurde. Als TPM schrijf ik die vereisten zelf. Ik zit dus dieper in de loopgraven van de ontwikkeling.

Ben Aston:

Voor mensen die niet bekend zijn met functionele vereisten of bedrijfsvereisten: jij doet dus het ontwerpen van functionele vereisten en bedrijfsvereisten. Dat is vaak een wat stroef en verwarrend gebied, omdat ontwikkelaars kunnen zeggen: “Dat is de taak van de PM” of “Dat is de taak van de bedrijfsanalist.” Aan de andere kant kunnen de BA of PM zeggen: “Ik kan dit niet definiëren, want ik weet niet welke opties er zijn.” Jij zit daar ergens tussenin. Hoe pak je dat proces aan?

Kelly Suter:

Aan het begin van elk project, wanneer je bij een team of bedrijf komt, moet je de rollen en verantwoordelijkheden goed begrijpen. Ze kunnen wel gedefinieerd zijn, maar afhankelijk van de klant kunnen ze evolueren of veranderen. Bij een maatwerkintegratie kan ik bijvoorbeeld zeggen: “Dit is een integratie met een voorraad-database. Ik wil dat de gegevens live worden bijgewerkt en precies tonen hoeveel kleine, middelgrote en grote T-shirts op voorraad zijn. De gegevens moeten dagelijks op dit tijdstip worden bijgewerkt.”

Ik kan de ontwikkelaar vertellen wat er moet gebeuren, maar die gaat misschien een niveau dieper waarop ik geen invloed heb en dat ik niet begrijp. Ik wil niet doen alsof ik het begrijp. Ik wil samen gaan zitten en zeggen: “Ik neem de vereisten tot dit punt voor mijn rekening. Kun jij helpen de rest uit te werken door de vijf waarom-vragen te stellen?” Waarom moet dit op deze manier worden ingevuld? Omdat bezoekers dit product zo vaak kopen. Waarom? Enzovoort.

Op een bepaald moment moet je zeggen: “Ontwikkelaar, ik heb je hulp nodig om de rest van deze vereisten voor deze functie te schrijven, omdat ik het niet kan en niet wil riskeren dat er iets tussen wal en schip valt.” Het is dus een balans. Je moet vooraf bepalen wat je wel en niet kunt doen. Het belangrijkste is dat mensen het niet persoonlijk opvatten wie wat beheert. Je speelt gewoon in op elkaars sterke punten. Daarover moet wel communicatie zijn.

Ben Aston:

Wat zijn die documenten precies? Waarom zijn ze belangrijk? Sommige bureaus ontwerpen gewoon iets, dragen het over aan ontwikkelaars en laten het bouwen. Is dit niet het tegenovergestelde van agile en flexibel werken?

Kelly Suter:

Een document met bedrijfsvereisten, of BRD, kun je vergelijken met een introductiecursus. Het bevat soms de belangrijkste punten: we moeten dit naar het Spaans en Mandarijn vertalen, tien cursussen opleveren, vóór april live zijn en een database van 6.000 gebruikers of die hoeveelheid verkeer ondersteunen. Het BRD is in feite: “Dit is wat we tot nu toe hebben besproken. Zorg dat je in de juiste richting werkt.” Het is ook een formeel controle- en goedkeuringsmoment voor beide partijen om te bevestigen dat iedereen hetzelfde begrijpt. Natuurlijk staat er ook in dat we dit verder zullen definiëren en dat we het melden wanneer iets buiten de scope valt of het budget overschrijdt. We herprioriteren en bepalen wat doorgaat, wat vervalt en wat naar fase twee verschuift.

Een document met functionele vereisten, of FRD, is een volgend controlepunt. Tussen het BRD en FRD gebeurt veel. Je neemt elk punt en werkt het verder uit. We gaan bijvoorbeeld naar het Spaans en Mandarijn vertalen. Doen we dat via een externe leverancier? Schrijven we code om het te automatiseren? Of voert een beheerder de drie talen handmatig in het contentmanagementsysteem in? Je werkt al die punten uit. Het BRD bevestigt dus dat iedereen hetzelfde begrijpt, terwijl het FRD je blauwdruk voor de bouw wordt.

Ben Aston:

Het BRD definiëren we aan het begin van het project. Het beschrijft vanuit zakelijk perspectief wat succes betekent. Het FRD bepaalt hoe een bepaalde functionaliteit moet werken. Als een site toegankelijk en leesbaar moet zijn voor mensen in China, moet die in het Mandarijn beschikbaar en gelokaliseerd zijn. Daar gaan we de details in.

Hoe kijk je naar agile werken? Sommige ontwikkelaars willen eerst alle vereisten zien, terwijl anderen zeggen dat we agile moeten werken en in kleine onderdelen moeten itereren zonder enorme hoeveelheden documentatie te maken. Hoe vind je die balans?

Kelly Suter:

Door vooraf duidelijkheid te creëren. Durf ik documentatie te zeggen? Leg vast dat we volgens een agile proces werken, wat dat betekent en wat we van de klant en intern nodig hebben. Organiseer een stevige interne kick-off. We bouwen momenteel bijvoorbeeld software die punten koppelt aan leren. Gebruikers volgen cursussen, maken vorderingen en verdienen punten die ze later op een marktplaats kunnen gebruiken.

We weten niet wat we niet weten. De klant weet dat hij het wil en wanneer het klaar moet zijn, en vertrouwt erop dat wij het kunnen maken. We hebben niet altijd tijd om alles vooraf te documenteren. Dan moet je het einddoel vastleggen zonder alle tussenstappen vooraf uit te werken. Tijdens de wekelijkse stand-up bespreken we wie aan badges, certificaten, een ranglijst en de winkelervaring werkt.

Elke twee weken presenteren we een release aan de klant. Die weet dat het werk nog ruw is en dat het niet om een afgewerkt uiterlijk gaat, maar om het realiseren van de functionaliteit. Stand-ups zijn onmisbaar. Als PM kun je ze documenteren: wat tonen we vandaag, wat kan de klant verwachten en welke vragen hebben we? Wanneer de klant zegt dat hij iets anders had verwacht, ontstaat er ruimte om dat te bespreken en een plan voor de volgende week te maken.

Je moet voortdurend naar het traject kijken. Hoe staan we ervoor ten opzichte van het eindproduct? Moeten we bijvoorbeeld certificaten uitstellen om ons op iets belangrijkers te richten? Het gaat om voortdurende communicatie, documentatie tijdens het proces en vertrouwen.

Ben Aston:

Dat voorkomt dat een project aan het begin stilvalt omdat je alles eerst volledig wilt definiëren. Functionele vereisten geven ontwikkelaars duidelijkheid over wat ze moeten bouwen, klanten inzicht in wat ze krijgen en QA duidelijkheid over wat ze moeten testen. Je werkt de vereisten gaandeweg verder uit.

Het documenteren kost natuurlijk tijd. Doe je dat in JIRA terwijl je een ticket schrijft?

Kelly Suter:

Wanneer ik een FRD heb afgerond, heeft het team meegekeken en is het document door de klant goedgekeurd. Daarna presenteer ik het aan het ontwikkelingsteam. Sommige ontwikkelaars willen precies weten wat hun taken zijn. Anderen willen niet dat je voorschrijft hoe ze hun werk moeten doen. Daarom vraag ik eerst of zij de taken zelf willen opbouwen of dat ik dat moet doen.

Meestal vinden ze het goed als ik de taken opbouw. Ik maak één taak per regelitem en groepeer verhalen per paginatype, zoals registratiepagina, homepage of productpagina. Voor elk regelitem op die pagina maak ik subtaken. Vervolgens laat ik ontwikkelaars hun eigen tijd inschatten. Laat bij voorkeur de persoon die het werk uitvoert de inschatting maken.

Ik gebruik JIRA van Atlassian voor taakbeheer. Nadat alles in de backlog staat, schatten de ontwikkelaars het werk in en ordenen ze het op de manier waarop ze het willen aanpakken. Daarna verdeel ik het in sprints op basis van werkweken van ongeveer dertig uur. Als je agile werkt en voor elke taak kwaliteitscontrole nodig hebt, voeg je in elk ticket toe hoe je bepaalt of de taak geslaagd is.

Ben Aston:

Laten we het hebben over inschattingen. Een klant wil aan het begin weten wat een project kost, terwijl de functionaliteit nog niet volledig bekend is. Hoe geef je dan een vroege raming?

Kelly Suter:

Dat is een ingewikkelde vraag. Als ik invloed had op de raming van mijn projecten, zou ik zeggen dat ik in 90 tot 95 procent van de gevallen geen formele invloed heb. Wanneer ik wel om een raming wordt gevraagd, wil ik eerst op hoofdlijnen weten wat we al eerder hebben gedaan. Kijk naar overeenkomsten in gebruikersaantallen, bedrijfsomvang of eerdere projecten en gebruik die als referentie.

Je kunt bijvoorbeeld weten dat een bepaalde e-commercebouw vroeger zes tot acht weken duurde met twee ontwikkelaars. Dat geeft een uitgangspunt, maar geen garantie. Als er geen integraties of maatwerk nodig zijn, kun je een basisinschatting geven. Anders heb je iemand nodig die namens de ontwikkelafdeling kan spreken. Het helpt om referentiegegevens bij de hand te hebben voor e-commerce, leerbeheersystemen of andere soorten projecten.

Ben Aston:

Dat is analoog ramen: vergelijkbare projecten gebruiken om een vroege bandbreedte te bepalen. Je kunt een lage en hoge kant aangeven en uitleggen dat de uiteindelijke raming pas betrouwbaarder wordt wanneer de vereisten verder zijn uitgewerkt.

Kelly Suter:

Twee oefeningen helpen mij daarbij. Vanaf de kick-off teken ik een driehoek met scope, planning en budget. Ik laat de klant deze rangschikken van één tot drie. Eerst zeggen ze vaak dat alles even belangrijk is, maar daarna moeten ze toch kiezen. Die prioriteiten kunnen later veranderen.

De tweede oefening is goed, beter, best. Als de klant een bepaald budget heeft, bespreken we wat binnen dat budget past. Als er een integratie bijkomt of een externe leverancier iets buiten scope brengt, leggen we uit wat het kost, wat er binnen het budget niet geleverd wordt en welke tussenoplossing mogelijk is. Zo maak je van de keuze een gezamenlijke zakelijke beslissing.

Ben Aston:

Dat is vooral nuttig bij vaste prijzen en technisch complexe projecten. Je helpt de klant begrijpen dat meer functionaliteit meer werk betekent en stemt de raming en aanpak af op de prioriteiten.

Wat zou je zeggen tegen iemand die voor het eerst vereisten gaat schrijven?

Kelly Suter:

Je weet waarschijnlijk meer dan je denkt. Je bent al blootgesteld aan digitaal gedrag en technologie. Spring niet meteen naar Google om een sjabloon voor technische documentatie te downloaden. Neem eerst afstand en vraag: wat bouwen we voor deze klant? Bijvoorbeeld een registratiepagina voor een evenement met een homepage en een webformulier. Wat moet er hier worden gedefinieerd? Zoek elk element op de pagina en vraag wat het doet op mobiel en desktop.

Leg het hardop uit alsof je het vertelt aan iemands grootmoeder, die nog een ouderwetse Nokia-telefoon gebruikt. Ga daarna naar de ontwikkelaar en vraag of je het goed hebt begrepen. Ontwikkelaars waarderen dat je vragen stelt en probeert iets zo te definiëren dat zij succesvol kunnen bouwen.

Verdeel de documentatie dus in onderdelen van wat je bouwt en leg elk onderdeel uit. Je eerste documentatie zal waarschijnlijk niet perfect zijn en misschien wat gespreksmatig klinken. Dat is niet erg. Het ontwikkelt zich. Jij vertegenwoordigt de expertise van je bedrijf, groep of team, dus loop het samen met de klant door. Je weet meer dan je denkt, omdat we allemaal in deze digitale wereld leven.

Ben Aston:

Vereisten gaan uiteindelijk over vragen stellen en antwoorden krijgen. Niets is vanzelfsprekend. Begin met jezelf af te vragen wat je zou moeten uitleggen aan je moeder of grootmoeder. Vergeet ook niet dat vereisten een communicatiemiddel zijn waarmee iedereen hetzelfde begrijpt wat er wordt gedaan.

Wanneer je duidelijkheid hebt over het werk, verspil je minder tijd aan verwachtingsmanagement en herstelwerk. Het kost tijd om documentatie te maken, maar die investering levert veel op wanneer de klant niet teleurgesteld raakt omdat hij iets anders heeft gekregen dan verwacht.

Kelly, bedankt dat je bij ons was.

Kelly Suter:

Bedankt, ik waardeer het.

Ben Aston:

Als een van onze DPM-experts verschijnt Kelly ook in onze cursus Meester worden in digitaal projectmanagement. Als je niet weet waar ik het over heb, maar wel PM-training nodig hebt, neem dan een kijkje. We hebben een intensieve cursus van zeven weken met interactieve videolessen, opdrachten, groepsdiscussies en webinars. Ga naar dpmschool.com en schrijf je in. Onze cursus begint in februari. Wil je bijdragen aan het gesprek over vereisten en hoe we ermee werken, ga dan naar het gedeelte bronnen van thedigitalprojectmanager.com en sluit je aan bij ons Slack-team. Daar vind je allerlei interessante gesprekken. Je kunt ook gewoon reageren op het bericht. Tot de volgende keer, bedankt voor het luisteren.