Ticketsystem

Das Leben besteht oft daraus die richtigen Dinge zur richtigen Zeit zu tun. Das vor allem wenn man Dinge in einer Gruppe mit und für andere macht. Das ist so im Arbeitsleben, in einem Verein oder auch der Familie. So gibt es zahlreiche System Aufgaben und deren Eigenschaften wie Dringlichkeit, Aufwand, Status, Zustand für sich und andere abzubilden. Sehr anschaulich ist ein Restaurant. Der Gast sitzt am Tisch und wählt ein Gericht, welches er vom Koch zubereitet und vom Kellner serviert haben will. Aus Sicht des Restaurants sitzen da viele Gäste, die alle, möglichst schnell was zum essen wollen. Darum hat eine Kellner Handzettel, auf den er aufschreibt was der Gast will, eventuell mit Sonderwünschen. Dieser wird in der Küche auf einen Stapel gelegt, ggf. sinnvoll gruppiert oder priorisiert. Und dann arbeitet der Koch diese Reihenfolge ab. Am Schluss macht am aus dem Bestellzetteln die Rechnung. Es gibt aber auch die elektronische Variante mit Registrierkasssen oder einem Orderman.

Große Projekte versucht man in kleine Aufgaben (''ToDos'') zu zerlegen und diese dann von verschiedenen Personen und Stellen zueinander passend abarbeiten zu lassen. Das kann man mit Stift, Zettel und Pinnwand machen, was den meisten Menschen recht gut liegt. Leider ist das schwierig wenn Menschen örtlich oder zeitlich unahängig arbeiten. Dann kommt man oft zu einem Kreuzfeuer aus email mit zahllosen ''cc'', ''AW. RE, FWD,'' und unendlichem TOFU. Hier helfen Issue-Tracking-Systems, auch Bugtracker oder Ticketsystem genannt.

Es ist nicht nur wichtig das man ein Ticketsystem mit den richtigen Funktionen hat, sondern das man es auch richtig bedient.

Funktionen

how-github-uses-github-to-build-github_kuchenmaschine

Welche Anforderungen man für sein Ticketsystem aufstellt hängt vom geplanten Projekt und dem Umgang der Mitarbeiter ab. Nicht alle Anforderungen sind für alle gleich wichtig, aber dennoch sollte man sich entscheiden welche man gut erfüllt haben will und welche bewusst nicht. Wichtig ist die Usability, den es hilft nichts wen man eine hoch kompliziertes nur über Schranken erreichbares Infrastruktur hat, die nur eine paar "Weise" bedienen können.

Tickets

Wie werden die Informationen, Aufforderungen, Wünschen, Nachfragen etc. in so einem System strukturiert? Persönliche ToDo-Listen, auf dem PC oder Papier, sind meist eine Liste mit je einer Zeile je Aufgabe. Ticketsysteme strukturieren Projekte in einzelne Tickets (oder Issues, Cases, Task, Aufgaben). Ein Ticket hat dann einen Betreff, eine Beschreibung und Metadaten. Dabei definiert sich ein Projekt am dadurch das es keine operative Überschneidungen mit anderen Projekten hat.

Struktur

Diese zahlreichen Tickets müssen nach unterschiedlichen, dynamischen Kriterien sortiert werden können. In einem Projekt werden dann, möglichst je Aufgabe, Tickets angelegt die dann einen bestimmten Prozess über seine Lebensweg begleiten. Dabei müssen verändern sich diese Aufgaben von der Priorisierung, Zuständigkeit und Relevanz ständig. Das müssen Tickets abbilden können.

  • der Status läst alle Beteiligten wissen in welcher Phase die Aufgabe steckt. Das könne ganz einfache Stufen wie 'offen, erledigt' oder auch komplex individuell zugeschnitten sein wie man sie oft in der Softwareentwicklung findet 'eingetroffen, gesichtet, Rückfrage, in Bearbeitung, Testing, Freigabe, erfolgreich geschlossen, nicht erfolgreich geschlossen'
  • Zuordnung zu einem Benutzer oder Gruppe.
  • die Priorität nach der Tickets bearbeite werden.
  • Bug oder feature
  • freie Label um andere projekt- oder gruppenspezifische Kriterien abbilden zu können.

Listen und Kanban-Boards

