Maximilian Wieland, EDV-Chef in München

Wenn man den zahlreichen Veröffentlichungen, die sich mit dem

Chief-Programmer-Team befassen, glaubt, dann wurde die Idee des

Chief-Programmer-Team geboren anläßlich eines Großprojekts bei der New York Times, gemeinsam getragen von der IBM und der New York Times.

Das Chief-Programmer-Team bietet sich an im Zusammenhang mit dem Strukturierten Systemdesign, denn so können den Teammitgliedern klar definierte und begrenzte Aufgaben zugewiesen werden. Der Verantwotungsbereich ist ebenso klar zu umreißen. Jedes Teammitglied wird entsprechend seinem Können eingesetzt, und der Gesamtüberblick ist durch den Chief-Programmer und dessen Stellvertreter gewährleistet.

Treffen wir eine ähnliche Situation aber auch beim mittelgroßen Anwender und seiner Verfahrensentwicklung an? Gelten hier die gleichen Kriterien oder liegen die Verhältnisse wesentlich anders?

Betrachten wir zunächst die Historie der Verfahrensentwicklung. Zur Zeit der Lochkartenmaschinen und der 2. EDV-Generation gab es den Allround-Datenverarbeiter, der von der Istaufnahme über Systementwurf, Programmierung, Test, Arbeitsvorbereitung bis zum Operating alles machte. (Wir finden ihn bei kleineren Anwendern mit MDT-Anlagen auch heute noch.)

Eine echte Arbeitsteilung ergab sich häufig erst mit der Einführung der 3. EDV-Generation. Die Verfahrensentwicklung bestand dann aus Organisations-Programmierern oder aus Systemanalytikern und Programmierern oder auch aus einer Mischung aus diesen Funktionen. Die Schnittstellen zwischen Systemanalyse und Programmierung waren nicht selten verschwommen.

Oft war es weniger eine Frage der Stellenbeschreibung als vielmehr der individuellen Fähigkeiten, welche Tätigkeit ein Mitarbeiter gerade ausübte. d.h., ob er etwa von der Istaufnahme bis zur Systemübergabe an das RZ alles allein machte oder ob er vielleicht nur ein Glied dieser Funktionskette war.

Eine Notwendigkeit, Die einzelnen Funktionen sauber abzugrenzen und damit auch den Tätigkeits- und Verantwortungsbereich festzulegen, wurde vielfach erst in jüngerer Zeit gesehen. Dabei war es dann nicht überall leicht, gewachsene Privilegien, Pseudohierarchien und selbst ernannte "Teams" abzubauen und dafür die Verfahrensentwicklung klar zu gliedern, z. B. in Systemanalyse - Anwendungsprogrammierung - Systempflege.

Selbst dann, wenn alle Beteiligten guten Willens waren, konnte es noch Monate und Jahre dauern, bis die Schnittstellen zwischen diesen Bereichen wirklich deutlich genug herausgearbeitet waren und bis die Zusammenarbeit in der erwünschten Form funktionierte. Dabei ist zu bedenken, daß organisatorische Änderungen dieser Art stets Unruhe, ja Unsicherheit in den Arbeitsablauf bringen und sich immer in der ersten Phase fast nur nachteilig auswirken.

(Es gibt auch Fälle, in denen aus sachlichen oder persönlichen Gesichtspunkten die Verfahrensentwicklung nicht sauber getrennt wurde. Dort gibt es immer noch Organisationsprogrammierer, aber daneben auch Systemanalytiker, Programmierer, Kodierer.)

Nach dieser Vorgeschichte steht uns jetzt, kaum daß wir uns an die Organisation des EDV-Bereiches gewöhnt haben, als neue Organisationsform der Verfahrensentwicklung das

Chief-Programmer-Team ins Haus.

Sollen wir erneut alles umkrempeln? Sollen wir Systemanalytiker und Anwendungsprogrammierer jetzt zu Chief-Programmern,

Chief-Programmer-Stellvertretern, Senior- und Junior-Programmierern umfunktionieren?

