Ein neues Projekt bringt für die Entwickler oft beträchtliche Lernanforderungen. Sie werden in einem - meist recht effektiven - Prozeß bewältigt, in dem Wissensaneignung sowie die Übernahme und Bewältigung von Aufgaben eng verschränkt sind.
Die Entwicklung von Software erfordert fast durchweg die Aneignung von zusätzlichem Wissen, für die früher Gelerntes oder gemachte Erfahrungen keine ausreichende Grundlage bilden. Die rasche Fortentwicklung der verfügbaren Hard- und Software verändert ständig die Gestaltungsparameter für Software-Entwicklungen. Es existieren bisher unbekannte Möglichkeiten, aber zugleich auch Restriktionen, die berücksichtigt werden müssen.
Wissensanforderungen ergeben sich auch aus dem jeweiligen Anwendungsfeld der Software, das sich seinerseits in ständiger Veränderung befindet. Erweiterung der Kenntnisse ist nicht nur dort erforderlich, wo in ein neues Anwendungsfeld vorgestoßen wird, sondern selbst auf vertrautem Terrain. Wissensaneignung muß also ständiger Teil der Arbeit in der Software-Entwicklung sein und macht tatsächlich auch einen nicht unbeträchtlichen Anteil der Arbeitszeit aus.
So gaben die Entwickler in der Befragung des arbeitspsychologischen Teilprojekts an, 22 Prozent ihrer Arbeitszeit habe mit Lernen zu tun; bei den Projektleitern waren es sogar 25 Prozent (Brodbeck 1991). Die Notwendigkeit der ständigen Anpassung des eigenen Wissensstandes wird als mehr oder minder selbstverständlicher Aspekt der beruflichen Tätigkeit gesehen. Dies gilt nicht zuletzt für jene Entwickler, die erst im Laufe ihrer Berufstätigkeit zur Software-Entwicklung gekommen sind, indem sie sich häufig Schritt für Schritt im Zuge der jeweiligen Aufgabenbewältigung die notwendigen Kenntnisse erarbeiteten und damit erst sukzessive von ihrer alten Tätigkeit in die Software-Entwicklung hineinwuchsen.
Nur zu einem sehr geringen Teil fand dieses Lernen in Schulungsveranstaltungen statt, ganz überwiegend vollzog es sich im Rahmen der eigenen Arbeit, als Teil der Bewältigung von Aufgaben. Dieser Prozeß wäre mit Learning by doing nicht hinreichend beschrieben. Vielmehr handelte es sich um einen Doppelprozeß, in dem theoretisches Lernen und die jeweilige Aufgabenbewältigung miteinander verschränkt waren. Weil bestimmte Aufgaben zu bewältigen waren, wurden die erforderlichen Kenntnisse erworben. Umgekehrt bestimmten angeeignete Kenntnisse die Ausführung und häufig auch die Zuweisung neuer Aufgaben. Einmal erarbeitete Kompetenzen strukturierten die weitere berufliche Tätigkeit. Der Weg zum Spezialisten war dabei oft erstaunlich kurz.
In einem Forschungsinstitut übernahm einer der Wissenschaftler gewisse Vorarbeiten für ein Bibliothekssystem, ohne je mit der DV etwas zu tun gehabt zu haben, auch ohne vorher qualifiziert worden zu sein. Damit war seine Karriere und sein weiterer Aufgabenbereich vorbestimmt: Da er der einzige Mitarbeiter am Institut war, der sich mit DV-Systemen befaßt hatte, wurde er zum Spezialisten - "Der einzige Einäugige unter lauter Blinden" - für alle Fragen der DV. Als man im Institut ein Bürosystem einrichten wollte, wurde ihm die Aufgabe übertragen, dieses zu entwickeln und seine Einführung zu betreuen.
Dieses Verfahren aufgabenbezogener Wissensakquisition basierte meist auf einem Ineinanderwirken individueller Eigeninitiative und weitgehend informeller Unterstützung durch den Projektleiter und die Kollegen. Nur in einigen überwiegend sehr großen Unternehmen trafen wir auf institutionalisierte Formen projektübergreifender Qualifizierung.
So erfolgte die Einweisung in die Projektarbeit überwiegend durch den Projektleiter: informell in 46 Prozent, stärker formalisiert in ebenfalls 46 Prozent der Projekte und/oder durch Kollegen. Nur relativ selten in einem Achtel der Projekte waren in diese Einweisung projektexterne Instanzen eingeschaltet.
Situation bei Anwendern und SW-Häusern ähnlich
Dem standen allerdings auch Berichte von Entwicklern gegenüber, denen umfangreiche und anspruchsvolle Aufgaben zugewiesen wurden und die man mit diesen über einen längeren Zeitraum alleinließ. Die meisten scheinen sich durchgebissen zu haben, aber das Risiko des Scheiterns eines solchen Verfahrens wurde immer wieder deutlich.
Inhaltliche Schwerpunkte dieser Einweisung waren das jeweilige Anwendungsgebiet (81 Prozent), Tools, Methoden, Entwicklungsumgebung etc. (72 Prozent) und die Ausführung der Projektarbeit (52 Prozent). Nur in 46 Prozent der Projekte wurde die Einarbeitungszeit gesondert kontiert, damit gab es einen fixierten Zeitraum, der für die Einarbeitung ausgewiesen war.
Die Situation in Anwenderunternehmen und Softwarehäusern unterscheidet sich dabei nicht grundlegend. In Softwareschmieden wird zwar die Einarbeitungszeit häufiger erfaßt und auch gesondert kontiert, der Grad der Formalisierung von Einweisung ist jedoch nicht wesentlich höher. Stärker dagegen unterscheiden sich große von kleineren Projekten durch die häufigere Formalisierung und Kontierung der Einweisung in die Projektarbeit wie auch durch deren inhaltliche Ausrichtung. Waren in Großprojekten vor allem Methoden, Tools etc. Gegenstand der Einweisung, so bezog sich die Information in kleineren Projekten primär auf das Anwendungsgebiet der zu entwickelnden Software.
Auch die Weiterbildung war wesentlich eine Frage der Eigeninitiative. Zwar gab es in etwa der Hälfte der Projekte Pläne, in deren Rahmen Weiterbildungsmaßnahmen in Anspruch genommen werden konnten, letztlich hing die Weiterbildung aber ganz oder weitgehend von der individuellen Initiative ab.
Dieses Verfahren der Wissensakquisition scheint überall dort bemerkenswert gut und effektiv funktioniert zu haben, wo eine entsprechende Eigeninitiative von den Entwicklern eingebracht und durch Hilfestellungen von Projektleitern oder Kollegen kontinuierlich gestützt wurde.
Das Verfahren dürfte sich nicht nur bei Aufgaben bewährt haben, für deren Bewältigung bereits Vorwissen und Erfahrungen im Team vorhanden waren, sondern auch bei neuartigen Aufgaben.
So wurde bei einigen Projekten berichtet, daß die Einarbeitung in eine neue Entwicklungsumgebung nicht viel Zeit beanspruchte; zwar habe man Lehrgeld gezahlt, dies sei aber im wesentlichen darauf zurückzuführen gewesen, daß die Besonderheiten und Defiziten der neuen Verfahren noch nicht bekannt gewesen seien. Hierbei wurde immer wieder die enorme Bedeutung der Integrationsfunktion des Projektleiters und des Kernteams erkennbar, der wir schon in anderem Zusammenhang begegneten.
Exemplarisch für eine solch projektinterne Einweisung ist die Darstellung eines Projektleiters: "wenn jemand neu in mein Projekt kommt, dann gebe ich ihm in den ersten paar Tagen Unterlagen, damit er sich zunächst einmal einlesen kann. Aber sehr rasch bringe ich ihn dann ans produktive Arbeiten, weise ihm Aufgaben zu, zuerst kleinere, dann langsam umfangreichere. Entscheidend ist aber, daß wir uns immer wieder zusammensetzen, mindestens einmal die Woche, und genau seine Arbeit durchgehen. Da sehe ich, wie weit er ist."
Dieses Verfahren der sehr kurzzyklischen Zuweisung produktiver Aufgaben und Ergebniskontrollen wurde von einer Reihe von Projektleitern offensichtlich recht konsequent und erfolgreich praktiziert. Erfolgreich war dieses Verfahren nicht zuletzt deshalb, weil meist zugleich auch kontextuelles Wissen vermittelt wurde:
- Erfahrungen und Hinweise, die den Umgang nachfolgender Bearbeiter mit der dokumentierten Software erleichtern können
- Erfahrungen und Kenntnisse, die bei der Anwendung von Instrumenten oder Verfahren erworben wurden,
- Erfahrungen, die mit den Auftraggebern beziehungsweise dem Anwenderbereich gemacht wurden, etwa über das Umfeld und die Einsatzbedingungen des Softwareprodukts oder auch Eigenarten und Qualifikationen einzelner Personen,
- Erfahrungen, die im Entwicklungsteam mit der Integration neuer, unerfahrener Kollegen gemacht wurden als Bezugspunkt für die Personaleinsatzplanung.
Kontextuelles Wissen, das erwies sich immer wieder, war für die Planung und Durchführung der Softwareprojekte von unschätzbarem Wert: bei der Wahl und Nutzung der Entwicklungsverfahren oder Instrumente, bei der Analyse der Entwicklung, bei der Festlegung der Spezifikationen und insbesondere bei der Planung sowie Kalkulation des Projektablaufs. Die Unterschätzung des notwendigen Entwicklungsaufwands in vielen Projekten ließ sich nicht zuletzt auch auf mangelnde Berücksichtigung von - durchaus vorhandenem - kontextuellem Wissen zurückführen. Es ist auch dieses kontextuelle Wissen, das den erfahrenen Software-Entwickler von dem Novizen unterscheidet.
Persönlich zugeschnittener fachlicher Horizont
So erklärte einer unserer Gesprächspartner die geringen Schwierigkeiten, die er im Vergleich zu jüngeren Kollegen im Umgang mit Anwendern habe, unter anderem aus den geringen Verständigungsschwierigkeiten. Er habe gelernt, Sachverhalte der Software in die Sprache der Anwender zu übersetzen. So sei anfänglich die schlichte Tatsache, daß der Begriff "Prozeß" für ihn und die jeweiligen Anwender sehr unterschiedliches bezeichnete, Ursache für manche Mißverständnisse und Schwierigkeiten.
Weniger tragfähig scheint sich das sehr personen- und aufgabenbezogene Verfahren bei der Wissensaneignung über das Anwendungsgebiet zu erweisen. Hier fehlten - insbesondere bei neuen Aufgabenbereichen - meist die kundigen Vermittler, oder sie waren mit anderen Aufgaben betraut und standen deshalb nicht zur Verfügung.
Als Muster zur Bewältigung der faktisch unbegrenzten Lernanforderungen kann die mehr oder minder enge Eingrenzung des fachlichen Sektors dienen, dem man Aufmerksamkeit widmete. Diese Eingrenzung, ihrerseits Ausdruck der aufgabenbezogenen Wissensakquisition, verstärkte natürlich die Gefahr einer Spezialisierung beziehungsweise eines sehr persönlich zugeschnittenen fachlichen Horizonts.
Die ausgeprägte Aufgabenbezogenheit der Wissensakquisition trug dazu bei, daß sich der Prozeß der Software-Entwicklung nicht selten recht konfliktträchtig gestaltete. Die enge Verschränkung von Wissen und Aufgabe führte verständlicherweise nicht nur zu einer ausgeprägten Identifikation mit der eigenen Aufgabe, sondern auch mit der jeweiligen technischen Lösung. Umgekehrt konnte dies heißen: Neue technische Ansätze wurden als Gefährdung der eigenen beruflichen Situation erfahren, durch die das eigene Fachwissen entwertet und damit der betriebliche Status gefährdet werden konnte. Immer wieder begegneten wir in den Projektabläufen Auseinandersetzungen, die nur im Zusammenhang mit solch existentiellen Gefährdungen zu verstehen waren. Solche Blockierungen machten sich vor allem dann bemerkbar, wenn Änderungsimpulse von außen in das Projekt hineingetragen wurden.
Auch die Personengebundenheit trug zur Akzentuierung der Problematik bei. In vielen Unternehmen war die Einführung neuer Methoden und Instrumente an die Einstellung von externen Fachleuten gebunden, die über entsprechende Kenntnisse verfügten. Dieses Vorgehen nach dem Prinzip "Neue Technik, neue Gesichter" hat in einer Reihe von Projekten innovatorische Prozesse in starkem Maße mit persönlichen Auseinandersetzungen belastet. Eine besondere Note erhielten diese Konflikte, wenn es sich bei den Neuen um Studienabgänger handelte. Die überlegene Praxiserfahrung der "Alten" wurde durch die Kenntnisse neuer Methoden der "Neuen" gefährdet. Eine Frontenbildung war damit programmiert.
Damit sind die Stärken und zugleich auch die Grenzen dieses Verfahrens aufgezeigt. Es ist nicht nur auf Eigeninitiative, sondern auch auf die Verfügbarkeit von Unterstützung angewiesen. Fehlt diese, dann ist meist auch die Eigeninitiative überfordert oder geht verloren.
Wenig Zeit für Unterstützung der Entwickler
So schieden in einem Projekt von vier neueingestellten Entwicklern zwei nach relativ kurzer Zeit wieder aus, weil sie sich weitgehend allein gelassen und überfordert fühlten. Der Projektleiter und sein Stellvertreter waren primär mit der Vertretung des Projekts nach außen sowie mit der Ausarbeitung des Gesamtdesigns befaßt und, hatten für die Unterstützung der Entwickler bei der Bewältigung der ihnen zugewiesenen Teilaufgaben nur wenig Zeit.
In den meisten Fällen scheint das Verfahren aufgabenbezogener Qualifizierung in den meisten Projekten jedoch recht gut funktioniert zu haben. Dort, wo neuartige Entwicklungsaufgaben relativ rasch bewältigt werden konnten, ließ sich dies nicht zuletzt der Wirksamkeit des Qualifizierungsverfahrens zurückführen.
Gleiches gilt für die rasche Eingliederung neueingestellter Entwickler ohne einschlägige Erfahrungen. Allerdings war das Verfahren aufgabenbezogener Qualifizierung auch mit beträchtlichen Belastungen für die Entwickler verbunden und trug zweifelsohne zu dem Gefühl hoher Beanspruchung bei, das immer wieder zum Ausdruck kam.
Zwiespältigkeit bei älteren Entwicklern
In den meisten der von uns mit Entwicklern geführten Gespräche äußerten sich diese zwar erstaunlich gelassen bezüglich der Bewältigung der sich ihnen stellenden Lernanforderungen. Nur relativ selten wurde das Gefühl der unmittelbaren Überforderung artikuliert. Bei einem Teil der älteren Entwickler, mit denen wir uns über dieses Thema unterhielten, war hier jedoch Zwiespältigkeit zu spüren. Einerseits kam durchaus ein beträchtliches Selbstbewußtsein und Vertrauen in die eigene Tätigkeit zum Ausdruck: Neue Qualifikationsanforderungen seien zu bewältigen. Andererseits war auch Sorge um die längerfristigen Aussichten zu spüren, Zweifel, ob man auf Dauer werde mithalten können. Vor allem langfristig erscheint eine Ergänzung der aufgabenbezogenen Qualifizierung durch institutionalisierte Weiterbildung, für die auch zeitliche Freiräume ausgewiesen sind, notwendig. (wird fortgesetzt)
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, Gießen 1991.
* 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.
Serie: Das Softwareprojekt
In dieser Serie wird über eine Untersuchung berichtet, die die Autoren in und an 46 Softwareprojekten durchführten. Sie war soziologischer Teil des interdisziplinären Projekts zur Arbeitssituation in der Softwareentwicklung, das vom Bundesministerium für Forschung und Technologie (BMFT) im Rahmen des Programms "Arbeit und Technik" gefördert wurde. Das Teilprojekt "Informatik" lag in den Händen von Professor Dr. Wolfgang Hesse, ferner von Udo Bittner und Johannes Schnath, Universität Marburg; das Teilprojekt "Arbeitspsychologie" wurde bearbeitet von Professor Dr. Michael Frese sowie Felix C. Brodbeck, Torsten Heinbockel, Sabine Sonnentag und Wolfgang Stolte, Universität Gießen.
Die Studie erscheint in Buchform im Herbst 1992 im Campus Verlag unter dem Titel "Das Softwareprojekt - Projekt-Management in der Praxis".