Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

12.04.1991 - 

Technisch-administrative Ansätze enttäuschen meist

CASE-Probleme sind oftmals von der gruppendinamischen Art

12.04.1991

Weder im technischen noch im methodischen Bereich, so Gisela Bolbrügge*, lassen sich die Produktivitäts- und Qualitätsprobleme der Anwendungsentwicklung lösen. Entscheidende Bedeutung bekommt oft ein Faktor, der kaum vom Einsatz des jeweiligen CASE-Systems abhängt, nämlich der gruppendynamische Prozeß innerhalb des Entwicklungsteams.

"Wir können uns die Menschen, mit denen wir arbeiten, nicht aussuchen." Diese Meinung kann dazu führen, daß in konkreten Projektkrisen unterlassen wird, entsprechende Teamentwicklungs-Maßnahmen zu ergreifen. Die unausgesprochene Erwartung, die Dinge werden sich im Laufe der Zeit schon wieder regeln, bringt nur Enttäuschungen hervor. Denn in Projekten, bei denen ein Endtermin fest geplant ist, ist diese Zeit einfach nicht vorhanden.

Im Gegenteil: Steigender Zeitdruck macht die Zusammenarbeit zunehmend schwieriger, und die Arbeitsergebnisse entsprechen weder der gewünschten Qualität, noch werden die Projekte rechtzeitig beendet. Diese Vogel-Strauß-Politik kann zur Folge haben, daß sich Mitarbeiter dauerhaft verfeinden, daß sich Resignation breitmacht, daß der eine oder andere innerlich kündigt oder das Unternehmen aufgrund dieser Reibungsverluste verläßt.

Solche Situationen zehren an den Nerven der Beteiligten und der Verantwortlichen, ganz zu schweigen davon, daß sie Geld kosten. Wie hoch allerdings diese Kosten sind, ist nicht ganz einfach festzustellen. Müssen Projekte immer wieder in solche Krisen geraten oder sind diese Probleme vermeidbar? In diesem Zusammenhang lohnt es sich durchaus, den Verlauf eines Projektes unter gruppendynamischen Gesichtspunkten zu betrachten.

Ein wesentliches Merkmal insbesondere von DV-Projekten ist, daß das Team nicht über die gesamte Projektdauer aus denselben Mitarbeitern besteht. Einzelne Fachleute werden bei Bedarf hinzugezogen und verlassen das Projekt wieder. Dieser Tatsache wurde bisher unter dem Aspekt "Zusatzaufwand für Kommunikation" Rechnung getragen.

Nach Tuckmann durchläuft eine Gruppe von Menschen, und hierbei ist es nebensächlich, unter welchen Sachaspekten sie zusammenkommt, folgende vier Phasen:

- Forming (Zusammenkommen),

- Storming (Sich-Zusammenraufen),

- Norming (sich Regeln geben) und

-Performing (Leistung erbringen).

Das heißt, wirklich arbeitsfähig und produktiv wird ein Team erst damit wenn es die Schwierigkeiten der ersten drei Phasen durchlaufen hat. Wer schon einmal die Gründung eines Vereins miterlebt hat, kann dieses Modell sicher leicht nachvollziehen.

Je mehr Zeit also ein Team benötigt, bis es in die Phase des Performing eintritt, um so näher ist bereits der Endtermin des Projektabschnittes gerückt. Die Zeit, die ursprünglich für die Erstellung des Arbeitsergebnisses geplant war, ist stark geschrumpft. Dafür steigt aber der Termindruck. Der Teufelskreis hat begonnen.

Gelingt es, den Zeitpunkt des Performings im Projektverlauf beziehungsweise in den einzelnen Abschnitten weiter nach vorn zu rücken, so können gleichzeitig die Produktivität des Teams und die Qualität der Ergebnisse gesteigert werden. Bisher wurde mit diesem Anspruch die Einführung technisch-administrativer Methoden begründet. Doch die erwünschten Effekte blieben aus. So werden auch die Erwartungen an CASE hinsichtlich Produktivität und Qualität vermutlich solange enttäuscht werden, bis sich die Erkenntnis durchsetzt, daß die meisten Probleme in der Software-Entwicklung weder im technischen noch im methodischen Bereich zu suchen sind.