Ich meine, wir sollten uns zuerst überlegen, was dem mittelgroßen, kommerziellen Anwender das

Chief-Programmer-Team letzten Endes bringt und wann und wo er es überhaupt einsetzen kann. Welche Aufgaben stehen denn an?

a) Wir müssen die bestehenden Programme warten.

b) Wir entwickeln Programme und kleinere Systeme.

c) Wir entwickeln größere Systeme.

Zu a) nützt uns am meisten derjenige

Systemanalytiker/Programmierer, der das Programm entwickelt programmiert hat. Ein Chief-Programmer-Team einzusetzen wäre hier unsinnig - auch dann, wenn es sich um größere Änderungen handelt. Diese Arbeiten nehmen nun leider einen ganz großen Teil unserer Kapazität in Anspruch.

Bei b) handelt es sich um Programme, die, etwa im Anschluß an bestehende Systeme, als Ergänzungs- oder Auswertungsprogramme, als Diagnose- oder Berichtigungsprogramme oder ähnliches konzipiert sind. Auch dazu brauchen wir kein Chief-Programmer-Team, zumal dies zeitlich überblickbare Arbeiten für einen oder zwei Mitarbeiter sind.

Bleibt also c) als Anwendungsfall für das

Chief-Programmer-Team. Welche Mitarbeiter können sich diesen - von interessierten und dynamischen Fachleuten generell

angestrebten - Tätigkeiten wirklich von widmen? Wer also könnte Mitarbeiter in einem Chief-Programmer-Team werden, um dort ausschließlich, zeitlich also kontrollierbar und disponierbar, tätig zu sein? Was geschieht mit all den anderen Mitarbeitern, die diesen Vorzug nicht genießen? Bleiben sie in der Systemanalyse oder Anwendungsprogrammierung? Was machen wir mit den Mitarbeitern des Chief-Programmer-Teams, wenn das Projekt abgeschlossen ist? Werden sie wieder in die Systemanalyse/Programmierung

eingegliedert? Wenn ja, wie? Wer wartet dann das vom

Chief-Programmer-Team entwickelte System? Welche Zuständigkeit haben der Leiter der Systemanalyse und der Programmierung für das Projekt

1. personell

- während der Projektentwicklung

- nach der Projektentwicklung

2. fachlich

- während der Projektentwicklung

- nach der Projektentwicklung

Viele Fragen, die Unklarheit, Personalprobleme und Fehlerquellen schaffen und die letzten Endes geeignet sind, die sprichwörtlichen Projektphasen "Bestürzung-Chaos" tatsächlich herbeiführen.

So effektiv ein Chief-Programmer-Team im geeigneten Fall auch zu wirken vermag, so wenig paßt es - zumindest heute noch - in die

EDV-Personal-Struktur beim kommerziellen Anwender. (Es sei denn, die Verfahrensentwicklung existiert noch als eine Gruppe unterschiedlich qualifizierter Mitarbeiter. Dann ist es leichter, für ein Projekt ein

Chief-Programmer-Team zusammenzustellen. Es bleibt aber doch eine Menge der aufgezeigten Probleme bestehen.)

Der Verzicht auf das Chief-Programmer-Team braucht freilich nicht zu bedeuten, daß sich der Anwender nicht wesentlicher Elemente der Arbeitsweise des Chief-Programmer-Teams bedienen sollte. So ist es ohne Zweifel richtig, Projektteams auf fachlicher Grundlage bei Systemanalyse und Programmierung unter Projektleitern zu bilden und die Gesamtaufgabe in überschaubare Moduln aufzuteilen, um mehrere Mitarbeiter parallel einzusetzen.

Für EDV-Hersteller oder Software-Anbieter, die mit großen neuen Projekten betraut werden und die nun ausschließlich dafür eine Gruppe von Mitarbeitern abstellen (vielleicht auch zusammen mit Mitarbeitern des Auftraggebers), erscheint jedoch das

Chief-Programmer-Team wie eingangs schon gesagt, als logische und, in Verbindung mit der Strukturierten Programmierung, folgerichtige Form der Projektorganisation.