Programmierergehälter: Nach Gusto des DV- Chefs?

15.08.1980

Bei der Bewertung von Programmierer-Leistungen stehen für Peter Ostermeyer, Leiter DV/Org. beim Hamburger Adreßbuchverlag, Engagement und Berufserfahrung an erster Stelle. Es wäre unsinnig, erklärt auch Hydac-DV-Chef Horst Wahlen, für die Beurteilung eines "Softwerkers" die Anzahl der kodierten Zeilen oder Tests heranzuziehen, da diese von Faktoren abhängig seien, die dieser nicht zu vertreten habe. Wahlen meint, daß die Leistung eines Programmierers nicht meßbar sei und deshalb vom Vorgesetzten zumeist subjektiv beurteilt werde: "Dabei spielen sowohl Emotionen als auch die Gewichtung bestimmter Eigenschaften eine Rolle, die wiederum nur die Vorliebe des DV-Chefs widerspiegeln." Außerdem gibt Wahlen zu bedenken, daß sich Programmierergehälter inzwischen weniger an der effektiven Leistung orientieren. Stöhnt der erfahrene DV-Mann: "Der Markt diktiert, was gezahlt werden muß." ha

Peter Ostermeyer

Leiter DV/Org, Hamburger Adreßbuchverlag, Dummrath & Fassnach KG, Hamburg (Siemens 7.748, 7.531 - BS2000)

Unserer Meinung nach ist eine objektive Leistungsmessung bei reinem Programmieren individueller Anwenderprogramme nicht möglich. Die Zeit des Nur-Kodierers ist heute vorbei. In unserem Unternehmen werden deshalb Mitarbeiter sowohl für Organisation, Programmierung, Tests und Systemanalyse als auch für die Koordination und Schulung in den Fachbereichen eingesetzt.

Selbstverständlich gibt es auch bei uns nicht den Allround-Mann der all diese Gebiete perfekt beherrscht. Vielmehr ergeben sich die Schwerpunkte der einzelnen Mitarbeiter im Rahmen der praktischen Arbeit.

Die Leistung eines einzelnen Programmierers kann man weniger anhand der zu erledigenden Aufgaben, als vielmehr am erkennbaren Engagement messen. Bei der Festsetzung von Gehältern gehen wir aber auch im wesentlichen von der bisherigen Berufserfahrung aus. Ein Mitarbeiter der zehn Jahre Praxis hat, wird generell besser bezahlt, als ein Newcomer, der direkt von der Hochschule kommt.

Einfacher ist es, die Leistung einer gesamten Crew zu bemessen. Denn schließlich arbeitet nicht nur eine Person an einem Projekt, sondern die Arbeiten fließen ineinander über. Im Nachhinein kann man zwar die Fehler erkennen, aber konkret zu beurteilen, wo ein Programmierer innerhalb eines Projektes Schwächen oder Stärken hatte, liegt nicht im Sinne einer Beurteilung. Entscheidend ist letztendlich vor allem die Qualität des erstellten Produktes.

Bei uns wird nicht das reine Programmieren vorrangig eingeschätzt, sondern die Schwerpunkte liegen bei der Vorgabe eines Problemes. Das heißt, wenn die Vorgabe schlecht ausfällt, fällt auch dementsprechend schlecht das Programm aus. Die Schuld liegt dann aber nicht am Programmierer, sondern an den Leuten, die das Problem definiert haben.

Jürgen Meyer

DV-Leiter, Jos. Hansen & Söhne Außenhandels-Gesellschaft mbH, Hamburg (IBM/34)

Bei einem Programmierer kann man nicht die gleiche qualitative Beurteilung erstellen, wie bei einem normalen Sachbearbeiter. Allein die Aufgabenvielfalt läßt eine schemenhafte Arbeitsqualitätsmessung nicht zu.

Hinzu kommt, daß andere Abteilungen die Programmiereraufgaben erheblich erschweren. Dies beginnt bereits bei der Problemanalyse, indem die Fachbereiche nicht in der Lage sind, ihre gewünschte Lösung zu definieren. Auch beim Programmtest fehlt meist die Unterstützung der Fachabteilungen. Der Programmierer ist somit gezwungen, selbst Testdaten zu erstellen, die dann nur auf kritische Programmteile ausgerichtet sind. Fehler bleiben meist unentdeckt, da der Softwaremann nicht gleichzeitig die erforderlichen Fachabteilungskenntnisse besitzt.

Erst wenn der DV-Leiter zeitlich die Möglichkeit hat (was sehr selten vorkommt), an der Problemanalyse mitzuwirken, lernt er objektiv die Arbeit und die Leistung des Programmierers einzuschätzen. In diesem Rahmen spielt auch die Möglichkeit des Delegierens eine wichtige Rolle. Der Beurteiler sollte wissen, wie hoch der Unterstützungsgrad durch den Fachbereich bei der Realisierung eines Problemes war; präzis: Ob der Zeitbedarf des Programmierers auf eigene Schwächen oder auf mangelnde Hilfestellung zurückzuführen ist.

Auch die Zeit nach der Freigabe des Programmes muß in eine Beurteilung einbezogen werden. Erst später zeigt sich, ob Fehler auf mangelhafte Problemanalyse zurückzuführen sind, die der Programmierer bei ausreichender Sach-, Branchen- oder Firmenkenntnis hätte abfangen können. Handelt es sich um einen relativ neuen Mitarbeiter, müssen speziell hier bei der Leistungsbemessung selbstverständlich Abstriche gemacht werden.

