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.

Dabei kann ein ticketsystem helfen, kann! Prim√§r m√ľssen menschen wissen wie das gehen soll

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)