Schlechte Tickets – ein Problem für alle

Einleitung

#

Die folgenden drei Tickets kommen mir in ähnlicher Form fast täglich unter. Was auf den ersten Blick wie ein Problem des zuständigen Entwicklers wirkt, hat weitreichendere Folgen. Folgen für den Nutzer, der das Ticket erstellt hat und für das Projekt bzw. die Firma als Ganzes. Am Ende zeige ich dir noch, wie ein gutes Ticket aussieht und gebe dir ein Template mit auf den Weg, das du verwenden kannst.

Ticket 1

#

Ticket 2

#

Ticket 3

#

Was ist an diesen Tickets schlecht

#

Gehen wir die drei Tickets systematisch durch und schauen uns an, was nicht so gut ist.

Die ersten beiden sind emotionale Ausbrüche ohne Substanz – nachvollziehbar im Moment der Frustration, aber als Arbeitsgrundlage unbrauchbar.

Das dritte Ticket täuscht durch seine Länge über die fehlenden Inhalte hinweg: Zwischen Smalltalk und Höflichkeitsfloskeln verstecken sich keine verwertbaren Informationen. Keine Schritte zur Reproduktion, keine Fehlermeldungen, keine Systemangaben, also nichts, womit ein Entwickler arbeiten könnte.

Was haben diese drei Tickets gemeinsam? Sie zwingen den Bearbeiter zum Rätselraten.

Das Fehlen konkreter Details zieht sich durch alle drei Beispiele:
Was genau funktioniert nicht?
Unter welchen Bedingungen tritt das Problem auf?
Welche Fehlermeldung erscheint?

Diese Fragen bleiben unbeantwortet.

Und genau hier beginnen die Folgen, die weit über die Frustration des zuständigen Entwicklers hinausgehen.

Folgen für den Entwickler

#

Wollen wir uns zunächst den negativen Folgen für den Entwickler widmen, der ein solches Ticket bearbeitet.

Zeitverschwendung durch Detektivarbeit

#

Statt sich direkt der Lösung des Problems zu widmen, muss der Entwickler erst einmal herausfinden, was überhaupt das Problem ist. Das bedeutet: Rückfragen stellen, auf Antworten warten, den Kontext wechseln zwischen verschiedenen Aufgaben, und im schlimmsten Fall selbst auf die Suche nach dem Fehler gehen ohne zu wissen, wonach genau gesucht werden soll. Was in 30 Minuten erledigt sein könnte, zieht sich über Tage hin – nicht wegen der Komplexität des Problems, sondern wegen fehlender Informationen.

Frustration und sinkende Motivation

#

Wer täglich mit unvollständigen oder emotionalen Tickets konfrontiert wird, verliert die Freude an der Arbeit. Die ständige Notwendigkeit, grundlegende Informationen mühsam zusammenzutragen, frustriert. Besonders demotivierend wirkt es, wenn man spürt, dass sich der Ticketersteller keine fünf Minuten Zeit genommen hat, während der Entwickler nun Stunden investieren muss. Diese Frustration summiert sich und kann langfristig zu Resignation führen – man arbeitet dann nur noch das Nötigste ab, statt mit Engagement an Lösungen zu arbeiten.

Qualitätsverlust bei der Problemlösung

#

Ohne vollständige Informationen steigt das Risiko von Fehleinschätzungen. Der Entwickler muss raten, welcher Fall gemeint ist, arbeitet möglicherweise am falschen Problem oder übersieht wichtige Randbedingungen.

Das Ergebnis kann vieles sein, sehr oft ist es aber für die Entwickler unbefriedigend. So bekämpfen Fixes oft nur Symptome statt Ursachen, neue Bugs entstehen durch unvollständiges Verständnis der Situation oder Lösungen gehen am eigentlichen Problem vorbei.

Die Qualität der Arbeit leidet nicht aus Unfähigkeit, sondern aus mangelnder Informationsgrundlage, welche wiederum aus ungenauer Kommunikation resultiert.

Folgen für den Nutzer

#

Auch der Nutzer selbst leidet unter schlechten Tickets und das oft mehr als ihm selbst bewusst ist.

Zeitverschwendung durch unnötige Rückfragen

#

Ein unvollständiges Ticket löst fast immer eine Rückfragekette aus.

Der Entwickler fragt nach, der Nutzer antwortet, stellt fest, dass er eine wichtige Information vergessen hat, antwortet erneut und das Ganze kann sich über Tage hinziehen. Die Ironie dabei ist, dass der Nutzer, die Zeit, die er beim Schreiben des Tickets gespart hat, mehrfach durch asynchrone Kommunikation zurück zahlt.