Die Veränderungen am Arbeitsplatz eines Software-Entwicklers vollziehen sich in immer kürzeren Zeitabständen, und zwar in zwei Bereichen: in technischer Hinsicht und im Hinblick auf die Arbeitsorganisation. Forderungen nach Normierung und Standardisierung machen ein neues Arbeitsverhalten erforderlich. Von Menschen, die im DV-Bereich arbeiten, wird einfach erwartete daß sie sich rasch anpassen und ständigen Neuerungen gegenüber aufgeschlossen sind. Unsicherheiten und Ängste, die unter diesen Umständen entstehen, werden verdrängt und ignoriert; sie aber erzeugen Druck, der dann im Umgang mit anderen abgebaut werden muß. Die Zusammenarbeit im Team findet gleichzeitig auf drei Ebenen statt, nämlich auf der Sachebene, auf der Geschäftsordnungsebene und auf der Beziehungsebene. Immer wieder lassen sich - zumindest am Projektbeginn - Unklarheit und Unsicherheit auf allen drei Ebenen erkennen.

Nicht selten ist den Projektmitarbeitern ihre Aufgabe

höchst unklar, weil weder das Ziel noch die Rahmenbedingunen genau und operationalisierbar beschrieben wurden. Unsaubere Projektdefinitionen sorgen in manchem Projekt für Verwirrung und kosten Zeit.

Fehlende Vorbereitung und Schulung hinsichtlich der administrativen Seite des projektmanagements oder gar das Fehlen eines Vorgehens- oder Phasenmodells können der Grund für Unsicherheit hinsichtlich der strukturellen Ebene sein. Es fehlt auch hin und wieder am Verständnis für den Sinn und Zweck des eigenen Tuns, wenn die Beziehung zum Gesamtzusammenhang nicht vermittelt werden konnte.

Bei all den genannten Störungen auf der Sach- und Geschäftsordnungsebene ist die Beziehungsebene noch durch den oben beschriebenen Gruppenentwicklungs-Prozeß belastet. Würde doch die Mißstimmung auf einer dieser drei Ebenen völlig ausreichen, um die Produktivität und Effizienz eines Teams zu senken!

Werkzeuge und Methoden allein helfen nicht

Dies macht deutlich, daß Methoden und Werkzeuge allein nicht geeignet sind, Produktivitätssteigerungen bei der Software-Entwicklung zu erreichen, sondern nur Hilfe und Erleichterung auf der strukturellen Ebene leisten können. Wenn hier Erwartungen enttäuscht werden, so liegt die Ursache dafür also nicht unbedingt an den falschen Tools und Methoden.

Was also ist zu tun? Von DV-Mitarbeitern wird stets gefordert, daß sie teamfähig seien, wiewohl selten genau definiert wird, was genau damit gemeint ist. Die bisher beschriebene Problematik kann also gelöst werden, wenn man Mitarbeiter aus dem DV-Bereich dabei unterstützt, ihre persönlichen und sozialen Kompetenzen zu erhöhen. Es ist schließlich eine Frage dieser Fähigkeiten, wie schnell die ersten drei Phasen der Gruppenentwicklung bewältigt und die Energien frei für die eigentliche Aufgabe werden.

Dann erst können auch Methoden und Werkzeuge ihren vollen Nutzen entfalten. Das Dilemma im DV-Bereich ist jedoch, daß es als immens wichtig erachtet wird, das technische Wissen stets so aktuell wie nur irgendmöglich zu halten, während die Stärkung der sozialen Kompetenz als Nice-to-have eingeschätzt wird. Umdenken tut hier not.