Login
Login-Name Passwort


 
Newsletter
Werbung

Do, 18. September 2003, 00:00

Vorstellung des Projektes »FreePriority« (Version 0.4.1)

Das Programm soll pädagogischen Teams helfen, ihre Arbeit zu koordinieren, zu dokumentieren und zu überprüfen. Das Programm hat nicht den Anspruch, eine Groupware-Lösung oder ein Ticket-System zu sein. Pädagogische Teams sind sinnvollerweise nicht größer als ca. acht Personen. Das ist der Rahmen, in dem sich das Programm bewegt.

Vorwort

Die graue Theorie

Ein nicht unerheblicher Teil des Artikels beschäftigt sich mit der Organisation von Arbeit selbst. Hinter dem Programm steht eine bestimmte Art, mit pädagogischer Arbeit umzugehen. Wenn Sie das Programm effektiv benutzen wollen, werden Sie auch die Struktur Ihrer Arbeit überprüfen und ggf. anpassen müssen. Das Programm ist nicht dazu da, Ihre Strukturschwächen zu kompensieren, sondern sie aufzudecken und zu verändern. Wenn Sie also nicht bereit sind, sich mit der Theorie dieses Programms zu beschäftigen, werden Sie auch nicht die Stärken für sich nutzen können.

Zielhierarchie

Jeder Pädagoge sollte sie kennen, die "Zielhierarchie". Das Prinzip "vom Allgemeinen zum Speziellen": Richtziel, Grobziel, Feinziel. Der Sinn einer solchen Zielhierarchie ist, dass jedes Ziel in einem Kontext steht und sich diesem einfügen sollte. In den letzten Jahren wurden die Mittel im sozialen Bereich immer weiter gekürzt. Dadurch wurde der Personalschlüssel (Verhältnis Betreuer zu Betreuten) immer knapper. Aus Personalmangel muss jetzt noch genauer geschaut werden, wie Arbeit effizienter gestaltet werden kann. Hier kommt jetzt der Name des Programms ins Spiel: "FreePriority".Es müssen Prioritäten gesetzt werden in der Zielstellung, wenn man noch sinnvoll arbeiten will. Es ist wichtig, sich klar zu machen, was die eigenen Ziele sind, um zu überprüfen, ob eine Maßnahme ihren Aufwand wert ist und ab wann eine Maßnahme zu "teuer" oder besser "ineffektiv" wird und man selbige besser abbricht, um freiwerdende Mittel besser einzusetzen.

Projekte

Die Definition von Projekt schwankt. In der Regel hat ein Projekt ein Ziel, eine Zeitspanne und Ressourcen (Mitarbeiter, Geld, Räume). Es gibt eine Menge Parallelen zwischen Objekten aus der OO-Programmierung und und Projekten. Das brachte mich auf die Idee, den Ansatz von OO-Programmierung auf die pädagogische Arbeit zu übertragen. Der Sinn ist unter anderem, der Informationen zu kapseln. Häufig stellen wir fest, daß nicht die Information an sich gefehlt hat, sondern sie nicht zum richtigen Zeitpunkt am richtigen Ort bei der richtigen Person war. Ein weiteres weit verbreitetes Problem ist es, die relevanten Informationen von den redundanten zu unterscheiden. Viel Zeit geht damit verloren, ständig Informationen zu sortieren und zu bewerten. Zeit, die in der eigentlichen pädagogischen Arbeit fehlt.

Um dieses Problem zu vermindern, kann man versuchen, Informationen zu separieren. Das heißt, dass Informationen immer an (gedachte) Einheiten gebunden werden. Ein Ziel, Ressourcen, Informationen und Aufgaben bilden zusammen eine Einheit. Diese Einheit sei künftig als "Projekt" bezeichnet. Die internen Abläufe und Informationsflüsse eines Projektes interessieren nur ihre Mitglieder.

Durch diese Informationskapselung sollten die Mitarbeiterinnen nur mit den Informationen konfrontiert werden, die für ihre Arbeit von Bedeutung sind. Je kleiner sie die Projekte (oder Zielstellungen) definieren, umso differenzierter können sie mit dem Informationsfluss arbeiten bzw. ihn steuern.

Alles ist ein Projekt