Ein sorgfältig formuliertes Ticket wäre in Summe deutlich schneller gewesen.

Frustration durch Missverständnisse

#

Wenn Kontext fehlt, muss der Entwickler Annahmen treffen und diese Annahmen sind nicht immer richtig. Das Ergebnis ist oft eine Lösung, die am eigentlichen Problem vorbeigeht, ein Nutzer, der nochmals ein Ticket erstellen muss und auf beiden Seiten das Gefühl, nicht verstanden zu werden.

Missverständnisse durch unklare Kommunikation sind vermeidbar und trotzdem einer der häufigsten Gründe für Unzufriedenheit auf beiden Seiten.

Schlechteres Produkt

#

Wer ein Problem nicht klar beschreibt, riskiert, dass es nicht korrekt behoben wird. Reproduzierbare Schritte, Fehlermeldungen und Systemangaben sind keine bürokratischen Hürden, sondern die Grundlage dafür, dass ein Fix tatsächlich das Problem trifft und nicht nur ein Symptom beseitigt.

Letztlich bekommt der Nutzer ein Produkt, das schlechter ist, als es sein müsste und das nur weil Informationen fehlten und nicht weil niemand helfen wollte.

Folgen für das Projekt oder die Firma

#

Auf individueller Ebene sind es Kommunikationsprobleme, die zu Frustration führen können. Auf Projekt- oder Firmenebene hat das wirtschaftliche Folgen.

Hohe Kosten durch Zeitverschwendung

#

Entwicklerzeit ist teuer. Jede Stunde, die ein Entwickler damit verbringt, fehlende Informationen zu rekonstruieren, Rückfragen zu stellen oder am falschen Problem zu arbeiten, ist eine Stunde, die nicht in produktive Arbeit fließt. Denn er ist nicht nur länger als nötig mit diesem Ticket beschäftigt, sondern andere Aufgaben bleiben ebenfalls liegen.

Multipliziert man diesen Effekt über ein Team und mehrere Monate, entstehen erhebliche versteckte Kosten, die in keiner Aufwandsschätzung auftauchen, weil sie als unvermeidlicher Overhead abgebucht werden, obwohl sie vermeidbar wären.

Verlust von Entwicklern

#

Gute Entwickler haben Optionen und wer dauerhaft in einem Umfeld arbeitet, in dem schlechte Kommunikation die Norm ist und Frustration der tägliche Begleiter, sucht sich früher oder später etwas Besseres. Der Verlust erfahrener Entwickler ist für Projekte und Firmen eine der teuersten Konsequenzen schlechter Prozesse, auch wenn der Zusammenhang zwischen der Qualität von Tickets und der Fluktuation im Team selten direkt gezogen wird.

Es ist oft nicht der einzige Grund für einen Firmenwechsel, kann das Fass aber zum Überlaufen bringen.

So sieht ein gutes Ticket aus

#

Zum Abschluss, als Gegenstück zu den drei Beispielen vom Anfang, zunächst ein Template als Ausgangspunkt, gefolgt von einem konkreten Beispiel, das zeigt, wie es in der Praxis aussehen kann.

Template

#

**Titel:** Kurze, präzise Zusammenfassung des Problems

**Umgebung:**

- Betriebssystem / Browser / Version:
- Betroffene Version der Anwendung:

**Schritte zur Reproduktion:**

1. ...
2. ...
3. ...

**Erwartetes Verhalten:**
Was sollte passieren?

**Tatsächliches Verhalten:**
Was passiert stattdessen?

**Fehlermeldung / Screenshots:**
(Falls vorhanden)

**Zusätzlicher Kontext:**
Tritt das Problem immer auf oder nur unter bestimmten Bedingungen?

Ausgefülltes Beispiel

#

Fazit

#

Gute Tickets sind keine Frage von Talent oder technischem Wissen, sie sind eine Frage von Respekt und Verantwortung.

Respekt gegenüber der Zeit des Entwicklers, der das Problem lösen soll, und Respekt gegenüber dem Team, das an einem gemeinsamen Produkt arbeitet.
Und letztlich auch Verantwortung gegenüber sich selbst und der Firma, für die man arbeitet.

Das Template aus diesem Artikel ist ein Anfang und muss nicht blind befolgt werden. Es soll vielmehr als Einstieg dienen und eine Idee vermitteln, worauf es Entwicklern ankommt und was ihnen hilft ihre Aufgabe schnell und zufriedenstellend zu erledigen.

Ein gutes Ticket kostet fünf Minuten, ein schlechtes Ticket hingegen kostet alle Beteiligten ein Vielfaches davon.

Vorschaubild

#

Erstellt mit Flux-2