Kanban-Board, by Jeff.lasovski CC BY-SA 3.0 Ticketsyteme sind vor allem dann sinnvoll wenn ein Projekt viele Aufgaben hat. Dazu können Ticketsystem die vorhandenen Tickets zu unterschiedlichen Darstellungen auflisten: Beispielsweise Listen von Tickets die einzelnen Mitarbeitern zugeordnet sind, sortiert nach Priorität. Tickets sortiert nach Status (z.B. "offen", "in Bearbeitung", "zur Abnahme" ). Aber auch Aufgaben nach eigens definierten Kriterien auflisten (z.B Netzwerkrelevant, Wetterabhängig etc.). Einige Ticketsysteme bieten dynamische Filter die zahlreiche Kombinationen von Kriterien ermöglichen.

Ein Kanban-Board besteht aus mehreren Spalten die Listen bestimmter Ticketstatus. Kanban-Boards zeigen schnell die Priorität von kommenden Aufgaben, die aktuelle Arbeitsbelastung des Teams und erledigte Tickets auf.

Priorität

In jedem Projekt ergeben sich Aufgaben die meist ungeordnet auftreten, die Aufgabe des Projektmanagements ist es diese zu einer ständigen Gesamtstruktur zu verbinden und die Priorität festlegen

Priorität kann dabei zwei unterschiedliche Strukturierungen bedeuten

  • Aufgaben in Prioritätskategorien zuordnen (sehr wichtig, wichtig, normal, weniger wichtig)

  • oder Aufgaben nach Priorität sortieren

  • in Gruppen ist eine Zuordnung an einen oder mehrere zuständige Bearbeiter daher wichtig das jedes Mitglied weiß was gerade von ihm erwartet wird. Diese Aufgaben dann erfüllen kann oder auch intervenieren wenn die Erwartungen zu hoch gesteckt sind

  • Das Duedate ist die Angabe wann etwas gemacht werden soll, oder das date, wann es fertig sein muss. Vor allem beim duedate ist es sinnvoll auch einen Zeitbereich angeben zu können.

Auch wenn diese Kategorien nicht nativ vorhanden sind, kann man sie mit einem Taging, sofern möglich, selbst nachstellen. Dann ergeben sich auch noch weiter Kategorie-Klassen wie 'Queues', Kundenzuordnung. Die Kategorien sollten sich auch im Design widerspiegeln. So erkennt man ''Prio1'' gleich an der z.B. roten Hintergrundfarbe

Zugang

Wie kommen die Daten nun an die User und wie pflegen die User die Daten ein. Die meisten Ticketsystem sind über den browser erreichbar. Der mobile Zugriff kann auch über html oder eben eine app gehen, für offline Daten ist eine app meist besser.

Die Darstellung in html ist oft sehr ausführlich, verlangt aber vom user das er diese Aufstellung auch anschaut, daher ist es wichtig das user Änderungen per mail, rss oder sonst wie mitbekommen können.

Eine weitere schöne und gute Möglichkeit ist es nicht nur Benachrichtigungen per mail zu verschicken, sondern gleich ganze Aufgaben, so können user die sich selten einloggen , oder auch Systemfremde mit Information versorgt werde. Kann man zusätzlich noch mit einer E-Mail dirkt an das Ticketsystem schreiben und so Tickets aufmachen oder beantworten (OTRS-Ansatz), werden auch die Informationen von Externe oder system-inaffinen gleich mit organisiert.

Bearbeiten

Meist werden Tickets über ein Weboberfläche oder über E-Mails bearbeitet. Weboberflächen haben den Vorteil von vielen Nutzern genutzt werden zu können. Eine "Bearbeitung" über emails erfolgt über eine E-Mail, mit einem Betreff und Beschreibung an eine Service E-Mailadresse oder als Antwort auf eine Benachrichtigung.

Weitere sinnvolle Funktionen zur Bearbeitung sind:

  • Häufig genutzte Worflows als shortcut: 'Assign to me' ein einfache Zuordnung an den bearbeiteten Benutzer, anstatt ein Auswahl aus einer Liste 20 anderer Teammitgliedern. Ein Tickt auf 'In Bearbeitung' setzen.
  • Massenänderungen an Auswahllisten (z.B. alle Tickets einer Person die in denm Urlaub geht, an dessen Stellvertreter)
  • Oft werden Tickets doppelt angelegt, oft sammeln sich in beiden Tickets wichtige Infos oder Status. Erkennt man das Dublikat muss man bei vielen System eines von den beiden schliessen. Schön ist es wenn man beide, inklusive der Historie, vereinigen kann. OTRS macht das sehr schön mit einer 'merge'-Funktion.

