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.

aus

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.

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.

Technik

 

Abgrenzung
Issue Trackiung

• Redmine
• mantis

Customer
und OTRS sind beides Ticketsysteme

Groupware
sind meist adressverwalter und kalender

 

Funktionen

• mail
  • direkt an also an personen die nicht im System sind (OTRS-Ansatz)
• Taging
  • kunde als 'john@example.net' und '@example.net'
  • closes/open
  • Prio
  • bearbeiter
  • udn das alles schon stylen je nach wichtigkeit
  • auch "hide"
  • droper
• recents als mail oder rss oder twitter oder mir egal
  • neues
  • anders Tag (aka Quee verschoben)
  • tag beobachten (gaht in mediawiki nicht)
• adding
  • als comment (also drunter)
  • als version (also drüber aka wikiverison)
• rechte rollen
  • aus framework
    • rechte rollen
    • access
    • imap?
  • proaktiv nur wenn für bestimmtes tag freigeschalten, sonst generel nie (!= wiki))
  • sperren auf user
• trigger
  • auslösen von 2 und 3 Aktioen bei (reopen bei followup) tag bei new ect

 

Erfahrung

klml kennt

• mantis
• redmine kann sehr viele mit mails (in out) aber halt RoR
• flyspray wird afaik nicht mehr maintained
• OTRS eigentlich ein Kondenkommunikatonssystem (mails und Anrufe), man kann zwar keine Version oder Releases planen, aber
• Hörensagen
• Jira_(Software) soll ja der Weisheit letzter Schluss sein ...
  • fogbugz Kartoffelpresse! auserdem kein OS und 25$ p/m
  • trac ist zwar auch nett, aber auch soviel struktur zum pressen
  • launchpad
• trac
• basecamp kein OS und 50$ p/m
• mingle kommt über den Scrum-Taskboard Ansatz, recht clickibunti für noobs, aber vmtl eher nur innerhlb des teams zu gebrauchen, kann afaik keine mails

 

Aber auch persönliche ToDolisten sind eigebtlich nicht gruppenfähige Projektverwatlungssysteme, aber meist dafür sehr einfach bedienbar

• rememberthemilk.com nutzt klml
• todoist wirkt halt ser appleexk aufgeräumt
• 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

... und wünscht sich github.com/klml/dikid

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

---