Van een vaag functieverzoek naar een duidelijk uitvoeringsplan

Iemand zegt: “We moeten de onboarding makkelijker maken.”

Iedereen is het ermee eens. Dan komen de suggesties: een checklist toevoegen, de configuratie inkorten, betere instructies schrijven, een welkomstmail sturen.

Al snel zijn er genoeg ideeën om een sprint te vullen. Minder duidelijk is welk probleem het team probeert op te lossen.

Dit is een goed moment om een mindmap te maken. Die geeft het team een plek om het verzoek te verkennen, ideeën te verbinden en onbeantwoorde vragen zichtbaar te houden voordat het beslist wat het gaat bouwen.

In deze gids volgen we een fictief team dat werkt aan een product met gedeelde werkruimtes. Nieuwe klanten maken een account aan, richten een werkruimte in en nodigen hun teamgenoten uit. Het team heeft de opdracht gekregen die ervaring te verbeteren.

We brengen het verzoek van een open discussie naar een klein, duidelijk omschreven stuk werk in Jira. Je kunt hetzelfde proces volgen met elke mindmaptool.

1. Begin bij het verzoek, zonder het als het antwoord te beschouwen

“De onboarding makkelijker maken” drukt een bedoeling uit. Het vertelt ons nog niet waar mensen vastlopen of wat er moet veranderen.

Het team zet Onboarding verbeteren in het midden van de mindmap en voegt vier takken toe:

• Een account aanmaken
• Een werkruimte inrichten
• Teamgenoten uitnodigen
• Samen de eerste nuttige actie uitvoeren

Dit geeft het gesprek structuur. In plaats van over “onboarding” te praten als één groot probleem, kunnen mensen een specifiek deel van de ervaring aanwijzen.

Het team zet wat het op dit moment weet naast de bijbehorende takken. In ons fictieve voorbeeld heeft de supportafdeling vragen gekregen over waar je collega’s kunt uitnodigen. Tijdens een observatiesessie zoekt een nieuwe eigenaar van een werkruimte op het startscherm van die werkruimte naar een uitnodigingsoptie. Die optie bestaat, maar staat in de instellingen van de werkruimte.

Deze observaties geven een aanknopingspunt voor onderzoek. Ze bewijzen niet dat het hele onboardingproces opnieuw moet worden gebouwd.

Het team laat de andere takken op de mindmap staan en richt zich op Teamgenoten uitnodigen.

2. Scheid wat je weet van wat je denkt

Een verklaring kan al snel als een feit gaan klinken zodra iemand die met overtuiging uitspreekt.

“Mensen nodigen hun collega’s niet uit omdat het uitnodigingsproces te ingewikkeld is.”

Misschien. Maar hebben ze moeite om het uitnodigingsformulier te vinden, het in te vullen of te begrijpen waarom ze nu al iemand zouden uitnodigen? Dat zijn verschillende problemen.

Onder de tak voor uitnodigingen maakt het team drie groepen.

Waargenomen

• De supportafdeling heeft vragen gekregen over waar je teamgenoten kunt uitnodigen.
• Een eigenaar van een werkruimte zocht op het startscherm naar uitnodigingen.
• De huidige uitnodigingsoptie staat in de instellingen van de werkruimte.

Aangenomen

• Een beter zichtbaar toegangspunt zou mensen helpen de optie te vinden.
• Sommige eigenaren beseffen misschien niet dat teamgenoten uitnodigen een nuttige volgende stap is.

Nog onduidelijk

• Kunnen eigenaren het bestaande formulier invullen zodra ze het hebben gevonden?
• Begrijpen de mensen die een uitnodiging ontvangen wat ze daarna moeten doen?

De labels zijn belangrijker dan de visuele vormgeving. Iedereen die de mindmap bekijkt, moet een observatie kunnen onderscheiden van een mogelijke verklaring.

Voordat het team een oplossing kiest, vraagt het enkele nieuwe eigenaren van werkruimtes om een collega uit te nodigen. Het kijkt waar ze zoeken en vraagt wat ze verwachten dat er gebeurt, zonder eerst de uitnodigingsoptie aan te wijzen.

In dit voorbeeld wijzen de sessies erop dat het vinden van het formulier het eerste obstakel is. Zodra eigenaren het toegangspunt krijgen aangewezen, kunnen ze het formulier invullen. De ervaring van de ontvanger moet nog apart worden onderzocht.

Het team kan nu een gerichter probleem beschrijven:

