Je ticket is gesloten. De gebruiker kon nog steeds niet betalen.

Je backend gaf een 200-statuscode terug. De mobiele app toonde een foutmelding. De gebruiker tikte drie keer op "Betalen". Er werden drie afschrijvingen gedaan op hun rekening. Eén bestelling is voltooid. Hun saldo is nu lager. Je logs tonen nul fouten.

Elke engineer deed zijn werk. Niemand loste het probleem op.

Teams falen vaak niet door slechte code, maar omdat ze het verkeerde werk uitvoeren. Je levert misschien een systeem op dat perfect werkt, maar een verschrikkelijke ervaring creëert.

Junior engineers denken in tickets. Ticket toegewezen. Code geschreven. Tests geslaagd. PR samengevoegd. Ticket gesloten.

Deze mindset is een risico naarmate je groeit. Een engineer die tickets sluit is nuttig. Een engineer die vraagt "lost dit het zakelijke probleem daadwerkelijk op" is onmisbaar.

Neem een betalingsproces. De backend engineer bouwt een endpoint. Het verwerkt afschrijvingen en geeft de juiste codes terug. 100% testdekking. Ticket gesloten. De mobile engineer bouwt het scherm. Het roept het endpoint aan en toont een reactie. Soepele UI. Ticket gesloten.

Het probleem waar niemand eigenaarschap over nam: Wat gebeurt er als de netwerkverbinding wegvalt na de afschrijving, maar voordat de mobiele app de bevestiging ontvangt?

De backend toont succes. De mobiele app toont een fout. De gebruiker probeert het opnieuw en wordt twee keer afgeschreven.

De oplossing is niet alleen een backend- of mobile-fix. Het vereist idempotency-keys. De mobiele app moet voor elke poging een unieke key genereren. De backend moet die key gebruiken om te garanderen dat een herpoging nooit een dubbele afschrijving veroorzaakt.

Deze oplossing komt pas tot stand als engineers met elkaar praten over de gebruikerservaring tijdens netwerkstoringen.

Hetzelfde gebeurt met hardware. De hardware engineer levert firmware. De mobile engineer levert de app. De backend engineer levert de API. Elk onderdeel werkt. Elke test slaagt.

Maar de gebruiker drukt op een knop en het licht gaat pas 11 seconden later aan. De latentie bevindt zich in de gaten tussen de componenten. Geen enkele engineer was verantwoordelijk voor de end-to-end snelheid.

Echte betrouwbaarheid is een systeemkenmerk, geen componentkenmerk.

Om dit op te lossen, moet je de manier waarop je werkt veranderen:

Je functietitel beschrijft je vaardigheden. Het bepaalt niet de grenzen van je verantwoordelijkheid.

Als backend engineer ben je verantwoordelijk voor het feit dat gebruikers betrouwbaar kunnen betalen. Als mobile engineer ben je verantwoordelijk voor het vertrouwen van de gebruiker.

Tickets sluiten is het minimum. Eigenaarschap nemen over het resultaat voor de gebruiker is het hoogst haalbare.

Bron: https://dev.to/walosha/your-ticket-was-closed-the-user-still-couldnt-pay-14di