Zusammenfassung
Bislang habe ich Programmierarbeit in einer Weise dargestellt, in der die Arbeitsstile vorwiegend als Resultat individueller Vennittlungsweisen zwischen Organisationstatbeständen, Arbeitsstofflichkeit und subjektiven Dispositionen erscheinen. Ebensowenig aber, wie Subjektivität sich in Individualität erschöpft, existieren Arbeitsstile als bloß individuelle, von sozialen Bezügen unabhängige Handlungsweisen monadengleicher Akteure. Die vor allem der Spezifik der Erhebungsform geschuldete bisherige Darstellungsweise sollte nicht den Blick auf die tatsächliche Gruppenbindung oder mindestens Gruppenbezogenheit von Arbeitsstilen verstellt haben. Wie etwa am besonders einprägsamen Beispiel der Informatikerin Ä. in ihrer Gruppe von Ingenieuren deutlich geworden sein sollte, ist die Gruppe, das Projektteam, der primäre Ort der Auseinandersetzung mit divergierenden Arbeitsanforderungen. Die hier als »subjektive Leistungen« besonders herausgestellten praktischen Vermittlungsleistungen der Arbeitenden werden zunächst und vor allem im Team hervorgebracht, sei es, daß dabei eine kollektive Verfahrensweise geprägt wird, wie in Ä.s Fall, sei es aber auch, daß Einzelne jeweils divergierende Stile etablieren: Diese entstehen, wie eine Fülle von abgrenzenden Bemerkungen in den zitierten Selbstdarstellungen belegen, in steter Auseinandersetzung mit den Praxen vor allem der unmittelbaren KooperandInnen.
This is a preview of subscription content, log in via an institution to check access.
Access this chapter
Tax calculation will be finalised at checkout
Purchases are for personal use only
Preview
Unable to display preview. Download preview PDF.
Literatur
In Frage kommen hier vor allem berufsbiographicanalytische Ansätze, deren Zahl und Elaboriertheit in den letzten zehn Jahren deutlich gewachsen ist (vgl. z.B. Hermanns u.a. 1984, Hoerning 1980, Voges 1987 ).
Dem Forscher, der nur eine dieser Gruppen untersucht, droht leicht die Gefahr des »going native«, der Überidentifikation mit der Informatlnnengruppe. Ich hoffe, dieser Gefahr nicht über Gebühr erlegen zu sein. Um Mißverstandnissen vorzubeugen, sei vorausgeschickt: Die Beschreibung der anderen betrieblichen Gruppen (z.B. Vertriebsmitarbeiterinnen) ist hier diejenige, die die Entwicklerinnen präsentieren - auf der Basis ihrer sehr subjektiven Er-kenntnisperspektiven und Retevanzstrukturen. Meine Darstellung versucht, die arbeitslogischen Motive und die »innerbetrieblichen Handlungskonstellationen« (Weltz/Lullies 1984) herauszuarbeiten, die eine solche Wahrnehmung des sozialen Umfeldes in der Arbeit befördern.
Es muß an dieser Stelle nachdrücklich darauf hingewiesen werden, daß hier jeweils subjektive Perspektiven in ihren verallgemeinerbaren Formen dargestellt werden; Perspektiven, die notwendig beschränkt sind. So ziehen W. und A. hier nicht in Betracht, welche Funktionen etwa die Repräsentationsrituale oder die Art der Kaufentscheidung für die - andernorts stattfindenden - Machtspiele in den beteiligten Organisationen haben. Zu Machtspielen bei der Informatisierung vgl. Ortmann u.a. (1990: 71f.).
C.C. hat guten Grund sich trotz seiner Projektleiter-Funktion nicht zum Management zu zählen, da er lediglich die fachliche Leitung inne hat, also keinerlei disziplinarische Funktionen, und überdies - wie er an anderer Stelle etwas verschmitzt anmerkt - auch in Fachfragen nur begrenzt souverän agieren kann: »… dann kann man ‘n bißchen mitwirken oder nicht. Meistens eich’.« (C.C./3) Die Trennung in fachliche und administrative Leitung von Projekten ist, wie Welz und Ortmann (1992: 51) feststellen, in der Softwarebranche verbreitet.
Diesen Begriff verstehe ich hier zunächst nicht als eine über das Feld der Programmierarbeit hinausgehende Generalisierung, allerdings klingt darin die Option an, daß die hier und in den folgenden Abschnitten mit diesem Begriff assoziierten Merkmale auch über dieses enge Feld hinaus im Bereich technisch-wissenschaftlicher Arbeit vorfindlich sein mögen - dies zu belegen erforderte indes weitere, vergleichende Untersuchungen.
Programmierarbeit ist nicht nur ein noch junger Typ von Arbeit, sie wird auch weit überwiegend von Jüngeren durchgeführt: Ab einem Alter von 35–40 Jahren sind Programmiererinnen in der Entwicklung kaum noch zu finden. Dies läßt sich nicht allein mit dem erst in den letzten 10–15 Jahren so recht boomenden Arbeitsmarkt erklären: Programmiererinnen hören häufig in diesem Alter mit der Programmierung auf und geben als Grund dafür Projektstreß und Kreativitätsdruck an.
Dieser Begriff wird hier verstanden als relativ zu den Gepflogenheiten von Geschäftswelt und betrieblicher Büroarbeit.
Für ein abschreckendes Beispiel vgl. Volpert (1985).
Dies belegen neben meinen eigenen Untersuchungen (Strühing 1987 und 1991), die Arbeiten von Friedrich Weltz u.a. (Weltz u.a. 1991 und Weltz/Ortmann 1992) sowie Brodbek u.a. (1992) für die deutsche Softwarebranche sowie die Arbeiten der Gruppe um Bill Curtis für die nordamerikanische Diskussion (Curtis u.a. 1988 und Krasner u.a. 1987: vgl. auch Abschnitt 5.1.3).
Sieht man von den an einer Hand abzuzählenden Ilochschulen mit Studienprojekten in der Informatikausbildung (z.B. TU Berlin) einmal ab.
Gleichwohl erleben die Befragten ihre relative Inkompetenz in diesem Bereich durchaus als Mangel, wie sich in der nennenswert häufigen Neigung. hei Weiterbildungsaktivitäten auf Rhetorik-Schulungen zuzugreifen, zeigt.
Zum »Opportunismus« als Gestaltungsprinzip von Entwurfstätigkeiten in der Programmierarbeit gibt es eine aktuelle Diskussion in der amerikanischen und französischen Kognitionsforschung (vgl. Guindon 1990, Visser 1987); dort wird indes nicht die Differenz betont, sondern eine verallgemeinerte Typik herausgearbeitet (Guindons Ansatz stelle ich in 5.1.3. kurz vor).
Zu diesem Interview gibt es kein Bandaufnahme, deshalb wird es hier paraphrasiert wiedergegeben.
Ein vergleichender Blick auf den Umfang von Normungen im Bereich des Maschinenbaus oder der Elektrotechnik einerseits und der Informatik andererseits könnte diesen Umstand verdeutlichen: In letzterer Disziplin existieren bei weitem weniger DIN-Normen oder vergleichbar verbindliche Standardisierungen.
In der angelsächsischen Diskussion über Arbeitsweisen und Fehlertypiken von Programmieranfängerinnen wird meist der Begriff (novice« mit all seinen auch klerikalen Konnotationen dem des »beginners« vorgezogen (vgl. z.B. Perkins/Martin 1986).
Ich will nicht unterlassen darauf hinzuweisen, daß in der Frage der Veralltäglichung die Metapher zumindest vom » Initiationsritua!« ihre Grenzen findet: Initialionen zeichnen sich in der Regel gerade durch durch ihren alltagsfernen Charakter und ihre periodische Veranstaltung aus - jedenfalls ist dies die Begriffsverwendung der Ethnologie (z.B. Erdheim 1984: 285f.). Die Soziologie ist hier etwas offener in der Fassung des Begriffs «Initiation«. So versteht das Wörterbuch der Soziologie (Endruweitffrommsdorf 1989: 305) darunter »im weitesten Sinne jede formal deutlich markierte Aufnahme in eine Gruppe, einen Verband oder eine Gemeinschaft der Erwachsenen«, die den «kritischen Wechsel zu veränderter Identität und neuem Status« gewährleisten soll. Ich habe versucht, den Alltagscharakter der hier beschriebenen Art von Initiation durch den Begriff des «Initiationsprozesses« stärker herauszustellen.
Rights and permissions
Copyright information
© 1993 Springer Fachmedien Wiesbaden
About this chapter
Cite this chapter
Strübing, J. (1993). Kollektiver Habitus — Stilisierte Gruppenidentitäten und ihre arbeitsstofflichen Bezüge in der Programmierarbeit. In: Subjektive Leistungen im Arbeitsprozeß. DUV Sozialwissenschaft. Deutscher Universitätsverlag, Wiesbaden. https://doi.org/10.1007/978-3-663-01637-3_4
Download citation
DOI: https://doi.org/10.1007/978-3-663-01637-3_4
Publisher Name: Deutscher Universitätsverlag, Wiesbaden
Print ISBN: 978-3-663-01638-0
Online ISBN: 978-3-663-01637-3
eBook Packages: Springer Book Archive