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.

11.03.1994

Technikzentrierte Berufsauffassung ist ueberholt Software-Entwicklung hat auch politische und soziale Aspekte

Von Friedrich Weltz*

Software-Entwickler sind nicht mehr nur kognitiv gefordert. Sie muessen auch betriebspolitischen Anforderungen gerecht werden. Dies indes deckt sich nicht mit ihrem bisherigen technikzentrierten Selbstverstaendnis. Qualitative und oekonomische Aspekte sprechen dafuer, soziale und ingenieurmaessige Faehigkeiten unter einen Softwerkerhut zu bringen.

Dem Aussenstehenden mag Software-Entwicklung als ein eher trockenes Geschaeft erscheinen, wenn auch eines mit hohem Anspruch. Wir hoeren von den Auseinandersetzungen zwischen der Unix- und der Open- Systems-Welt. Wir verfolgen die Diskussionen um die Vorteile verschiedener "Sprachen" mit beeindruckenden Namen: Pascal (warum nicht Kant?), Lisp (warum nicht Stutter?) oder Cobol (warum nicht Wicht?); wir lesen von Projekten mit so anspruchsvollen oder geheimnisvollen Titeln wie Wisdom, Task und Batis. Die Auseinandersetzungen um die Vorteile der einzelnen Systeme, Sprachen, Tools und Releases in den Fachzeitschriften erfolgen offensichtlich auf einem Niveau grosser Fachlichkeit und Abstraktion. Der Gipfel der Anschaulichkeit erscheint erreicht, wenn Informatiker von Spaghetti-Programmen sprechen. Darunter kann sich auch der Laie etwas vorstellen, wenn auch sicher das Falsche.

Hier, so vermittelt sich der Eindruck, regiert die Technik, und damit Rationalitaet, Sachlichkeit, kuehle Distanz zu den Niederungen gefuehlsbezogener Einstellungen und Wertungen. So ueberraschte uns die Emotionalitaet, auf die wir in den Gespraechen mit Software- Entwicklern stiessen, in denen wir uns ueber ihre Berufserfahrungen unterhielten.

Noch kaum je waren wir bei einer Untersuchung aehnlich anschaulichen Schilderungen emotionaler Krisen begegnet: schlaflose Naechte, Nervenkrisen, ja Traenen (echte, keine symbolischen oder Krokodilstraenen).

Wieso, so fragten wir uns, kann ein technischer Entwicklungsprozess so emotionsbefrachtet sein? Warum ist die Wahl zwischen einer Anlage von IBM oder DEC, zwischen Standardsoftware oder Eigenentwicklung, die Entscheidung ueber die Einbeziehung dieser oder jener Funktion nicht nur so hart umkaempft, sondern auch mit solchen Emotionen beladen? Was belastete die Kontroversen mit Kollegen, Vorgesetzten, Auftraggebern, Anwendern, bei denen es um das Wie der anstehenden Loesungen ging? Nicht technische Schwierigkeiten loesten emotionelle Krisen aus, sondern immer wieder das Problem, einen Konsens ueber den richtigen Weg zu finden. Folgende Entwicklung stellte sich in vielen Projekten ein:

- eine haeufig relativ kurze Anfangsphase, in der das Projekt geplant und Konzepte entwickelt wurden, mit einer eher optimistischen, bisweilen fast euphorischen Grundstimmung;

- eine meist recht ausgedehnte, oft immer wieder verlaengerte, hoechst belastende und emotionsbefrachtete Periode, in der diese Konzepte "verkauft" wurden, das heisst mit allen involvierten Stellen (innerhalb der DV, bei den Anwendern, beim Spitzen- Management, bei den Herstellern) abgestimmt werden mussten;

- eine meist ebenfalls laengere Phase der Ausarbeitung, fuer die angesichts der Abstriche, die vom urspruenglichen Konzept gemacht werden mussten, und der haeufigen Zusatz- und Aenderungsanforderungen eine eher resignative Grundstimmung charakteristisch war;

- eine haeufig recht hektische Schlussphase, in der angesichts der wachsenden Ueberschreitung des Zeit- und Kostenbudgets bei allen involvierten Stellen die Ungeduld wuchs und Einigung darueber hergestellt werden musste, was nun als endgueltiges Produkt zu betrachten sei.

Grundsaetzlich korrespondierte die "Emotionalitaetskurve" weitgehend mit dem "politischen" Gehalt der einzelnen Projektphasen. Die Stimmung hing davon ab, mit welcher Dringlichkeit entschlossen werden musste, wie das Produkt letztlich auszusehen habe.

Hinter den Diskussionen um technische Details stand meist die Auseinandersetzung um Prinzipielles. Und Kaempfe um Grundsaetze sind immer besonders erbittert. Erschwerend kam aber hinzu, dass es meist nicht nur um die wahre Lehre ging, sondern auch um ganz handfeste materielle Aspekte.

Viele Entscheidungen ueber eine DV-Anwendung waren fuer die von ihr Betroffenen - in den DV-Abteilungen selbst wie in den Fachbereichen - zumindest potentiell mit Vor- und Nachteilen verbunden: Karriereaussichten, Qualifikationschancen, Handlungs- und Einflussspielraeume wurden eroeffnet oder eingeschraenkt.

Die Wahl etwa zwischen IBM oder DEC war somit nicht nur eine Entscheidung ueber eine technische Anlage, sondern auch ueber persoenliche Zukunftsperspektiven.

Die Enttscheidung fuer eine Programmiersprache konnte sich auf die Einflussverteilung zwischen DV und Fachbereichen auswirken. Verborgenes Konfliktpotential wurde so aktualisiert.

