10 Gründe, warum ein Ti­cket­sys­tem besser ist als E-Mails

Zur Grundidee und Struktur von Ticketsystemen gibt der Blogbeitrag Arbeiten mit einem Ticketsystem eine Übersicht. Wenn das Thema neu ist, dann ist dort ein guter Einstiegspunkt.

Das Schreiben einer E-Mail erscheint oft viel einfacher und schneller als ein Ticket anzulegen. Im ersten Moment mag das stimmen, aber spätestens bei der ersten Rückfrage wird es unübersichtlich, zäh und schnell chaotisch. Hier daher meine ultimativen 10 Gründe, warum ein Ticketsystem in der Projektarbeit die E-Mail aussticht:

• Zentralisierung und Zusammenarbeit
• Transparenz (Übersicht für alle)
• Zielgerichtete Suchfunktion
• Kund*innen(ein)bindung
• Standardisierung und Strukturierung
• Workflows und Qualitätssicherung
• Priorisierung
• Automatisierung
• Reporting
• Dokumentation
• Inbox-Zero

Zen­tra­li­sie­rung und Zu­sam­men­ar­beit

An der Realisierung von Projekten sind mehrere Personen beteiligt. Bei unseren Projekten ist es immer mindestens das verantwortliche Team sowie die projektverantwortlichen Stakeholder auf Kundschaftsseite. Teilweise sind auch weitere Dienstleister involviert.

Durch unser Ticketsystem haben alle Projektbeteiligten Zugriff auf alle aktiven und vergangenen Tasks. Nichts verschwindet in E-Mail-Postfächern auf Nimmerwiedersehen. Wenn z.B. Kolleg*innen krank werden oder für vier (4!) Wochen in den Urlaub verschwinden, ist das Ticketsystem als zentrale Informationsquelle entscheidend. Wäre in einem solchen Fall z.B. die Abstimmung zu einem Feature im bidirektionalen E-Mail-Austausch erfolgt, hätten Kolleg*innen, die als Vertretung einspringen, keinen Zugang zu abgestimmten Informationen. Es käme somit mindestens zu einem zeitweisen Informationsverlust und zu Verzögerungen. Tritt eine Person komplett aus dem Projekt oder der Firma aus, sind die Informationen aus E-Mail-Konversationen komplett verloren. ¯\_(ツ)_/¯

Transparenz

Ein Ticket zeigt im Ticketsystem den Status der damit verbundenen Aufgabe und somit den Fortschritt an. Es zeigt auch an, wer wann welche Änderungen oder Anfragen getätigt hat. Wenn mehrere Personen an demselben Problem arbeiten, wird es schnell schwierig, den Überblick über einzelne Tasks zu behalten. Versuchte man dies über E-Mails zu realisieren, müsste sichergestellt werden, dass immer die richtige Person eine Kopie der Nachricht erhält. Das ufert in reinen E-Mail-Schlachtfeldern aus, die keiner in seinem Postfach vorfinden möchte. ¯\_(ツ)_/¯

Ziel­ge­rich­te­te Such­funk­ti­on

Während sich in E-Mail-Clients i.d.R. nur nach Volltext und ggf. einschränkenden Kriterien wie Absender und Datum suchen lässt, bieten aktuelle Ticketsysteme Suchfunktionen, durch die zielgerichtet nach spezifischen Eigenschaften des Tickets gesucht werden kann. So lässt sich die Suche z.B. auf ein Projekt, einen Tickettyp, einen Autor oder eine Kombination solcher Eigenschaften eingrenzen.

Im E-Mail-Programm wird das leider nichts. ¯\_(ツ)_/¯

Kund*in­nen(ein)bin­dung

Nicht nur das Projektteam, auch der*die Kund*in sollte auf sein*ihr Projekt im Ticketsystem zugreifen können. Wir verschaffen unseren Kund*innen so immer einen transparenten Einblick in den Projektstatus und binden sie aktiv in die Projektentwicklung ein.

Darüber hinaus ermöglichen wir es unsere*n Kund*innen so, selbst Bugs, Feauture-Requests und andere Tasks im Ticketsystem einzustellen. Dies beschleunigt den Arbeitsprozess und macht Zuständigkeiten transparent (wer übernimmt welche Aufgabe?).

Dieses Maß an Einbindung erreicht man nicht per E-Mail. ¯\_(ツ)_/¯

Stan­dar­di­sie­rung und Struk­tu­rie­rung

Für die Bearbeitung von Tasks ist es essenziell, dass grundlegende Standardinformationen vorliegend sind. Mit einem gut konfigurierten Ticketsystem können in bestimmtem Kontext benötigte Informationen als Pflichtangaben abgefragt werden. Mit einem Bug-Ticket könnte z.B. die Pflichtangabe über das verwendete System verbunden sein, in dem der Fehler aufgetreten ist. Bei der Einreichung eines Bugs per E-Mail fehlen diese Informationen oft, sodass sich die Lösung des Problems durch Nachfrageschleifen unnötig verzögert. ¯\_(ツ)_/¯

Workflows und Qua­li­täts­si­che­rung

Durch individuelle Ticket-Workflows wird definiert, wie die Übergänge eines Tickets von einem zum anderen Status erfolgen. So kann garantiert werden, dass definierte Prozesse z.B. zur Qualitätssicherung eingehalten werden. Bei uns können Tickets z.B. nicht einfach von „Ready“ (vorbereitet für die Umsetzung) auf „Done“ (fertig umgesetzt) wechseln. Es gibt immer einen Qualitätssicherungs-Step. So wird sichergestellt, dass das Vieraugen-Prinzip eingehalten wird und dass kein fehlerhafter Code ausgespielt wird.

