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 udn 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

7609785_0fdfba177aaa277474ab2e9042aef79c aus

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.

Aufteilung und Kategorie

Projekte in Aufgaben zu strukturieren ist die Kernanforderung. Wie werden die Informationen, Aufforderungen, WĂŒnschen, Nachfragen etc in so einem System strukturiert? Persönliche ToDo-Listen, au PC oder Papier, sind meist eine Liste mit je einer Zeile je Aufgabe. Ticketsystem versuchen ganze Projekte in einzelne Teilaufgaben zu zerteilen. Dabei definiert sich ein Projekt am dadurch das es vermutlich keine operative Überschneidungen mit anderen hat. 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.

In jedem Projekt ergeben sich Aufgaben die meist ungeordnet auftreten, die Aufgabe des Projektmanagements ist es diese zu einer stÀndigen Gesamtstruktur zu verbinden.

  • PrioritĂ€t sorgen dafĂŒr zur richtigen Zeit die richtige Aufgabe erledigt wird.
  • 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
  • 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'
  • 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 errrichbar. 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 bearbeite oder ĂŒber mails. Eine mail an eine Service emailadresse mit Betreff und Beschreibung oder als Antwort auf eine Benachrichtigung.

  • MassenĂ€nderungen an Listen, (z.B. Alle Tickets die nĂ€chste Woche due-date werden eine Prio hoch): kann Jira

Das System sollte logische Änderungen auch selbst machen können. 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öglichkleit geben automatisch bei nĂ€her rĂŒckenden Termin die Prio nach oben zu schieben (eine Woche vorher wichtig, ein Tag vorher dringend).

Ticketverwaltung

Oft werden Dublikate angelegt, oft sammeln sich in beiden Tickets wichtige Infos oder Stati. Erkennt man das Dublikat muss man bei vilen System eines von den beiden schliessen. Schön ist es wenn man beide inklusive der Historie vereinigen kann. OTRS macht das serh schln mit der Funktion 'merge'.

usability und speed

usability und speed sind naben allen Funktionen und design wichtiger. Gerade Informationen aus einem Tickstsyytsem werden nicht mal aufgerufen wie ein Wikipediartikel und dann stundenlang vertieft darin gelesen. Kurz sich versichen ob man noch alles richtig weis, nur mal schnell den statsu checken, doer 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.

Benachrichtigung

Neue Tickets oder Änderungen, vor allem die auf der eigenen ToDolist. Das kann ĂŒber viele KanĂ€le passieren, am probetesten sind aner mail oder rss

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
* screenshot vor allem bei styling fehlern * wenn vorhanden link auf * Seite in der Anwendung oder Seite * wenn bekannt link auf versionsverwaltung
Fehlermeldung
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.

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)

Erfahrung

klml kennt

  • mantis recht rudimentĂ€r, aber alle Grundfunktionen da
  • redmine kann sehr viele mit mails (in out) aber halt RoR
    • demo
    • plan.io bietet anscheinend gehostetes redmine an
  • flyspray wird afaik nicht mehr maintained
  • OTRS eigentlich ein Kondenkommunikatonssystem (mails und Anrufe), man kann zwar keine Version oder Releases planen, aber
  • fogbugz langsam, unflexibel, featureitis, aber man kann nicht mal html in die description posten, es gibt keine Vorschau. Außerdem kein OS und 25$ p/m
  • [https://github.com github.com] ist nicht nur ein sehr gutes webrepo, sondern hat auch ein "issue-tracking" mit milestones (auf tags gemappt), Bearbeiterzuordnung und frei tags. Mit den tags kann man prinzipiell auch stati darstellen, aber nur bedingt prios verwalten, da man immer nur ein prio ansehen kann, aber gerade prios auf/ab-steigend braucht.
  • Jira eigentlich state of the art vor allem auch fĂŒr agile AnsĂ€tze oder Kanban, hat sicherliche noch Potential, aber gut nutzbar.

Hörensagen

  • basecamp ist eher eine gemeinsame Todolisten. Zwar kann man Bearbeiter (keine Gruppen) und duedates vergebe, aber die Todos haben nur eine Zeile Beschreibung. Mehr Text kann man nur in der 'Diskussion' abgeben, die aber kein Zusammenhang zum todo hat. Prios gibt es leider gar nicht. Außerdem kein OS und min 20$ p/m,
  • wedoist.com wirkt noch aufgerĂ€umter als basecamp, und hat ein recht gutes Taggingsystem das auf todos und Diskussion geht microblog (vulgo twitter). Der Diskussionsbereich ist eher microblog-artig (vulgo twitter). ZusĂ€tzlich gibt es einen chat, was manchmal hilfreich sein kann. Allerdings ist es auch nur eine gemeinsame Todoliste, kein Projektmanagementool.
  • trac ist zwar auch nett, aber auch soviel Struktur zum pressen
  • launchpad
  • trac
  • mingle kommt ĂŒber den Scrum-Taskboard Ansatz, recht clickibunti fĂŒr noobs, aber vmtl eher nur innerhal des teams zu gebrauchen, kann afaik keine mails
  • project management platform for agile developers wird als umija goes canban pilotiert

Aber auch persönliche ToDolisten sind eigentlich nicht gruppenfĂ€hige Projektverwatlungssysteme, aber meist dafĂŒr sehr einfach bedienbar

  • rememberthemilk.com nutzt klml
  • todoist wirkt halt ser appleesk aufgerĂ€umt
  • ein schöner Ansatz ist auch todotxt.com, kann man mit desktop, web, texteditor und konsole!!!11elf bedienen ;)
  • oder in vielen tools (Outlock, Handy, Google etc) einfach dabei
  • text oder worddatei auf dem Desktop
  • Zettel

Beobachtung

Hannes K.: wenn der ander da komplette e-mails reinpackt

davon kann man auch ableiten das der user halt diese "Funktion" will