Warum Ticket-Abschlüsse allein keine Software-Probleme lösen

In vielen Tech-Teams herrscht eine gefährliche Illusion: Der Job ist erledigt, sobald eine Aufgabe als „abgeschlossen“ markiert wird. Doch was passiert, wenn diese Aufgabe zwar technisch korrekt implementiert ist, aber das eigentliche Geschäftsproblem ungelöst bleibt? Ein klassisches Beispiel ist die Zahlungsabwicklung – ein Szenario, das in der Praxis häufiger vorkommt, als es Entwickler offen zugeben.

Stellen Sie sich vor: Ein Nutzer versucht, eine Zahlung über eine Mobile App zu tätigen. Der Backend-Service verarbeitet die Anfrage fehlerfrei, die Mobile App zeigt jedoch einen „Zahlungsfehler“ an. Der Nutzer versucht es erneut – und wird doppelt belastet. Beide Systeme arbeiten einwandfrei. Doch das eigentliche Problem? Niemand hat die Nutzererfahrung über den gesamten Prozess hinweg betrachtet.

Der Unterschied zwischen Aufgabe und Problem

Frühe Karrierephasen in der Softwareentwicklung sind oft von einem klaren Muster geprägt: Ein Ticket wird zugewiesen, der Code geschrieben, getestet und schließlich geschlossen. Diese Herangehensweise ist für den Einstieg unverzichtbar. Doch sie birgt ein Risiko: Sie fördert das Denken in isolierten Komponenten statt in ganzheitlichen Lösungen.

Ein Entwickler, der sich als „Ticket-Abschliesser“ versteht, liefert zuverlässige Arbeit ab. Doch ein System-Owner hinterfragt: Welches Problem löst dieses Ticket wirklich – und löse ich es an der richtigen Stelle? Diese Frage ist nicht nur akademisch. Sie entscheidet darüber, ob ein Produkt am Ende zufriedene Nutzer oder frustrierte Anwender schafft.

Ein konkretes Beispiel: Ein Backend-Entwickler implementiert einen Zahlungs-Endpoint, der korrekte Statuscodes zurückgibt und alle Tests besteht. Ein Mobile-Entwickler baut eine Benutzeroberfläche, die die Antworten des Backends verarbeitet und dem Nutzer eine Rückmeldung gibt. Beide Aufgaben sind abgeschlossen. Doch was passiert, wenn das Netzwerk genau in dem Moment ausfällt, in dem das Backend die Zahlung verarbeitet, die Mobile App aber die Bestätigung nicht erhält? Der Nutzer sieht einen Fehler, versucht es erneut – und wird doppelt belastet. Beide Entwickler haben ihre Aufgabe perfekt gelöst. Doch das eigentliche Geschäftsproblem – die Zahlung zuverlässig einmalig zu bestätigen – blieb ungelöst.

Praxisfall 1: Die Zahlung, die gleichzeitig funktionierte und scheiterte

Dieses Szenario ist in der Produktion häufiger anzutreffen, als viele Teams zugeben. Die typische Abfolge einer Zahlungsabwicklung sieht so aus:

• Die Mobile App initiiert die Zahlung.
• Der Backend-Service verarbeitet die Anfrage und leitet sie an den Zahlungsanbieter weiter.
• Der Zahlungsanbieter bestätigt die Transaktion.
• Der Backend-Service sendet eine Bestätigung an die Mobile App.
• Die Mobile App zeigt dem Nutzer den Erfolg an.

An jeder dieser Schnittstellen kann es zu Verzögerungen kommen – sei es durch Netzwerkprobleme, Serverlast oder einfach durch die natürliche Latenz im globalen Datenverkehr. Fällt die Verbindung zwischen dem Backend-Service und der Mobile App nach der Bestätigung durch den Zahlungsanbieter, aber vor der Rückmeldung an die Mobile App aus, entsteht eine gefährliche Lücke.

Der Backend-Service und der Zahlungsanbieter loggen einen Erfolg. Die Mobile App zeigt jedoch einen Fehler an. Ein verunsicherter Nutzer versucht es erneut. Das Ergebnis? Eine doppelte Belastung. Die Lösung liegt nicht in der Optimierung einer einzelnen Komponente, sondern in der Einführung eines Idempotenz-Schlüssels.

// Mobile App: Generierung und Speicherung eines eindeutigen Schlüssels pro Zahlungsversuch
const idempotencyKey = `pay_${userId}_${orderId}_${Date.now()}`;
localStorage.setItem('pending_payment_key', idempotencyKey);