Kaum ein Projekt existiert in einem luftleeren Raum. Beginnen wir beim Allgemeinen und gehen zum Speziellen. Die größte gedachte Einheit (also Projekt) ist die Einrichtung selbst, in dem ein Team von wahrscheinlich nicht mehr als zwölf Personen arbeitet. Alles, was darüber liegt, ist vielleicht eine Brigade, aber kein Team.

Als Beispiel nehmen wir eine pädagogisch betreute Wohngemeinschaft. Die Wohngemeinschaft ist das, was im Programm "Dachprojekt" genannt wird. In der Regel hat eine solche Wohngemeinschaft ein pädagogisches Ziel. Diese kann sich ändern, wenn z.B. BewohnerInnen ein- oder ausziehen. Deshalb läßt sich das Ziel des Dachprojektes auch jederzeit verändern.

Von dem Dachprojekt leiten sich dann weiter Feinziele ab, z.B. eine Gruppenreise. Hierfür wird dann ein Unterprojekt oder "Kindprojekt" angelegt. Und von diesen können weitere Kindprojekte abgeleitet sein, wie z.B. "Ausflug zum Strand". Auf diese Weise werden die Ziele immer weiter verfeinert und und konkretisiert. So gibt es immer ein enges "Eltern-Kind-Verhältnis" zwischen den Projektzielen.

.Bei allen Projekten unterhalb des Dachprojektes ist zu beachten: Man kann (Kind-) Projekte nicht umbenennen oder deren Ziele verändern. Das ist ganz bewusst so gemacht worden, weil das der Idee vom projektorientierten Arbeiten (oder auch "der Multiprojekttechnik") widersprechen würde. Eine Zieländerung ist - in der Idee von Multiprojekttechnik - einer Verwerfung eines Projektes und der Beginn eines neuen Projektes. Der Grund ist, dass die Dokumentation und Reflexion eines Projektes nur Sinn macht, wenn das Ziel eindeutig ist. Wenn das Ziel verändert wird, ist es schwieriger, über die eigene Arbeit zu reflektieren, weil der Wert der Arbeit immer am Ziel gemessen wird.

Es gibt bei jedem Projekt auch "Lateral-Erfolge", die nichts mit dem ursprünglichen Ziel zu tun haben. Aber das sollte nicht dazu verleiten, die ursprünglichen Ziele umzuinterpretieren oder umzubenennen. Das wäre Selbstbetrug. Stattdessen sollte darüber nach- gedacht werden, was zu der falschen Zielstellung geführt hat. Und wenn ich mir einen Fehler offen eingestehen kann, wird es mir auch besser gelingen, eine neue bessere Zielstellung zu überlegen, um dann planvoll und bewusst daran weiter zu arbeiten. Sonst bestünde die Gefahr, dass man versucht wäre, sich immer weiter durchzumogeln und sich eine gewisse Beliebigkeit einstellt. Die Zusammenhänge der (vielleicht gescheiterten) Projekte gehen dabei auch nicht verloren, weil der Beginn und das Ende eines jeden Projektes in den jeweiligen Eltern-Projekten dokumentiert wird.

Projektleiter

Jedes Projekt muss einen Projektleiter haben. Das heißt nicht, dass er das Projekt alleine mache muss. Der Projektleiter ist verantwortlich für das Projekt. Bei ihm laufen alle Informationen zu seinem Projekt zusammen. Er muss "Fachmann" sein für sein Projekt, denn er bildet die Schnittstelle zu seinen Kollegen und den anderen Projekten. Er organisiert die Arbeit zu seinem Projekt. Das heißt nicht - wie schon gesagt - dass er sie alleine macht. Nur muss er den Überblick behalten, denn seine Team-Kollegen verlassen sich auf ihn, so wie er sich auf die Übersicht der Projektleiter der anderen Projekte verläßt. So muss er nicht die Interna anderer Projekte kennen, sondern übernimmt nur die Arbeit, die ihm von dem jeweiligen Projektleiter übertragen wird, und wird auch nur die Informationen erhalten, die er braucht, um diese Arbeit zu machen. Auf diese Weise werden Informationen und Arbeit gekapselt und separiert und sorgen für Entlastung und Struktur.

Kommentare (Insgesamt: 0 || Kommentieren )
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung