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.

10.08.1984 - 

Unprofessionelles Verhalten wirkt sich extrem kostenintensiv aus

Teamarbeit: Ein Weg aus der Softwarekrise

MÜNCHEN - Softwarekrise, Anwendungsstau, Benutzerkonflikt - Begriffe, die immer wieder in der Fachpresse vorkommen. Mit immer mehr Fachwissen und dem Eisatz von Tools versuchen die Software-Leute, den Problemen beizukommen. Der einzige Weg aus dem Dilemma aber heißt Software-Engineering, die systematische Programmerstellung in Teamarbeit. Diese Ansicht vertritt Brigitte Schröder, Mitarbeiterin der Coverdale Team Management Deutschland GmbH in Schleching. Im folgenden Bericht geht sie auf die immer wieder beobachteten Schwierigkeiten bei der Softwareerstellung ein und versucht, einen Weg aus der Krise zu weisen.

Lange Zeit hat man versucht, der Krise mit immer mehr Fachwissen, mit Einsatz von immer mehr Tools entgegenzuwirken. Doch damit bekämpft man nur einzelne Symptome. Sollte man sich jetzt nicht einmal auf andere, mehr systematische Ansätze besinnen? Inzwischen ist die Einsicht gewachsen, daß das Erstellen einer Gesamtkonzeption für ein Softwareprojekt nicht mehr Zeit kostet, sondern im Gegenteil Zeit, Geld und Frustrationen (er)spart.

Starre Phasenmodelle führen zu unsicherer Qualität

Doch selbst Phasenmodelle als Hilfe führen zu Ergebnissen, deren Qualität völlig unsicher ist, wenn man von ungeprüften Vorgängen ausgegangen ist. Die Crux beginnt ja oft schon bei der ungenauen Zieldefinition von seiten der Geschäftsleitung. Wenn nicht rückgefragt und auf genauerer Definition des Informationsbedarfs bestanden wird, bleibt es oft Glückssache, die Bedürfnisse zu treffen. Ohne genaue Zielklärung und Überprüfung, ob dieses Ziel mit den zur Verfügung stehenden Mitteln überhaupt erreichbar ist, ist auch der Erfolg eines Projektes nicht meßbar.

Eine Gefahr besteht darin, ein Phasenmodell zu starr zu benutzen, das heißt einfach weiterzumachen, obwohl neue

Informationen vorliegen die zum Überdenken zwingen sollten und möglicherweise für eine Änderung des eingeschlagenen Weges sprechen. Es wäre empfehlenswert, daß Beteiligte aller Ebenen einmal in einer risikofreien Seminarsituation die Auswirkungen unsystematischen - oder auch starr systematischen - Vorgehens erleben würden und sich dabei erfolgreiche Arbeitstechniken aneigneten. Ich denke dabei beispielsweise an Auswirkungen auf Zeitbedarf, Arbeitszufriedenheit, Qualität des Produkts, Akzeptanz bei den Auftraggebern. Das wäre nicht nur der Softwarebranche zu empfehlen - aber gerade hier wirkt sich unprofessionelles Verhalten extrem kostenintensiv aus.

Weiter fällt auf, daß abgeschlossene Projekte in der Regel nicht oder in unzureichender Weise auf Erfolge hin analysiert werden. Daher werden erfolgreiche Praktiken nicht systematisch auf das nächste Projekt übertragen. Kein Wunder, daß die gleichen Fehler immer wieder gemacht werden!

Schon zu Beginn eines Projektes heißt es oft: "Führen Sie eine Schwachstellenanalyse durch... ."Die positiven Praktiken im manuellen System werden nicht registriert und gehen im weiteren Prozeß oftmals verloren. Die Annahme, daß alles geändert werden muß und alles mit dem Computer besser läuft, trifft nicht nur aus irrationalen Gründen oft auf Widerstand bei den Fachabteilungen. Das gleiche gilt für die Ablösung bereits bestehender Computersysteme.

Eigentlich sollte eine Ist-Analyse die Stärken und Schwächen eines Systems herausstellen. Verbreitet ist diese Praxis aber nicht. Denn es fällt uns nicht leicht Positives zu sehen. Das Negative dagegen fällt auf.

Kooperation erfordert Übung und Umdenken

Wir müssen also von Grund auf umdenken. Und das gelingt kaum einfach dadurch, daß es jemand von uns verlangt oder wir uns "Mühe geben". Man muß dies üben, um wirklich Veränderungen erwarten zu können.

In sämtlichen Stellenanzeigen werden Mitarbeiter mit "Bereitschaft zur Teamarbeit" gesucht. Bereitschaft, schön und gut - wer hätte die nicht heutzutage, wo jeder die Notwendigkeit von Zusammenarbeit erkennt. Nur: Bereitwilligkeit allein reicht erfahrungsgemäß nicht aus. Denn offensichtlich hapert es trotzdem mit der Teamarbeit. Was fehlt, sind handfeste Fertigkeiten. Die müssen erarbeitet und trainiert werden.

"Einfach" ist es ja noch, wenn es zum Beispiel um ein Entwicklungsteam geht. Da kann man das altbekannte "Wir-Gefühl" in Abgrenzung zu den anderen", den Benutzern, entwickeln. Daß diese Abgrenzung nicht unbedingt zum Vorteil des Produktes gereicht, ist wiederholte Erfahrung. Wie leicht bekommt das stolze Entwicklungsteam dann zu hören: Prima Lösung - aber leider zum falschen Problem!

Die neuen Techniken haben unsere Arbeitszusammenhänge durcheinandergerüttelt. Die Informationsressourcen, die wir zu einer optimalen Arbeit benötigen, liegen oft außerhalb des eigenen Arbeitsbereiches. Der Programmierer braucht für seine Arbeit notwendig die

Informationen der Fachabteilung. Wenn er diese womöglich als Gegner ansieht, wird der Informationsaustausch besonders erschwert. Das gleiche gilt natürlich umgekehrt genauso.

Defensives Management durch Resignation

Wir sind nicht Mitglieder einer einzelnen Gruppe, sondern mehrerer Gruppen mit wechselnder Zusammensetzung. Wir müssen Mitglieder fremder Abteilungen, ja, oft auch anderer Ebenen, in unsere Gruppen hereinlassen. In einem Projektausschuß treffen sich Vertreter verschiedener Abteilungen, verschiedener Unternehmen. Das verlangt weitergehende Fertigkeiten der Zusammenarbeit, mehr als sogenannte "Fähigkeit im Umgang mit Kunden".

Resignation vor Zusammenarbeitsproblemen führt dazu, daß die schönsten Projekt-Management-Werkzeuge defensiv benutzt werden. Anstelle von Zusammenarbeit findet Abschieben von Verantwortung statt. Der Softwareentwickler ist Profi in der Kommunikation mit der Maschine. Leider qualifiziert ihn das nicht gleichzeitig für die Kommunikation mit anderen Menschen.

Es wird viel geschrieben über "Kommunikation" zwischen DV-Abteilung. Man liest von Vorschlägen, wie man einzelne Mitarbeiter mit den Arbeitsweisen der "anderen" vertraut machen kann, etwa durch "Job-Rotation". Dies macht die anderen etwas weniger anders und erleichtert sicher das gegenseitige Verständnis. Es ändert aber nichts daran, daß verschiedene Parteien auf ein gemeinsames Ziel hin zusammenarbeiten müssen. Und das geht über die herkömmliche Interpretation des Begriffs "Kommunikation" hinaus.