Dat is specifiek genoeg om richting te geven aan het volgende gesprek. Het is ook iets waar het team na een wijziging opnieuw naar kan kijken.

Vergroten

3. Verken enkele antwoorden op hetzelfde probleem

Nu het probleem duidelijker is, kijkt het team opnieuw naar mogelijke verbeteringen. Het voegt drie opties aan de mindmap toe:

• Een actie Teamgenoten uitnodigen op het startscherm van de werkruimte plaatsen.
• Een uitnodigingsstap toevoegen aan de eerste configuratie.
• Een vervolgmail sturen met uitleg over hoe je collega’s uitnodigt.

Elke optie kan helpen, maar bereikt de eigenaar op een ander moment.

De actie op het startscherm is beschikbaar wanneer iemand terugkeert naar de werkruimte. Een configuratiestap introduceert uitnodigingen vroeg, maar sommige eigenaren zijn dan misschien nog niet klaar om mensen uit te nodigen. Een e-mail kan als herinnering dienen, al moet de eigenaar daarna wel terug naar het product.

Het team schrijft naast elke optie een korte notitie over wat die moet vergemakkelijken. Zo blijft het gesprek verbonden met het probleem, in plaats van te veranderen in een stemming over ieders favoriete functie.

Je hoeft niet elke denkbare oplossing in kaart te brengen. Begin met een paar aannemelijke antwoorden en vraag:

• Pakt dit de moeilijkheid aan die we hebben waargenomen?
• Helpt het op het moment dat de eigenaar het nodig heeft?
• Wat moeten we uitzoeken of veranderen om dit te laten werken?

Een nuttige mindmap maakt het makkelijker om deze keuzes te bespreken. Meer takken zijn niet automatisch beter.

Vergroten

4. Kies één nuttige eerste stap

Het team kiest ervoor een zichtbare uitnodigingsactie op het startscherm van de werkruimte te testen.

Waarom deze optie? Ze sluit direct aan op de plek waar eigenaren zochten, en het team kan het bestaande uitnodigingsformulier gebruiken. De actie blijft bovendien beschikbaar voor eigenaren die pas later besluiten collega’s uit te nodigen.

Dit is een beginpunt, geen bewering dat alle onboardingproblemen zijn opgelost.

Het team breidt de gekozen tak uit met de afgesproken scope en noteert naast het plan de uitgestelde ideeën en het nog openstaande onderzoek:

Binnen deze verbetering

• Een uitnodigingsactie met een duidelijk label toevoegen aan het startscherm van de werkruimte.
• Vanuit die actie het bestaande uitnodigingsformulier openen.
• De bestaande uitnodigingsrechten en het verzendgedrag behouden.

Later

• Overwegen of een uitnodigingsstap thuishoort in de eerste configuratie.
• Overwegen of een herinnering achteraf nuttig is.

Te onderzoeken

• De ervaring van het ontvangen en accepteren van een uitnodiging bekijken.

Door deze groepen zichtbaar te houden, voorkom je dat dezelfde besluiten steeds opnieuw ter discussie staan. Het idee voor de e-mail is niet verdwenen. De ervaring van de ontvanger is niet vergeten. Ze maken alleen geen deel uit van deze eerste verbetering.

Op dit punt overlegt het team ook met de mensen die de wijziging gaan implementeren. Een bestaand formulier hergebruiken klinkt eenvoudig, maar er kunnen beperkingen zijn die de aanpak beïnvloeden. Die kun je beter ontdekken voordat je de scope als definitief beschouwt.

Vergroten

5. Beschrijf wat iemand moet kunnen doen

“Een uitnodigingsknop toevoegen” beschrijft een wijziging aan de interface. Het zegt minder over de ervaring die het team wil creëren.

Een nuttigere vraag is:

Het team spreekt een korte lijst controles af:

• Een eigenaar die teamgenoten mag uitnodigen, kan een actie Teamgenoten uitnodigen vinden op het startscherm van de werkruimte.
• Door deze te selecteren, wordt het bestaande uitnodigingsformulier voor de huidige werkruimte geopend.
• De eigenaar kan de uitnodiging voltooien via het bestaande proces.
• Iemand zonder uitnodigingsrechten krijgt via de nieuwe actie geen toegang.
• De actie is bruikbaar op de schermformaten die het product ondersteunt en is met het toetsenbord bereikbaar.

Dit zijn acceptatiecriteria: waarneembare voorwaarden waarmee het team zijn werk kan controleren. Ze hoeven niet als een technische specificatie te lezen.