Schön wäre es wenn das System logische Änderungen auch selbst machen könnte. So ist es meist praktikable nur imr Prioritäten zu arbeiten als mit 'duedates'. Wenn eine Aufgabe doch ein duedate hat, so sollten es die Möglichkeit geben automatisch, bei näher rückenden Termin, die Priorität nach oben zu schieben (eine Woche vorher: wichtig, ein Tag vorher: dringend). Bisher kenn ich aber ein System das dies macht.

Benachrichtigung

Benutzer müssen über neue Tickets oder Änderungen an bestehenden Tickets informiert werden, denn nieman kann den ganzen Tag eine Ticketliste im Aufge behalten. User müssen aber slebst konfigurieren können bei welchen Arten Änderungen und bei welchen Tickets sie informiert werden wollen. Sollen nur eigene Tickets, neue Tickets oder nur größere Änderungen eine Benachrichtigung auslösen.
Die Benachrichtigung kann über viele Kanäle passieren. Am einfahcsten ist es wenn für jede gewollte Änderung eine E-Mail verschickt wird. Aber auch spezielle Client Programme, Webnotifications, Chatsbots oder RSS feeds können den User informeiren

usability und speed

usability und speed sind neben allen Funktionen und designs viel wichtiger. Gerade Informationen aus einem Ticketsystem werden nicht mal aufgerufen wie ein Wikipediartikel und dann stundenlang vertieft darin gelesen. Kurz sich versichern ob man noch alles richtig weis, nur mal schnell den status checken, oder auch das scheinbar unwichtige Telefonat ("tel hans: er schickt morgen neuen specs" ) notieren, muss schnell gehen. Langsame Ladezeiten verhinden das man mal schnell eben klickt, schaut, schreibt , aber genau das ist wichtig.

Alternative: Gemeinsam Postfach

Oft wir der anstatt eines speziellen Systems ein gemeinsames email Postfach genutzt.Ein kommende Aufgaben werden von allen gesichtet und dann an persönliche Unterordner oder Projektordner verschoben.Das geht auch bei kleinen Teams, wenigen Aufgaben und keiner starken Strukturierung (prio, duedate, state etc).Es es bedarf aber wesentlich mehr Disziplin. Eine versehentlich verschobene Mail ist im Organisationsnirwana verschwunden, ein Ticketsystem wäre redundant, oder alarmiert. Auch lässt sich mit Ordnern nur eine Kategorie zuordnen, entweder nach Projekt, Bearbeiter, Owner etc. nicht aber mehren. Den Status (erldigt oder nicht) bildet man meistens mit dem Posteingang ab.

Ein weitere Nachteil ist das es nicht skaliert, gerade in hektischen Zeiten wird man keine Systemumstellung machen. Genau dann aber braucht man ein System was schnell, zuverlässig und mit auch mal mehr Leuten arbeitet.

Wer sich darüber Gedanken macht wie er eine gemeinsame Inbox besser verwaltet, ist eigentlich schon reif für ein richtiges Ticketsystem. Zumindest habe ich persönlich ab und zu in kleineren Teams mit einer gearbeitet und es waren immer mehr Schwierigkeiten mit verlorenen mails, Unübersichtlichkeit und Zuständigkeitsbereichen als der Aufwand für ein Ticketsystem. Wer richtige Projekte (ca über 3 Personen und 3 Wochen) macht, egal ob Software oder Bau, braucht ein Organisationssystem.

Howto

Es genügt nicht nur ein gutes Werkzeug zu haben, man muss damit auch umgehen können. Erstens müssen alle Mitglieder möglichste einfachen Zugang zum System haben. (siehe Usability) Aber auch wenn nun alle mit dem System umgehen können, es braucht eine Regel wie der Fluss von Informationen zu einem Projekt wird. Ein paar theoretische Ansätze die man nie ganz einhalten kann, aber als Denkpattern ganz gut funktionieren.

Everything starts with an issue

Erstellen

Betreff
"sommer newsletter kommt erst nach 30 Minuten" "sommer geht nicht"
Beschreibung
alle wichtigen Details, gern in Listen, aber ausformulierten Stichpunkten. Zusätzlich:

: vor allem bei Software screenshots oder links auf die entsprechende Seite oder Anwendung. : Fotos bei Gebäuden oder Maschinen
: links auf Seite in der Anwendung oder Seite : Referenz auf Dokumenmation, Versionsverwaltung, Leistungsverzeichnisse

Fehlermeldungen
bitte copy pasten, nicht screenshoten
  • Zitate kennzeichnen
  • keine Anrede & Verabschiedungsformel, ist zwar nett gemeint, lenkt aber ab

Verteilung