// Jeder Wiederholungsversuch der Zahlung enthält diesen Schlüssel
const response = await fetch('/api/payments', {
  method: 'POST',
  headers: {
    'Idempotency-Key': idempotencyKey,
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({ amount, currency, orderId })
});

Der Backend-Service prüft nun bei jeder Anfrage, ob bereits eine erfolgreiche Transaktion mit diesem Schlüssel existiert. Falls ja, wird die bestehende Transaktion zurückgegeben – ohne eine neue Zahlung zu initiieren. Erst wenn keine bestehende Transaktion gefunden wird, wird der Zahlungsanbieter kontaktiert.

// Backend: Prüfung auf bestehende Transaktionen mit demselben Schlüssel
async function processPayment(req) {
  const idempotencyKey = req.headers['idempotency-key'];
  const existing = await db.payments.findOne({ idempotencyKey });

  if (existing?.status === 'success') {
    return existing; // Erfolgreiche Transaktion erneut zurückgeben
  }

  const charge = await paymentProcessor.charge(req.body);
  await db.payments.create({ idempotencyKey, ...charge });
  return charge;
}

Dieser Ansatz funktioniert nur, wenn Entwickler beider Systeme zusammenarbeiten und sich nicht nur auf ihre individuellen Aufgaben konzentrieren, sondern auf das große Ganze: Wie sieht die Nutzererfahrung aus, wenn das Netzwerk versagt?

Praxisfall 2: Das „funktionierende“ Smart-Home-Gerät mit katastrophaler Latenz

Ein weiteres Beispiel für das Missverständnis zwischen Aufgabe und Problem findet sich im Smart-Home-Bereich. Ein Team entwickelt ein Gerät, das aus drei Komponenten besteht: Hardware, Mobile App und Backend-Service. Jede Komponente wird einzeln getestet und als „funktionierend“ markiert. Doch die Nutzererfahrung leidet unter einer kumulativen Verzögerung.

Ein Nutzer drückt den Knopf, um ein Licht einzuschalten. Die Hardware sendet den Befehl an das Backend. Das Backend verarbeitet die Anfrage und sendet eine Push-Benachrichtigung an die Mobile App. Die Mobile App aktualisiert die UI. Die Lichtverzögerung beträgt insgesamt 11 Sekunden. Keine Komponente ist defekt – jede fügt jedoch 3 bis 4 Sekunden eigene Verzögerung hinzu.

Das Problem? Niemand hat die End-to-End-Latenz gemessen. Die Nutzerbewertungen sprechen von „träger“ oder „unreagierbarer“ Bedienung. Die Entwicklerteams analysieren ihre Komponentenmetriken und finden nichts Auffälliges. Der Grund: Die Zuverlässigkeit wurde als Eigenschaft einzelner Teile behandelt – nicht als Eigenschaft des gesamten Systems.

Echte Nutzererfahrung entsteht erst an der Schnittstelle aller Komponenten. Selbst wenn das Backend eine Verfügbarkeit von 99,9 % aufweist, kann die Mobile App nur alle 5 Sekunden nach Updates fragen. Die Hardware benötigt zusätzliche Zeit für die Übertragung. Die Cloud-zu-Mobile-Push-Benachrichtigung fügt weitere Latenz hinzu. Die einzige Möglichkeit, solche Probleme zu erkennen, besteht darin, die gesamte Nutzerreise zu instrumentieren – nicht nur die Antwortzeiten einzelner APIs.

// Instrumentierung der End-to-End-Nutzerreise
const journeyStart = performance.now();
await hardwareCommandAPI.send(deviceId, 'turn_on');
const responseTime = performance.now() - journeyStart;

// Loggen der gesamten Verzögerung, nicht nur der API-Antwort
console.log(`Gesamte Nutzererfahrung: ${responseTime} ms`);

Der Weg zu ganzheitlichen Lösungen

Die Beispiele zeigen: Technische Perfektion in einzelnen Komponenten garantiert keine zufriedenstellende Nutzererfahrung. Der Schlüssel liegt in der Systemperspektive – darin, Verantwortung nicht nur für die eigene Aufgabe, sondern für das Gesamtziel zu übernehmen. Dazu gehören:

• Klare Definition der Geschäftsziele – nicht nur der technischen Anforderungen.
• Instrumentierung der gesamten Nutzerreise, nicht nur der Komponentenmetriken.
• Regelmäßige Überprüfung der Nutzererfahrung in realen Szenarien, insbesondere unter Netzwerkbedingungen.
• Enge Zusammenarbeit zwischen Entwicklern, Produktmanagern und Designern, um Lücken zwischen den Systemen zu schließen.

Entwickler, die sich als System-Owner verstehen, erkennen, dass ihr Job nicht beendet ist, wenn ein Ticket geschlossen wird. Ihr Job endet erst, wenn das eigentliche Problem – die zufriedenstellende Nutzererfahrung – gelöst ist. Das ist der Unterschied zwischen einem funktionierenden System und einem, das wirklich funktioniert.