Bei externen Programmierern ist eine Beurteilung generell einfacher. Es besteht ein Zwang zur detaillierten Vorgabe, bezogen auf eine Person, die besser einzuschätzen ist, als eine Problemstellung, an der ein gesamtes Team mitwirkt.

Ein guter Programmierer sollte auch daran gemessen werden, ob er in der Lage ist, bei der Lösung eines Problemes mit der vorhandenen Hardware auszukommen, also Kosten zu sparen. Bereits nach der Problemanalyse sollte er wissen, ob eine Aufstockung der Hardware erforderlich ist. Hinzu kommt der Aspekt des Handlings. Allein die Art, wie ein Softwerker die Durchführungsphase, den späteren Dateiaufbau oder den Dateizugriff, plant, läßt Rückschlüsse auf seine Qualitäten zu.

Durch die derzeitige Kostensituation gewinnt der Aspekt der Termintreue verstärkt an Bedeutung. Ein Programmierer sollte seine Termine zwar einhalten, sie aber gezielt planen und mit einem "Sicherheitszuschlag" versehen, weil oftmals erst in der Test- und Programmierphase Detailprobleme erkannt werden, die erhebliche Änderungen oder gar einen Neuanfang bewirken können.

Das beste Beurteilungskriterium ist immer noch die Einsatzbereitschaft. Speziell im Programmiererjob läßt sich relativ schnell erkennen, ob ein Mitarbeiter engagiert ist" denn es gibt Probleme en gros, die weder Aufschub dulden, noch in der regulären Arbeitszeit zu erledigen sind.

Horst Wahlen

DV-Leiter, Hydac Gesellschaft für Hydraulik GmbH, Sulzbach (Siemens 7.722, BS 1000)

Bevor- sich die Frage nach einer objektiven Leistungsmessung von Programmierern stellt, muß vorerst definiert werden, worin die Leistung eines Programmierers überhaupt besteht. Sind es lediglich die üblichen Routineaufgaben wie das Erstellen eines Ablaufplanes, das reine Kodieren, das Testen oder nur das Erstellen einer Dokumentation?

Allein die Gesamtheit dieser Aufgaben reicht nicht aus, um zu einer korrekten Leistungsbeurteilung zu kommen. Es wäre sicherlich unsinnig, die Anzahl der kodierten Zeilen oder Tests für eine Bewertung heranzuziehen, da diese von gänzlich anderen Faktoren abhängig sind, die keineswegs der Programmierer allein zu verantworten hat. Hier spielt sowohl das Operating. als auch die Datenerfassung eine nicht zu unterschätzende Rolle.

Wichtige Voraussetzungen für die Arbeit der Programmierer sind schnelles Auffassungsvermögen, logisches Denken sowie selbständiges Arbeiten und Durchschaubarkeit der Aufgabenstellung. Diese Faktoren sind die wichtigste Grundlage für die Leistungsbemessung.

Da Arbeitseinheiten wie Länge, Größe oder Gewicht, die in anderen Berufen maßgeblich sind, beim Software-Job absolut keine Bedeutung haben, besagt dies im Prinzip, daß die Leistung eines Programmierers nicht objektiv meßbar ist. Sie wird in der Regel vom Vorgesetzten, meist vom zu ständigen DV-Leiter, subjektiv gemessen. Dabei spielen nicht selten Emotionen oder die Gewichtung bestimmter Eigenschaften eine Rolle, die wiederum nur eine Vorliebe des DV-Chefs widerspiegeln. Fazit: Programmier-Leistung wird nicht gemessen, sondern "nur" beurteilt.

Meßbar ist zwar die Laufzeit eines Programmes, meßbar wiederum ist aber nicht, ob es sich dabei um die effektiv optimale Laufzeit handelt.

Es ist zwar durchaus möglich, die tatsächlichen Leistungen eines Programmierers zu ermitteln, indem mehrere Mitarbeiter gemeinsam an einem Projekt beziehungsweise am gleichen Programm arbeiten - aber wer kann sich das schon leisten?

Im Nachhinein läßt sich immer problemlos feststellen, ob ein Programm überhaupt läuft, ob es fehleranfällig oder gar fehlerfrei ist. Die Dokumentation gibt zusätzlich Auskunft, ob das Programm für einen Dritten brauchbar ist. Aber dann ist es für eine Rüge meist zu spät - und der Programmierer hat eventuell schon einen neuen Job.

Bei all diesem Argumentations-Hick-Hack stellt sich generell die Frage, warum die Leistung eines Programmierers eigentlich gemessen werden sollte. Der Grund für derartige Beurteilungen liegt meist in der Festsetzung eines Gehaltes. Aber gerade in diesem Punkt sind wir Datenverarbeiter bereits so weit, daß sich Programmierer-Gehälter nicht allein an der tatsächlichen Leistung orientieren, sondern daß uns vielmehr der Arbeitsmarkt die zu zahlenden Summen diktiert.

Bei der Neueinstellung eines Programmierers lassen sich zwar Angaben über die bisherigen Erfahrungen sowie über "angebliches Können" ins Kalkül der Beurteilungs-Überlegungen einbeziehen. Diese sind jedoch nur begrenzt nachprüfbar, so daß immer eine Dunkelschwelle verbleibt. Übrig bleibt also nur, welche Programmiersprachen der Neuling beherrscht, welche Ausbildung er genossen hat und durch welche Bereiche seine bisherige Tätigkeit führte. Diese raren Ansatzpunkte bilden jedoch noch keine Grundlage für eine qualifizierte und objektive Bewertung.