Wie die formale Projektorganisation variiert die Arbeitsteilung in den Projektteams von Projekt zu Projekt sehr stark. Sie ist häufig weniger Resultat formaler Aufgabenzuweisung, sondern eher das Ergebnis eines naturwüchsigen Prozesses.
Wie allgemein in industriellen Produktions - und Entwicklungsprozessen ist die Aufteilung der anfallenden Arbeitsaufgaben in der Software - Entwicklung wichtige Gestaltungsdimension sowohl für die Abwicklung und das Ergebnis von Softwareprojekten als auch für die Arbeitsbedingungen der in der Software - Entwicklung Beschäftigten. Unter dem Schlagwort " Taylorisierung " wird eine schematische, kleinteilige Aufteilung von Arbeitsprozessen auch im Zusammenhang mit der Software - Entwicklung zunehmend kritisch diskutiert. Die negativen Auswirkungen auf die Arbeitssituation - und damit die Motivation der Beschäftigten - und auf die Qualität der Softwareprodukte stehen dabei im Vordergrund (Hesse 1991). Schlagworte wie Softwarefabrik und der Einsatz sehr spezialisierter Werkzeuge lassen vermuten, daß hier Entwicklungen im Gang sind, die möglicherweise die Arbeitsteilung bei Softwareprojekten und damit die Arbeitssituation der Software - Entwickler tiefgreifend verändern.
Die Befürchtung, daß sich in der Software - Entwicklung Fehler, die bei der Organisation industrieller Produktionsprozesse gemacht werden, wiederholen, ist zweifellos berechtigt. Gerade mit dem wachsenden Umfang und der zunehmenden Komplexität von Entwicklungsvorhaben gewinnt die Auseinandersetzung mit den Möglichkeiten und Auswirkungen unterschiedlicher Formen der Arbeitsteilung in der Software - Entwicklung an Bedeutung. Über die zweifellos berechtigte Kritik an möglichen Auswüchsen tayloristischer Arbeitsorganisation darf allerdings nicht übersehen werden, daß - zumindest bei größeren Entwicklungsvorhaben - Arbeitsteilung grundsätzlich notwendig ist. Vorhaben von dem Umfang und der Komplexität, wie sie die meisten Softwareprojekte darstellen, lassen sich nur arbeitsteilig bewältigen. In fast allen untersuchten Projekten trafen wir auf eine mehr oder weniger ausgeprägte Arbeitsteilung in den Projektteams.
Solche Arbeitsteilung fehlte nur in jenen wenigen Projekten, in denen nur ein oder zwei Entwickler eingesetzt waren. Dabei handelte es sich durchweg um sehr kleine Projekte (siehe Abbildung 1).
Arbeitsteilung in den Projektteams ist in drei Dimensionen möglich: dem zeitlichen Nacheinander - einzelne Phasen werden von verschiedenen Entwicklern bearbeitet - , der anwendungsbezogenen Aufteilung einzelne Entwickler übernehmen jeweils einen Teilkomplex des Gesamtsystems und der systembezogenen Aufteilung, wobei einzelne Entwickler jeweils bestimmte systemspezifische Gestaltungskomplexe übernehmen, etwa Datenbanken, Steuerungssysteme. Relativ selten nur in einem Fünftel der Projekte wurde eine an Projektphasen ausgerichtete Arbeitsteilung praktiziert, etwa durch eine Trennung von Design, Realisierung und Test.
Wesentlich häufiger in fast 60 Prozent der Projekte trafen wir auf eine anwendungsbezogene Arbeitsteilung, nämlich auf die Bearbeitung von Subsystemen, wobei diese nach Charakter und Umfang beträchtlich differierten.
In etwa der Hälfte der Projekte gab es neben dieser phasen oder anwendungsorientierten Arbeitsteilung noch Spezialisten, die meist für bestimmte Systemfunktionen etwa Datenbanksysteme zuständig waren. In knapp 30 Prozent der Projekte galt das Prinzip: " Alle machen alles ", das heißt, die jeweils übernommenen Teilaufgaben wurden als Ganzes ausgeführt. In jedem zehnten Projekt gab es Teilteams, auf die die Bearbeitung der Gesamtaufgabe aufgeteilt war.
Das Phasenschema, das noch in der Mehrzahl der Projekte den Ablauf strukturiert, ist als Vorgabe für Arbeitsteilung eher die Ausnahme. Die vor allem für größere Projekte typische. Form der Arbeitsteilung ist die Zuweisung der Bearbeitung von Subsystemen an einzelne Entwickler, in Kombination mit der Übernahme der Bearbeitung bestimmter technischer Funktionen durch Spezialisten.
Nun sagen diese Formen der Arbeitsteilung noch wenig aus, wie kleinteilig die Aufgliederung der Arbeitsaufgaben erfolgte. Am ehesten läßt sich dies bei einer Ausrichtung der Arbeitsteilung am Phasenschema erwarten, ist hier doch die Beschränkung auf einen Tätigkeitstyp vorgegeben, zum Beispiel Analyse, Realisierung, Test. Bei den anderen Formen der Arbeitsteilung war eine solche Beschränkung eher eine Ausnahme, die bestimmte Gruppen besonders traf, vor allem Entwickler, die nur zeitweise in den Projekten eingesetzt waren. Zudem wurden hier die Wirkungen der Spezialisierung und Aufteilung der Aufgaben in vielen Projektteams auch aufgefangen durch die ausgeprägte Kooperation, die es unter den Entwicklern und meist auch mit dem Projektleiter gab
Die fachliche oder horizontale Arbeitsteilung muß ihrerseits in Verbindung mit den vertikalen Teamstrukturen gesehen werden. In der Hälfte der Projekte war diese sehr einfach: Dem Projektleiter standen die Entwickler gegenüber, denen jeweils eine Teilaufgabe zugewiesen war. In größeren Projekten gab es häufig noch einen stellvertretenden Projektleiter oder Teilprojektleiter. In einem Viertel der Projekte waren den Mitgliedern eines Kernteams von meist etwa drei bis fünf erfahrenen Entwicklern jeweils ein oder mehrere Zuarbeiter zugeordnet, denen sie einfachere Aufgaben zuteilten und sie bei ihrer Tätigkeit anleiteten beziehungsweise überwachten. Nur in etwa einem Zehntel der Projekte, durchweg in Anwender unternehmen, trafen wir auf den Chefprogrammierer, in dessen Hand die wesentlichen und anspruchsvolleren Entwicklungsarbeiten lagen und den ein oder mehrere Zuarbeiter unterstützten .
Neben der tätigkeitsbezogenen Arbeitsteilung gab es in fast allen Projekten eine qualitative Arbeitsteilung, das heißt schwierige und anspruchsvolle Tätigkeiten wurden überwiegend oder ausschließlich von bestimmten Teammitglieder ausgeführt, weniger qualifizierte Tätigkeiten von anderen. Eine solche qualitative Arbeitsteilung bestand in vielen Projekten zwischen Projektleiter und Teammitgliedern. So lag das Schwergewicht der Tätigkeit der Projektleiter in der Teilnahme beziehungsweise Durchführung von Sitzungen, in denen die inhaltliche und organisatorische Planung sowie Abwicklung des Projekts behandelt wurde, und bei der Administration beziehungsweise Organisation des Projekts. Daneben waren sie sehr häufig auch aktiv an dem eigentlichen Entwicklungsprozeß beteiligt. Dabei übernahmen sie zumeist besonders wichtige oder schwierige Entwicklungsaufgaben.
Etwa ein Drittel ihrer Arbeitszeit verbringen Projektleiter in Sitzungen und Beratungen - etwa zu gleichen Teilen mit projektinternen und projektexternen Partnern. Ein gutes Viertel ihrer Zeit ist organisatorischen Tätigkeiten gewidmet: Administration, Organisation, Akquisi-
tion. Knapp ein Viertel ihrer Arbeitszeit, so ergab die arbeitspsychologische Erhebung, arbeiten Projektleiter "produktiv" an der Software-Entwicklung mit, also am Spezifizieren, Codieren, Testen und Debuggen der Programme, an den Reviews oder anderen qualitätssichernden Maßnahmen. Knapp ein Zehntel der Arbeitszeit war schließlich der Systempflege und Dokumentation gewidmet.
[Brodbeck und andere]. Eine ausgeprägte qualitative Arbeitsteilung hatte sich vor allem in jenen - Projekten herausgebildet in denen der Projektleiter durch ein Kernteam oder einen Chefprogrammierer unterstützt wurde. Die Tätigkeit der übrigen Teammitglieder war hier meist auf weniger qualifizierte Zuarbeiten beschränkt.
Diese Form qualitativer Arbeitsteilung war dabei häufig nicht geplant, sondern quasi naturwüchsiges Ergebnis der Entwicklung des Personaleinsatzes im Projektverlauf. Zu dem Kernteam aus meist erfahrenen Entwicklern stoßen nach und nach in den mittleren Projektphasen mit ihrem höheren Anteil an ausführenden Arbeiten weitere qualifizierte Entwickler, die diese übernehmen.
Allgemein war in vielen Projekten die Arbeitsteilung im Team nicht-oder nicht allein - Ergebnis formaler Zuweisung, sondern quasi naturwüchsig entstanden; ad hoc übernommene Tätigkeiten hatten sich im weiteren Verlauf zu dauerhaften Aufgaben verfestigt, individuelle Vorhaben, Stärken oder Schwächen führten Zug um Zug zu einer Aufgabenteilung im Team.
In etwa 60 Prozent der Projekte waren die Aufgaben den einzelnen Teammitgliedern formal zugewiesen worden, in einem Viertel hatte sich die Übernahme der Aufgaben weitgehend informell eingespielt, in einem Zehntel war sie Ergebnis ad hoc auftretender Anlässe.
Vor allem in den kleinen und mittelgroßen Projekten reflektierte die Struktur den Arbeitsteilung im Projekt weniger die Ordnungsvorstellungen, unter denen dieses geplant worden war, sondern die Verteilung der Qualifikationen im Projektteam oder die historische Entwicklung des Projekts. Dieses Prozeß naturwüchsiger Aufgabenzuweisung verlief häufig recht rasch und führte zu einer dauerhaften Fixierung. Das Tempo wurde dabei wesentlich durch die Notwendigkeiten, die sich aus der Projektabwicklung ergeben, bestimmt. Wir trafen auf zahlreiche Fälle, wo ein bis dahin wenig qualifiziertes Teammitglied im Zuge der Übernahme einer Aufgabe innerhalb kurzer Zeit zum Spezialisten für einen bestimmten Fach- oder Anwendungsbereich avancierte.
Ähnlich wie die Projektorganisation wurde in vielen Projekten die Form der Arbeitsteilung erst im Projektverlauf gefunden. Im Unterschied zu dieser hatte die einmal eingespielte Arbeitsteilung meist eine beträchtliche Stabilität. Einmal etablierte Strukturen der Arbeitsteilung zeigten die Tendenz, sich zu verselbständigen, sich auch über einzelne Projekte hinweg fortzusetzen. Nach dem Motto "Einmal Spezialist, immer wieder Spezialist" wurde so bisweilen aus einer zunächst eher zufällig übernommenen Aufgabe und der damit verbundenen Qualifizierung eine Rollenzuschreibung, die unter Umständen den weiteren Karriereverlauf prägte. Eine solche Fixierung wurde von den Betroffenen ambivalent bewertet. Einerseits kann sie sehr rasch zu einer herausgehobenen Position führen, andererseits ist mit ihr die Gefahr einer einseitigen Festlegung verbunden, die auf Dauer eine Begrenzung der Karriereaussichten bedeuten kann. Wesentliche Bestimmungsfaktoren vor allem der qualitativen Arbeitsteilung waren also neben dem Umfangng, Struktur und Komplexität der Entwicklungsaufgaben vor allem die qualifikatorischen Voraussetzungen in den Projektteams. Hierbei machte sich in vielen Projekten der hohe Anteil von Software-Entwicklern mit fehlender oder nur geringer Berufserfahrung bemerkbar.
In immerhin 28 Prozent der untersuchten Projekte setzten sich die Projektteams überwiegend aus Berufsanfängern zusarnmen, in weiteren 35 Prozent machten diese einen beträchtlichen Teil aus und nur in 37 Prozent konnte überwiegend auf erfahrene Entwickler zurückgegriffen werden - mit großen Unterschieden in Anwenderunternehmen und Softwarehäusern: In 43 Prozent der Projekte in Softwarehäusern kamen überwiegend Berufsanfänger zum Einsatz, in Anwenderunternehmen nur 16 Prozent.
Die Notwendigkeit zur raschen Qualifizierung und Integration von Entwicklern mit geringer Berufserfahrung hat in zahlreichen Projekten die Gestaltung der Arbeitsteilung wesentlich bestimmt.
Die starke qualifikatorische Komponente der Entstehung der Arbeitsteilung in den Projektteams dürfte nicht zuletzt mit dafür verantwortlich sein, daß in den untersuchten Projekten auch stärker arbeitsteilige Organisationsformen relativ selten wirklich kritisch bewertet wurden.
Weniger qualifizierte und stärker durch Routine geprägte Tätigkeiten wurden meist eher als Durchgangsstationen eines persönlichen Entwicklungsprozesses begriffen und daher zumindest für einen begrenzten Zeitraum erträglich. Dort, wo sich die Arbeitszuweisung dauerhaft verhärtet hatte, wurden stärkere arbeitsteilige Projektstrukturen auch deutlich kritischer bewertet. Dies war jedoch eher die Ausnahme.
Für die zukünftige Entwicklung wird von großer Bedeutung sein, wie sich der Einsatz neuer Methoden und Instrumente in der Software-Entwicklung auf diese Offenheit auswirken wird. In den untersuchten Projekten waren hier Auswirkungen auf die Arbeitsteilung und die Arbeitszuweisung in den Projektteams noch kaum zu erkennen. Auch von unseren Gesprächspartnern wurden solche Auswirkungen fast durchweg gering veranschlagt.
Die nächste Folge dieser Serie erscheint unter dem Titel "Schlüsselpositionen: ein ausschlaggebender Leistungsfaktor". (wirdfortgesetzt)
Literatur: F.C. Brodbeck, S. Sonnentag, T. Heinbokel, W. Stolte, M. Frese: Tätigkeitsschwerpunkte und Qualifikationsanforderungen in der Software-Entwicklung. Manuskript, Veröffentlichung in Vorbereitung.
W Hesse: Neues Denken in der Softwarewelt. Manuskript, Veröffentlichung in Vorbereitung.
Professor Friedrich Weltz ist Geschäftsführer der Sozialwissenschaftlichen
Projektgruppe, München, und Honorarprofessor an der Universität Göttingen; Rolf Ortmann ist Mitarbeiter der Sozialwissenschaftlichen Projektgruppe, München.