[linux-l] Trouble Ticket System für die BeLUG

[Steffen Dettmer]

* Olaf Radicke wrote on Thu, Mar 23, 2006 at 17:18 +0100:
 [...] 
> Also ich würde gerne ein Projekt dazu starten. Mich hat das Thema Trouble 
> Ticket System sowieso schon interessiert. Mein Vorschlag:

Grundsätzlich finde ich sowas prima; wir benutzen sowas auf Arbeit. Es
hilft, Transparenz zu erhalten, später nachvollziehen zu können, was
gemacht wurde und vor allem hilft es, Dinge nicht zu vergessen.

Allerdings scheinen mir zwei Dinge wichtig, die in diesem Fall
möglicherweise nicht gegeben sind.

Erstens muss es eine Art "Controller" geben. Das ist jemand, der sich
beispielsweise um Artefakte kümmert, die niemandem zu gewiesen sind oder
die lange nicht bearbeitet wurden und dergleichen; auch die Dinge, die
aus irgendwelchen Gründen nicht zum gewünschten "Workflow" passen,
Ausnahmen oder Spezialbehandlung bedürfen. Passiert ja in der Praxis
dann erstaunlich oft, dass irgendwo etwas nicht 100% passt. In Firmen
meist einfach zu lösen: entweder bestimmt man einen oder es macht der
Chef, dass ist ja in den "normalen" Abläufen auch meist so: kann man
etwas nicht selbst lösen, ist es das Problem des Chefs :)

Zweitens macht so ein System IMHO eigentlich nur Sinn, wenn es Probleme
enthält, die man nicht sofort "ad hoc" lösen kann (sonst löst man die ja
einfach gleich), Rückfragen etc. notwendig sein können (um es nicht zu
vergessen und Bearbeiter wechseln zu können) und wo ein einigermassen
einheitlicher Workflow passt (z.B. es wird immer analysiert, dann
korrigiert, dann getestet, dann vom wem auch immer akzeptiert oder nicht
etc.). Ob das so auf Installations- und Konfigurationsprobleme passt,
wage ich zu bezweifeln. 

Anhand der Mailingliste (und anderer) meine ich folgende Beispiele für
diese beiden Probleme erkennen zu können: 

 - Probleme werden teils gar nicht gelöst
   (Hat man 500 offene Dinge in einem Tracker, ist er schnell nicht mehr
   wirklich eine Hilfe)
 - Es gibt i.d.R. weder klaren "Problem Owner"
 - Es gibt keinen Controller
   (Werden Fragen oder Probleme nicht beantwortet, ist das eben so; es
   gibt niemanden, der dann andere bittet, zu diesem oder jenen Problem
   nachzulesen um es zu lösen oder so. Wird sicherlich auch nicht so
   einfach, weil man ja keine Zeit hat etc). Prioritäten etc. lassen
   sich sicherlich kaum objektiv definieren. Das ist bei Kunden meist
   einfacher.
 - Es gibt viele unterschiedliche Arten, Proble zu lösen
   (vom einfachen URL posting, vermutlich bis hin zu mehrfachen
   persönlichen Treffen; auf der Liste haben Leute, die an ganz was
   anderem arbeiten, die richtige Idee etc.)
 - Es wird nicht "direkt" getestet (nur probiert)
   (man kann es im Einzelfall natürlich probieren, teils bekommt man
   nichtmal feedback ob es denn nun geht. Veralgemeinert kann man selten
   testen, weil das von Versionsnummern etc. abhängt, die genauen
   Anforderungen ja so nicht klar und numeriert sind, etc.)

Damit sehe ich also weniger einen "Prozess", sondern mehr so eine Art
"Marktplatz", wo viele gute Sachen passieren, aber am Ende nie
garantiert ist, dass das "beste" gekauft wird. Liest ein Fachmann
zufällig eine Frage, beantwortet er sie gleich und es ist einfach. Liest
er sie zufällig nicht, wird das Problem vielleicht nicht gelöst, oder
"ausserhalb" (in dem Fall bekommt man die Lösung etc. vermutlich oft gar
nicht mit).

Ich hab in einem Projekt zwei Trackerdiskussionen und Einführung hinter
mir und beruflich Erfahrungen. Ein Hauptproblem scheint mir zu sein,
dass vorher selten genau klar ist, was man genau will. Ich denke, ein
Tracker / TTS sollte man benutzen, wenn man entsprechende Abläufe
bereits "händisch" macht, um Telefonkosten zu sparen und nicht mehr nach
eMails suchen zu müssen. Arbeitet man hingegen ganz anders, wird einem
ein Tool nicht unbedingt helfen, Probleme zu lösen, die man nicht
händisch "mit Zettel und Stift" lösen kann. Oder man sagt ganz klar: das
wollen wir alle nicht, eigentlich wollen wir nur eine Online-Liste und
finden ein TTS hier einfacher zu bedienen als ein Wiki oder so.

Natürlich sollt es möglich sein, diese Probleme anzugehen und zu lösen,
klar!

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.