Er zijn ook twee verschillende vragen die je uit elkaar moet houden. Hebben we de afgesproken wijziging opgeleverd? Die beantwoord je door deze voorwaarden te controleren. Heeft de wijziging uitnodigingen makkelijker vindbaar gemaakt? Daarvoor moet je observeren hoe mensen ermee werken.

Een knop kan precies volgens de specificatie werken en toch over het hoofd worden gezien.

6. Zet het afgesproken werk in Jira

De mindmap heeft het team geholpen het verzoek te verkennen en een beslissing te nemen. De gekozen verbetering is nu klaar om werk te worden dat iemand kan oppakken.

Het team maakt één Jira-ticket voor het afgesproken resultaat. Het maakt niet voor elke tak van de mindmap een ticket.

Dit zou dat ticket kunnen bevatten:

Titel: Uitnodigingen voor teamgenoten toegankelijk maken vanaf het startscherm van de werkruimte

Waarom dit belangrijk is: Nieuwe eigenaren van werkruimtes hadden moeite om de uitnodigingsoptie in de instellingen te vinden. We willen dat eigenaren een uitnodiging kunnen starten vanaf het startscherm, waar ze er al naar zoeken.

Scope: Een actie Teamgenoten uitnodigen toevoegen die het bestaande uitnodigingsformulier voor de huidige werkruimte opent. De bestaande rechtenregels en het uitnodigingsgedrag behouden.

Niet inbegrepen: Een nieuw configuratieproces, herinneringsmails of wijzigingen aan de ervaring van het accepteren van een uitnodiging.

Acceptatiecriteria: Neem de controles op die in de vorige paragraaf zijn afgesproken.

Planningscontext: Link naar de mindmap zodat iedereen die aan het ticket werkt de observaties, alternatieven en beslissing over de scope kan bekijken.

Afhankelijk van hoe het team werkt, kunnen ontwerp en implementatie aparte taken worden. Splits het werk wanneer dat verantwoordelijkheden of oplevering verduidelijkt, in plaats van de structuur van de mindmap automatisch naar Jira te kopiëren.

Een tak ordent gedachten. Een ticket beschrijft werk. Ze hoeven niet één op één overeen te komen.

Als je mindmaptool met Jira verbonden is, kun je het ticket mogelijk vanuit het geselecteerde knooppunt maken en de koppeling zichtbaar houden op de mindmap. Zo niet, dan kun je het ticket apart maken en een link toevoegen. Controleer in beide gevallen het ticket voordat je het overdraagt: het korte label van een knooppunt bevat zelden alle context die iemand nodig heeft.

Zodra de uitvoering begint, houd je de status en verantwoordelijkheden bij in Jira. Gebruik de mindmap voor het bredere probleem, de redenering achter het besluit en de vragen die nog openstaan. Zo heeft elke plek een duidelijk doel en is de verleiding kleiner om twee aparte takenlijsten bij te houden.

Vergroten

7. Controleer of het oorspronkelijke probleem is verminderd

Nadat de wijziging is uitgebracht, keert het team terug naar de zin die het eerder opschreef:

Kunnen nieuwe eigenaren de uitnodigingsactie nu vinden zonder dat iemand aanwijst waar die staat? Kunnen ze verder met het bestaande formulier? Wijzen gesprekken met support erop dat dezelfde verwarring nog steeds voorkomt?

Als het team over geschikte productmetingen beschikt, kan het ook bekijken hoeveel nieuwe eigenaren van werkruimtes een uitnodiging starten en voltooien. Die cijfers hebben context nodig: sommige eigenaren werken mogelijk bewust alleen, en andere wijzigingen kunnen de resultaten beïnvloeden.

Voor dit fictieve verhaal hoeven we geen succesvol resultaat te verzinnen. De nuttige volgende stap is observeren wat er gebeurt en die inzichten aan de mindmap toevoegen.

Als eigenaren de actie vinden maar verderop vastlopen, heeft het team een specifieker probleem om te onderzoeken. Als de wijziging helpt, kan het beslissen of een volgende verbetering de moeite waard is.

Het oorspronkelijke verzoek was breed. Het resulterende plan is gericht: een duidelijk probleem, een gekozen antwoord, een behapbare scope en een manier om te controleren of de verbetering heeft geholpen.

Dat maakt de mindmap nuttig. Ze brengt het gesprek van “we zouden dit moeten verbeteren” naar een afgesproken volgende stap, terwijl de redenering en onbeantwoorde vragen in beeld blijven.