Die einfachste Variante ist der schwarzer Peter. Ein Ticket wird immer einer Person zugewiesen die aus Sicht des Aufnehmenden am ehesten passt. Diese Person hat dann sozusagen den schwarzen Peter und ist für das Ticket auch ungewollt verantwortlich. Diese Person kann sich aber der Verantwortung entziehen in sie das Ticket begründet ablehnt in dem sie es jemand anderem zuweist oder die Priorität senken kann.

Oft kann nur ein Teilbereich von einer bestimmten Person gelöst werden, eine Lösungsansatz definiert oder eine Entscheidung gefällt werden. Das wichtige ist ja dasnn das eine Person dann nicht weitermachen muss, sondern jetzt das Ticket wieder weiterschieben kann. Das kann solange passieren bis das Problem gelöst ist und geschlossen werden kann

Das ganze kann natürlich nur in einer kollegialen Atmosphäre funktionieren, nicht wenn jeder sich auf Bezug auf das recht weiterzuschieben vor jeder Verantwortung drückt. Aber die Methode schwarzer Peter funktioniert dann wenn Zuständigkeiten und zeitliche Kapazitäten nicht ständig klar sind. Dadurch das jeder das Ticket nur einer Person weiterschiebt die fachlich oder zeitlich besser in der Lage ist kommt es bei der Person an die zeitlich und fachlich die Aufgabe am besten lösen kann. Solche verschiebe Runden sollten aber möglichst kurz sein. Und es muss auch selbstständig erkannt werden wenn ein Ticket durch ständige Verschiebung oder meist durch Zuordnung zu einer fachlich oder zeitlich ungeeigneten Person nicht entsprechend seiner Priorität zugeordnet wird.

Für größere Teams kann man einen Dispatcher einsetzen. Da ist meist die Rolle des Team oder Projektleiters. Nur er darf Tickets Personen zuweisen und steuert damit die Aufgabenverteilung. Jetzt kann es einen Pool an nicht zugeordneten Tickets geben aus dem der Dispatcher gleichmässig welche an sein Team verteilt.

PingPong ist ein Modus in dem komplexerer Tickets eintreten wenn zwei Personen gegenseitig aber nacheinander an einem Projekt arbeiten. Und sich je anch Status das Ticket gegenseitig hin und her spielen, um dem anderen den aktuellen Stand zu übermitteln. Die Methode ist nicht wirklich effektiv, kann aber besser sein als E-Mail PingPong.

Priorisierung

''Egal, das ist alles gleich wichtig, es muss alles bis heute Abend erledigt werden'' sind markige Sprüche von Projektleitern, Chefs etc aber eigentlich ist es das Eingeständniss vor dem Projekt kapituliert zu haben.

Menschen priorisiern und werden Dinge nacheinander tun. Man hat die Chance das gemeinsam als Gruppe zu tun und dabei vielleicht manche erzwungene persönliche Prioritätsentscheidung (das Projekt ist AAA+) nicht zu fordern sondern ein Team zu haben.

Schliessen

ist ein Ticket erledigt wird es geschlossen oder archiviert, so ist es in den aktuellen Ansichten nicht mehr sichtbar, aber immer noch zur Nachvollziehbarkeit und Dokumentation lesbar. Natürlich kann die Person welche das Ticket final bearbeitet dieses auch schließen.

Um aber Missverständisse zu vermeiden kann man festlegen das nur die Person die ein Ticket eröffnet hat dieses auch wieder schließt um einerseits sicher zu gehen richtig verstanden worden zu sein, aber auch um zu wissen das eine Aufgabe erledigt ist und jetzt auch nicht mehr verändert oder weiterbearbeitet wird.

Oder falls dies nicht möglich ist, oder die Person das nicht will/kann, kann ein Ticket auch von einer anderen Person geschlossen werden um so mindest eine weitere Person kurz das Ergebniss prüfen lassen, und so das 4 Augen Prinzip einzuhalten. Es kann sogar sinnvoll sein eine unbeteiligte Person das Ticket schliessen zu lassen um dessen Un-Voreingenommenheit und Betriebssehfähigkeit (also ich meine !=Betriebsblindheit) zu nutzen.

Eine Definition of Done wann ein Ticket fertig ist vermeidet Missverständisse:

  • Hinweis wo sich das fertige Ergebniss findet (z.B. link auf Live- oder Testserver)
  • evtl Code Review
  • Dokumentation im
  • wiki
  • Code
  • manuelles testprotokoll (oder)
  • Test (der sollte bei TDD als erstes gemacht werden)