Software-Projektmanagement im Teamwork Für Software, Mitarbeiter Grundgehalt plus Leistungszulage?

10.10.1975

MÜNCHEN - Software-Erstellung nach dem Top-Down-Prinzip (Hierarchische Modularisierung) erfordert organisatorische Konsequenzen im Projektmanagement. Softlab-Manager Dr. Gerhard Heldmann (36) befürwortete auf einem Softlab-Seminar über "Moderne Software-Technologie" in München zur Planung und Erfolgskontrolle funktionale Projekt-Teams nach dem Chief Programmer Team-Konzept.

Hinter dem so elegant über Lippen rollenden Jargon verstecken sich wechselnde, Gruppen von Softwarespezialisten, die sozusagen um ein Projekt herum angeordnet werden und zu seiner Erledigung jeweils genau umschriebene Teilaufgaben - eben in sich abgeschlossene Module gemäß Top-Down-Design - übernehmen.

"Projekt-Teams sind eine Arbeitsform, die man aus anderen Bereichen längst kennt", erläutert Heldmann, "im Softwarebereich stießen wir auf Schwierigkeiten. Softwarespezialisten empfinden als Künstler und Alleingänger. Wir brauchen einen neuen Mitarbeiter-Typ: den Software-Ingenieur. Wir wollen weg vom persönlichen Software-

Stil."

Manpower allein genügt nicht

In der Feststellung steckt Dynamit, aber auch viel Dynamik, Ein Projekt-Team kann bestehen aus Projektleiter (Chefprogrammierer), Projekt-Assistent (Backup Programmierer), Projekt-Sekretär (zentrale Kommunikationsschnittstelle zwischen Rechner und Team sowie Programm-Bibliothekar) und Programmierer (Junior-Programmierer). (In Anlehnung an H. D. Miller und F. T. Baker, USA.)

Ein Team - so die Heldmann-Erfahrung bei Softlab und Siemens - sollte acht bis zehn Programmierer enthalten. Mehr Manpower bringt nämlich keineswegs mehr Effekt: ein Teil der theoretischen Leistung wird durch Querkommunikation verschlissen. Bei fünf Personen gibt es zehn mögliche bilaterale Kontakte bei zehn Personen bereits 45 Beziehungen. Schon gar nicht hilft die nachträgliche personelle Aufstockung eines Teams, um etwa Termine noch zu retten. Das erkannte schon F. P. Brooks, IBM-Manager für das 360-Software-Projekt, und stellte fest: "Adding manpower to a late Softwareproject makes it later."

Große Projekte - mehrere Teams

Große Projekte erfordern deshalb nicht größere Teams, so Heldmann, sondern die Aufteilung des Gesamtprojektes auf verschiedene Teams, die durch einen Projectmanager koordiniert Werden. Der Projektmanager hat eine weitere wichtige Funktion: er entlastet die Projektleiter/Teamleiter von den Management-Aufgaben, die administrative Arbeit nimmt ihnen ohnehin der Projektsekretär ab.

Nun liegt die Annahme nahe, Softwaremitarbeiter mißbilligten das Chief Programmer Team Konzept. Denn immer die gleichen Leute könnten Projektleiter werden, immer die gleichen Assistenten und Sekretäre, immer die gleichen unterpriviligierten Programmierer, die sich nach Top-Down-Methode beispielsweise für die systemnahen Module zu reinen E/A-Spezialisten (und sonst gar nichts) entwickeln.

Funktionen können wechseln

"Das ist falsch", meint Dr. Heldmann, "die Zusammensetzung der Teams kann und soll projektbezogen wechseln. Wer im Team A Chefprogrammierer war, arbeitet im Team B vielleicht als nachgeordneter Programmierer und umgekehrt. Denn es geht um Funktionen im Team, nicht um Rangstellungen im Unternehmen."

Grau ist alle Theorie, praktisch wird es, spätestens bei der Bezahlung der Team-Mitglieder. Da könnte ein ganz neues Entlohnungs- und Prämiensystem entstehen. Zum Beispiel: alle Mitarbeiter im Softwarehaus oder in der Softwareabteilung werden mit Basisgehältern ausgestattet, denen projektbezogen und gemessen am der Wichtigkeit der jeweils übernommenen Funktion Leistungsprämien zugeschlagen würden. "Das käme ja auch der Tatsache entgegen, daß es fest umschriebene Berufsbilder im Softwarebereich eigentlich gar nicht gibt", kommentiert der Team-Ideologe.

So sind denn auch die "Adressen" der Team-Mitglieder nicht eigentlich Berufsbezeichnungen, sondern lediglich auf das Projekt bezogene Funktionsbeschreibungen.

Funktion nicht gleich Beruf

Der Projektleiter/Chefprogrammierer erarbeitet Projektplan und Design für das Gesamtsystem und seine modulare Gliederung, programmiert den Systemkern selbst und definiert die Systemkomponenten. Der Projektassistent unterstützt ihn darin und ist sein Stellvertreter - verfügbar wenn der Team-Chef ausfällt. Der Sekretär ist verantwortlich für die Projektbibliothek einschließlich aller Routine- und Verwaltungsarbeiten. Er erfaßt die Daten für die Kontrolle des Projektfortschritts und ist zuständig für Berichte und Dokumentationen. Die Programmierer programmieren Systemkomponenten nach Vorgabe.

"Im Grunde keine neuen Berufe", stellt Dr. Heldmann fest, "aber doch neue andere Qualifikationen, die man von Softwaremitarbeitern erwarten muß: die Bereitschaft, auf Solo-Tänze zu verzichten und sich dem Team und seiner gemeinsamen Aufgabe unterzuordnen."

Wirklich sinnvoll - dann sogar unabdingbar - ist diese Organisationsform, wo Systeme nach dem Prinzip der Hierarchischen Modulisierung entwickelt und diese Module strukturiert programmiert werden.