E-Mail-Software kann das nicht. ¯\_(ツ)_/¯

Prio­ri­sie­rung

Im Ticketsystem kann die Priorität für einzelne Tasks entsprechend der Wichtigkeit gesetzt und vor allem auch verändert werden. Somit wird das Team schnell auf dringliche Tasks aufmerksam. Im Zusammenspiel mit intelligent definierten Workflows kann die Arbeit nochmals optimiert werden.

Ein Beispiel: Tickets, die bei uns nicht erfolgreich durch die Qualitätssicherung kommen, wechseln automatisch in die Prio-Stufe. So stellen wir sicher, dass keine neuen Aufgaben begonnen werden, solange Begonnene nicht erfolgreich abgeschlossen sind.

Natürlich lassen sich auch E-Mails mit „Priorität hoch“ verschicken, dies ist aber deutlich statischer und hilft somit nur bedingt. ¯\_(ツ)_/¯

Au­to­ma­ti­sie­rung

Da es sich bei Tickets um ordentlich strukturierte Datensätze handelt, lassen sich hiermit andere Systeme gut verknüpfen.

Konkret zu nennen wäre hier unsere Versionsverwaltung (Wie wir Software entwickeln, Teil 1: Versionsverwaltung), die aus den Ticket-IDs Issue-Branches erstellt und wiederum entscheidende Änderungen (z.B. Deploy auf LIVE) an das Ticket meldet, wo dies als Änderung dokumentiert wird.

Darüber hinaus lassen sich die Ergebnisse von Unit- oder Acceptance-Tests automatisiert in Tickets übertragen.

Eine weitere Optimierungsmöglichkeit ist das automatisierte Erstellen von Tickets zu wiederkehrenden Aufgaben. So werden bei uns Wartungs- und Maintenance-Tasks automatisch wöchentlich, monatlich oder quartalsweise erstellt – je nach vertraglich vereinbarten Maintenance-Bedingungen.

Einige Ticketsysteme bieten auch die Möglichkeit, beim Erstellen von Tasks Zusatzinformationen automatisiert aufzunehmen. Insbesondere für die Frontend-Entwicklung ist hier das Tool Bugherd zu nennen, das mit Erstellung des Tickets aus der Websiteoberfläche heraus auch Browserinformationen und Systemdaten automatisch in das Ticket übernimmt.

Und last but not least ist unser Ticketsystem mit unserer Buchhaltung verbunden, sodass Abrechnungsprozesse automatisch mit Abschluss bestimmter Tickettypen und Zeitbuchungen ausgelöst werden können.

Wie soll das mit einem E-Mail-Client funktionieren? ¯\_(ツ)_/¯

Reporting

Wir erfassen in unserem Ticket z.B. auch Arbeitszeiten, Arbeitsbereiche, Story Points und Laufzeiten. Diese Größen lassen sich recht einfach und komfortabel auf Projektebene, auf Team-Ebene oder auch F7-weit auswerten.

Die Fragestellung „Wie viele Story Points hat mein Team im letzten Quartal im Projekt XY durchschnittlich pro Sprint umsetzen können?“ lässt sich so leicht beantworten. Somit sind auch Projektionen für zukünftige Sprints zuverlässig möglich.

E-Mail... nun ja, lassen wir das ¯\_(ツ)_/¯

Do­ku­men­ta­ti­on

Frage 1000 Entwickler, wie gerne sie Dokumentation schreiben; keiner wird in Begeisterung ausbrechen. Ein gut gepflegtes Ticketsystem (in Kombination mit Coding-Standards und einigen Inline-Kommentaren im Quellcode) kann diese Aufgabe jedoch bereits zuverlässig erfüllen, da hier umfangreiche Informationen systematisch und gut durchsuchbar (s.o.) abgelegt sind. So lässt sich auch nach Jahren noch klären: „Is it a bug, or a feature?“. Die o.g. Verknüpfung unserer Versionsverwaltung mit dem Ticketsystem unterstützt uns hier zusätzlich, da direkt nachvollziehbar ist, welcher Code-Change mit welchem Ticket verbunden ist.

Dies ist vor allem bei langfristigen Projekten, bei denen auch Ansprechpartner wechseln, ein enormer Vorteil gegenüber jeglicher E-Mail-Kommunikation. ¯\_(ツ)_/¯

In­box-Ze­ro...

.. ein hehres Ziel, das wohl nie erreicht wird, solange es noch E-Mails gibt – das ist aber auch gar nicht so entscheidend. Viel entscheidender hingegen ist, dass die „Pings“ in der Inbox auf das Wesentliche reduziert werden und somit besser und fokussiert gearbeitet werden kann.

Denn gerade die Bemühung, einige der oben aufgeführten Vorteile eines Ticketsystems per E-Mail zu umzusetzen, resultiert in einer zeitraubenden E-Mail-Flut. Insbesondere der Versuch, Transparenz durch Einbindung aller potenziell (!) zu informierenden Stakeholder über lange CC- und E-Mail-Verteilerlisten zu schaffen, schafft das Gegenteil: Intransparenz und Ressourcenverschwendung. Es entsteht ein E-Mail-Ping-Pong der Extraklasse, bei dem im schlimmsten Fall mehrere Themen unter einem Betreff mit mehreren Beteiligten in chronologisch unsauberer Reihenfolge „abgestimmt“ werden. Kein Mensch durchblickt das, kein Mensch will das. ¯\_(ツ)_/¯

Fazit

Wer aufmerksam mitgezählt hat, kommt auf 11 gute Gründe; dabei hatte ich nur 10 versprochen. Was soll ich also noch mehr sagen? ¯\_(ツ)_/¯