Vielfach unterschätzt ist die Auswirkung, die gut geschriebene Anforderungen und Fehlermeldungen auf den Projekterfolg und Stimmung in einem Projekt haben können.
In der Zusammenarbeit zwischen Kunden und Softwareentwicklern müssen immer wieder Anforderungen oder Fehler vom Sender zum Empfänger transportiert werden. Was einfach klingt, ist es oftmals nicht.
Denn vielfach sind für den Entwickler Kontext unklar und die übermittelten Informationen unvollständig. Entwickler stehen dann vor der Herausforderung nachzuvollziehen zu müssen, was der Kunde gesehen hat, als er das Ticket geschrieben oder den Fehler gemeldet hat.
Manchmal ist es trivial und der Fehler schnell ausgemacht. Häufig aber vergeht sehr viel Zeit, bis der Klickweg nachvollzogen oder die genaue Konstellation nachgestellt wurde, die zum Fehler geführt hat.
Daher fragen Entwickler häufig schon nach, bevor sie überhaupt auf die Suche gehen. Dabei geht es dann nicht um Engstirnigkeit oder Erbsenzählerei. Denn wenn ein Ticket oder eine Anforderungsbeschreibung eine gute Reife hat, reduziert sich der Aufwand durch das Weniger an Abstimmung enorm.
Im Gegenzug kann der notwendige Abstimmungsaufwand (und die zunehmende Verstimmung) quasi gegen Unendlichkeit laufen, wenn bestimmte Dinge nicht beachtet werden.
Ein Klassiker dafür sind Sätze wie „ich hab das mal grob skizziert, sagt einfach Bescheid, wenn Euch noch was fehlt“. Hier weiß man als Empfänger häufig gar nicht, wo man anfangen soll.
Für Kunden ist häufig nicht klar ersichtlich, welche Informationen der Entwickler überhaupt benötigt. Sie stecken oftmals nicht so tief in der Thematik und es gehört einfach nicht zu ihrem Tagesgeschäft, Fehler zu melden oder Anforderungen zu beschreiben.
Daher möchten wir hier ein paar gute Praktiken zur Erstellung von Fehlermeldungen vorstellen, die sich in der Praxis bewährt haben und in der Zusammenarbeit sehr helfen können. So genannte Bug Reports müssen nicht technisch formuliert sein, sie sollen aber alle notwendigen Informationen enthalten, um den Fehler nachstellen zu können.
Wenn du als Sender folgendes beachtest, ist dir der ewige Dank der Empfänger sicher:
Wähle einen aussagekräftigen und prägnanten Titel
Der Titel sollte kurz und knackig sein. Aus ihm sollte idealerweise der Kern des Problems bereits hervorgehen. Drücke dich trivial aus.
Ein gutes Beisipiel ist hier der Betreff von E-Mails. Wenn er gut formuliert wurde, weiß der Empfänger bereits vor dem Lesen worum es in der Mail geht und findet sie auch nach langer Zeit leicht wieder.
Schreibe explizit, nicht implizit
Wenn du eine Aufgabe beschreibst, weißt du in der Regel bereits viel darüber. Darüber wird oft vergessen, dass dein Gegenüber den Kontext noch nicht kennt.
Gehe davon aus das derjenige, der das Ticket bearbeiten wird, bei Null anfängt.
So viel wie nötig, so wenig wie möglich
Es kann eine Herausforderung sein zu bewerten, ob Informationen notwendig, sinnvoll oder vielleicht überflüssig sind. Im schlimmsten Fall können überflüssige Informationen sogar verwirrend sein.
Hier ist Empathie hilfreich, versetze dich in die Lage deines Gegenübers. Was ist hilfreich, um den Fehler zu verstehen? Was trägt wahrscheinlich nicht direkt zur Problemlösung bei?
Wertschätze den Leser
Eine schnell und flüchtig übermittelte Information führt häufig widererwartend nicht dazu, dass das Problem vom Schreibtisch ist und delegiert wurde. Denn früher oder später müssen die fehlenden Informationen zusammengetragen werden, das führt zu Rückfragen oder Anrufen.
Nimm Dir Zeit, Deinem Leser genau zu beschreiben, was Du von ihm erwartest.
Fasse die Informationen vollständig zusammen
Ein gutes Ticket kann man idealerweise bearbeiten und erledigen, ohne eine Rückfrage für das bessere Verständnis stellen zu müssen.
Daher sollten folgende Informationen enthalten:
- Kurze aber klare Beschreibung
- (Klick-)Weg zum reproduzieren des Fehlers
- URL / Verlinkung der Seite
- Bilder und Screenshots, aus denen der Fehler hervorgeht
Dabei gilt natürlich wieder, “So viel wie nötig, so wenig wie möglich”. Ist also ein Screeshot nicht wirklich hilfreich, sollte er selbstverständlich weggelassen werden.
Die Erfahrung zeigt, dass schon 10 Minuten mehr investierte Zeit in eine gute und vollständige Beschreibung die Gesamtbearbeitungsdauer einer Aufgabe um ein vielfaches reduzieren kann. Das Gefühl danach, das Problem wirklich übergeben zu haben und vergessen zu können, ist wirklich schön!
Gehe davon aus, dass sich der Bearbeiter ändern wird
Eine der großen Stärken von Ticketsystemen ist, dass man mit ihnen Aufgaben atomisieren und so auf unterschiedliche Personen zu verteilen kann. Durch Verteilen der Unteraufgaben wiederum ist eine parallele, und dadurch schnellere Bearbeitung möglich.
Schreibe daher nicht einer bestimmten Person, sondern bleibe allgemein. Denn das Ticket kann durchaus auf Wanderschaft gehen. Ist zum Beispiel ein Mitarbeiter krank, kann das Ticket jemandem zugewiesen oder von jemandem übernommen werden, der vielleicht gerade erst zum Team dazugekommen ist und die Vorgeschichte noch nicht kennt.
Daher ist es wie oben bereits erwähnt wichtig explizit zu schreiben und davon auszugehen, dass der Leser bisher nichts von seinem Glück wusste.
Die Kommentare erzählen die Geschichte eines Tickets
Wie bereits erwähnt ist es durchaus üblich, dass ein Ticket den Bearbeiter wechselt. Daher ist der Verlauf der Kommentare und die darin enthaltenen Informationen sehr wichtig. Denn hier vollzieht der Bearbeiter den Sachverhalt, die Ergänzungen und die bereits erfolgten Tätigkeiten seiner Kollegen nach.
Dies im Hinterkopf haltend, nutze die Kommentarfunktion weise. Bleibe sachlich, freundlich und informativ. Sofern es neue, für die Bearbeitung relevante Informationen zur Aufgabe gibt, ist das Kommentarfeld der richtige Ort für die Ergänzung.
Auf eine weiterhin gute Zusammenarbeit!