Was die Auseinandersetzungen zweifellos erschwerte und zu ihrer Emotionalitaet beitrug, war der Umstand, dass haeufig auf technischer Ebene argumentiert wurde, wo es auch oder primaer um politische Aspekte ging und damit vermieden wurde, dass diese ausdruecklich und offen zur Sprache kamen.

Dabei waere es wohl falsch, diese Diskussionen um Technik nur als Scheinargumentationen aufzufassen, durch die die letztlich allein ausschlaggebenden politischen Aspekte nur verdeckt wurden.

Beide Ebenen hatten ihr Gewicht, nur war in den Auseinandersetzungen meist schwer auszumachen (und vor allem nicht nachzuweisen), welche nun letztlich gerade den Ausschlag gegeben hatte. Mit dieser Doppelboedigkeit umzugehen war offensichtlich nicht einfach; und ohne Zweifel trug sie zu der Emotionalitaet bei, von der man uns berichtete.

Ausbildung und berufliches Selbstverstaendnis haben dabei den Zugang zu dieser politischen Qualitaet des Gegenstandes der Arbeit - der Produktion von Software - erkennbar erschwert. Dies gilt insbesondere fuer jene Software-Entwickler, die direkt von einem Informatikstudium in ihre jetzige berufliche Taetigkeit uebergewechselt sind, ohne je Erfahrungen in der betrieblichen Praxis gesammelt zu haben.

Ein Softwareprogramm war fuer sie

- nicht in die Technik transponierte Organisation menschlicher Arbeit und Kooperation,

- nicht die Festschreibung von Arbeitsablaeufen und Zustaendigkeitsverteilungen,

- nicht die Zuordnung oder Einschraenkung von Handlungsmoeglichkeiten,

- nicht der Gewinn oder Verlust von Qualifikationen,

- sondern die Loesung eines abstrakten Problems durch die Technik.

Software-Entwicklung bedeutet in diesem Verstaendnis die Formulierung von Pflichtenheften, Programmen und Testablaeufen. Der Arbeitsplatz ist der Schreibtisch beziehungsweise am Bildschirm. Das Ideal ist die ungestoerte Taetigkeit an diesem Platz, die zu einem fertigen Produkt fuehrt. Konferenzen, Gespraeche, Sitzungen, wo Konzepte abgestimmt, Informationen ausgetauscht, Positionen abgeklaert werden, erscheinen als Zeitvergeudung, denen man leicht mit gereizter Ungeduld begegnet. Eine solche technikorientierte Auffassung von Software wie ueberhaupt des Wesens der Datenverarbeitung laesst nicht technikbezogene Anforderungen als etwas eher Stoerendes erscheinen, das von der eigentlichen Aufgabe, eine moeglichst perfekte Software zu erarbeiten, nur abhaelt.

Die Beruecksichtigung der Anforderungen Software-ergonomischer Systemgestaltung wie auch der spezifischen - unter Umstaenden betriebspolitischen - Gegebenheiten und Beduerfnisse in den Anwendungsbereichen erscheinen in dieser Sichtweise nicht als integraler, wesentlicher Bestandteil der eigenen Aufgabe, sondern als etwas Zusaetzliches. Entsprechend schwer faellt es, mit den Turbulenzen, Konflikten und Beanspruchungen, die sich aus den nicht technischen Anforderungen ergeben, fertig zu werden - ein Umstand, der sich in vielen Projekten nachteilig auf deren Durchfuehrung und Ergebnis auswirkt.

Letztlich verweisen diese Schwierigkeiten also auf die Berufsauffassung der Software-Entwickler. Solange diese durch ein technikzentriertes Selbstverstaendnis, das sich am ingenieurmaessigen Vorgehen orientiert, gepraegt ist, solange Software-Entwicklung nicht wesentlich auch als Arbeitsstrukturierung begriffen wird, bei der neben technischen soziale, betriebspolitische und oekonomische Aspekte gleichermassen beruecksichtigt werden, wird sich wenig aendern.

Hier liegt wohl die groesste Herausforderung an die Informatik an den Hochschulen und anderen Ausbildungseinrichtungen in den naechsten Jahren.

"Jeder hat Angst: Ist mein Wissen nicht mehr gefragt, bin ich morgen ueberfluessig, wird meine Position in Frage gestellt, wer kommt dann auf meinen Platz. Wissen bedeutet ja auch hier Macht." **

"Das waren damals ungeheuer heftige Diskussionen. Wir haben uns ein Jahr ueber Grundkonzepte gestritten." **

"Das hat man ja nicht so einfach abschuetteln koennen, diese endlosen, erhitzten Diskussionen. Die sind allen unter die Haut gegangen." **

"Wenn Sie bestehende Geleise veraendern, loesen Sie Unsicherheit aus. Das ist immer ein Kraftakt, da muss man sich schon sehr sicher sein, wenn man sich das zumutet. Wenn man so ein Projekt in die Welt setzt, loest man zum Teil direkt Hysterie aus. Die sehen das alles gleich morgen auf sie zukommen; die sehen nicht, dass das ein Prozess ist, der Zeit braucht und dass jeder da wieder seinen Platz finden wird."**

** Alle Zitate stammen aus Interviews, die die Sozialwissenschaftliche Projektgruppe (SPG), Muenchen, durchgefuehrt hat.

* Professor Friedrich Weltz ist Geschaeftsfuehrer der Sozialwissenschaftlichen Projektgruppe (SPG), Muenchen.