.svg)
We kregen onlangs een duidelijke herinnering waarom het schrijven van user stories zonder het begrijpen van de onderliggende bedrijfsprocessen simpelweg tijdverspilling is.
Het Open Commerce-team werd ingeschakeld voor een project dat het automatiseren van betalingen voor inkooporders van leveranciers omvatte. De financiële afdeling diende een wijzigingsverzoek in om automatische betalingen te stoppen en een knop “handmatig betalen” toe te voegen aan hun betalingslijst. Dit verzoek volgde op een ernstig incident waarbij een betaling die voor een leverancier bedoeld was, onverklaarbaar naar een andere werd gestuurd.
De redenatie van het financiële team leek logisch: ze wilden elke betaling handmatig controleren voordat deze naar de bank werd gestuurd om verdere fouten te voorkomen. De product owner begon onmiddellijk met het schrijven van een user story: “Als administratief medewerker wil ik inkooporderbetalingen handmatig goedkeuren om onjuiste betalingen te voorkomen.” Het omvatte alles—wireframes, acceptatiecriteria—het volledige pakket.
Maar hier is het punt: als we deze functie hadden ontwikkeld, zou het zijn doel missen.
In een vervolgmeeting betrokken we de collega van de financiële afdeling die het verzoek had ingediend en begonnen we het werkelijke proces van betalingsvalidatie te verkennen. Al snel werd duidelijk dat het handmatig goedkeuren van elke betaling niet de eenvoudige taak was die het leek. Het financiële team beschreef de complexiteit van hun proces—het verifiëren of bedrijfsnamen en bankgegevens overeenkomen, het kruisvergelijken van gegevens met de bank, en het zorgen dat betalingen naar de juiste leverancier gaan. Als we de knop “handmatig betalen” hadden geïmplementeerd, zou dit het team hebben overweldigd, met een onnodige werkbelasting.
Dit is waar het begrijpen van het volledige proces cruciaal is. Ik ben ervan overtuigd dat dit voor velen herkenbaar klinkt; situaties waarin een feature-verzoek wordt ingediend—alleen om een snelle oplossing die de zaken verder bemoeilijkt.
In plaats van door te gaan met de user story zoals deze was geschreven, hebben we een andere benadering gekozen:
- We organiseerden een korte workshop met het financiële team, de product owner en de solutions architect om een gedetailleerd diagram van hun betalingsproces te maken.
- We werkten samen met het ontwikkelingsteam om alle gegevenspunten die betrokken waren bij het validatieproces te identificeren.
- We beoordeelden welke delen van het proces geautomatiseerd konden worden binnen de bestaande geautomatiseerde betalingsopdracht, in plaats van het helemaal stop te zetten.
- Voor de controles die nog handmatige input vereisten, ontwierpen we een toevoeging aan de betalingstakenlijst waarbij alle beschikbare gegevens aan de gebruiker worden gepresenteerd, zodat ze weloverwogen beslissingen efficiënt kunnen nemen.
De les hier? Samenwerking is de sleutel. Door de Subject Matter Experts (SME’s) erbij te betrekken en het proces zorgvuldig in kaart te brengen, kunnen we oplossingen ontwerpen die daadwerkelijk waarde toevoegen. Bij Open Commerce pleiten we hier sterk voor—nauw samenwerken met interne teams om de echte uitdagingen achter de verzoeken te identificeren, te analyseren en aan te pakken.
Voordat je in ontwikkeling springt, zorg ervoor dat de story de kern van het probleem aanpakt, niet alleen het symptoom.
