Ticketsystem

Hinter dem "großartigen" Namen Issue-Tracking-System verbirgt sich ein recht gute und hilfreiche Software. Meist der Versuch große Projekte in kleine Aufgaben (vulgo ''ToDos'') zu zerlegen und diese dann von verschiedenen Personen und Stellen zueinander passend abarbeiten zu lassen. Meist mit Stift und Zettel, was den meisten Menschen recht gut liegt, aber recht Gruppenunkompatibel ist oder mit einem Kreuzfeuer aus email mit zahllosen ''cc'', ''AW. RE, FWD,'' und unendlichem TOFU.

Neben zahlreichen Projektmanagementtools, haben vor allem im Softwarebereich Bugtracker und Emailticketsystem Einzug gehalten. 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.

7609785_0fdfba177aaa277474ab2e9042aef79c aus

Funktionen

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.

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

Access

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 ĂŒber ein Webend oder ĂŒber mails als Antwort auf die 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).

Ticketverwatlung

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

Natural

Ticketsystem kann man aber auch in freie Wildbahn beobachten

  • Handzettel in Restaurants schreiben auf was der Gast will, queuen die KĂŒche und am Schluss erzeugen sie die Rechung. Es gibt aber auch die elektronische Variante davon (p:Orderman)
  • AtemschutzĂŒberwachung ĂŒberwacht die Laufzeiten von Feuerwehrleuten und setzt ĂŒberfĂ€llige Trupps auf Prio 1 zum retten

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

Aber 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.

Erstellen

  • Betreff: "newsletter doi kommt erst anch 30 Minuten" "doi 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.

Priotiserung

''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 Scrum#Definition_of_Done wann ein Ticket fertig ist vermeidet MissverstÀndisse:

  • Hinweis wo sich das fertige Ergebniss findet (z.B. link auf intergration)
  • Clean Code
  • evtl Code Review
  • Doku im
    • Code
    • wiki
    • manuellen testprotokoll (oder)
  • fertiger 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

Groupware sind meist nur Adressverwalter und Kalender.

Beobachtung

"Hannes K.: wenn der ander da komplette e-mails reinpackt", davon kann man auch ableiten das der user halt diese "Funktion" will

... und wĂŒnscht sich dev:dikid

Neben einem guten ticketer ist aber ein repository genauso wichtig, nicht nur fĂŒr softwarebastler.

Always create an issue for things you work on.