Wie kann es zu schlechter Produktvität kommen, obwohl alle Mitarbeiter für ihre Arbeit gut qualifiziert sind und ihre Arbeit gut erledigen?

Oft besteht die Überzeugung, dass wenn alle Mitarbeiter für ihre jeweilige Arbeit gut qualifiziert sind und alle Mitarbeiter Ihre Arbeit gut machen, auch das Projekt damit gut vorankommen würde. Leider ist dies ein großer und oft verhängnisvoller Irrtum.

Ein Softwareprojekt als Abtragen von Hügeln

Dieser Überzeugung liegt die (oft unbewusste) Vorstellung zugrunde, dass jeder der verschiedenen Aspekte eines Softwareprojektes (Anforderungsanalyse, Architektur, Design, Implementierung, Test, Dokumentation) mit einem Hügel gleichgesetzt werden kann, der abgetragen werden muss. Diese Vorstellung wird auch genährt durch Diagramme wie das in der nebenstehenden Abbildung. Man weiß, dass man für jeden Hügel Spezialisten benötigt (also z.B. Designer, Software-Entwickler, Tester etc.), aber implizit besteht die Vorstellung, dass jeder Mitarbeiter sozusagen an seinem Hügel arbeitet und sobald jeder seine Arbeit getan hat, d.h. seinen Hhügel abgetragen hat, ist das Softwareprojekt fertig.

Beispielsweise kann der immer wieder gemachte Versuch, ein Softwareprojekt zu beschleunigen, indem man mehr Mitarbeiter in das Projekt hineinbringt, auf diese Vorstellung zurückgeführt werden. Denn ein Hügel ist schließlich auch umso schneller abgetragen, je mehr Leute dabei mithelfen. Und wenn man diese Vorstellung zugrunde legt, ist es auch selbstverständlich, dass man der Überzeugung ist, dass jeder nur seine Arbeit optimal machen muss, damit das Softwareprojekt insgesamt schnell fertig ist. Leider ist ein Softwareprojekt jedoch komplexer.

Softwareprojekte als Bergbesteigung

Ein Softwareprojekt kann in mancher Hinsicht eher mit der Besteigung eines Berges verglichen werden, oft sogar mit einer Erstbesteigung. Auch dort kommt es nicht nur darauf an, dass jeder Mitarbeiter qualifiziert ist und jeder möglichst schnell vorankommt, sondern es kommt auch ganz wesentlich darauf an, dass der richtige Weg beschritten wird. Und wie in Softwareprojekten ist es auch dort oft schwer zu erkennen, welcher der vielen möglichen der richtige Weg ist.

Es gibt oft noch nicht einmal eine eindeutige Antwort auf die Frage nach dem besten Weg, selbst wenn man den Berg genau kennt. Denn je nach Fähigkeiten der beteiligten Personen mag entweder der einfache, aber von der Distanz her längere Weg der schnellere sein oder aber der schwierigere aber kürzere. Und wie bei Softwareprojekten macht es, sobald man eine ausreichend große Mannschaft zusammen hat, kaum Sinn, noch mehr Personen dem Team hinzuzufügen. Dadurch sind alle anderen nicht eher auf dem Gipfel, eher im Gegenteil, da man dann oft erst auf die Neuen warten muss, bis diese aufgeschlossen haben.

Beispiele für schlechte Produktivität trotz guter Arbeit

Einige Beispiele aus Softwareprojekten mögen erläutern, wie es kommen kann, dass der Projektfortschritt schlecht ist, obwohl alle ihre Arbeit gut erledigt haben.
Beispielsweise gibt es in Softwareprojekten oft die alternativen Wege, entweder bestimmte Architektur- und Designaspekte mit einem Prototypen zu testen, oder aber, sich diese Prototypen zu sparen und darauf zu vertrauen, dass man auftretende Probleme und Schwierigkeiten später während der Implementierung kurzfristig lösen kann. Falls man sich für die zweite Alternative entscheidet und sich später herausstellt, dass man ein auftretendes Problem doch nicht so einfach lösen kann, so ist oft ein erheblicher Teil der bis dahin geleisteten Arbeit verloren, was oft dem 10-100 fachen Aufwand für den Prototypen entspricht. Im Bild der Bergbesteigung würde dies bedeuten, dass man auf dem einen Weg plötzlich feststellt, dass sich dort ein unüberwindliches Hindernis auftut und man umkehren und doch einen anderen Weg nehmen muss.

Zweitens besteht jeweils die Alternative, das Design entweder bis ins letzte Detail (beispielsweise inklusive aller Methoden aller Klassen und ihrer Parameter) fertig zu stellen oder aber nur ein Grobdesign fertigzustellen (Klassen + wichtige Methoden) und das Feindesign im Zusammenhang mit der Implementierung zu erledigen. Im Bild der Erdhügel würde dies bedeuten, dass der eine Erdhügel (Design) kleiner, dafür der andere (Implementierung) größer wird. Dies wäre für sich genommen noch kein Problem. Aber leider ist es oft so, dass beispielsweise eine Einsparung von einem Tag beim Design leicht zu einem Mehraufwand von 10 Tagen bei der Implementierung führen kann. Auf der anderen Seite kann es genauso gut sein, dass zehn Tag Mehrarbeit beim Design noch nicht einmal einen Tag bei der Implementierung spart. Selbst wenn sowohl Designer als auch Programmierer für Ihre Arbeit hervorragend qualifiziert sind und ihre jeweilige Arbeit sehr gut machen, sind die verschiedenen Wege doch jeweils mit einem sehr unterschiedlichen Aufwand verbunden. Es gibt nur ein Optimum der Aufteilung zwischen Design und Implementierung. Jede Abweichung vom Optimum führt zu erheblichen Mehraufwänden und damit auch zu längerer Projektlaufzeit und höheren Kosten.

Wer ist verantwortlich für das Finden des Optimums

Leider ist dieses Optimum schwer zu bestimmen. Denn es gibt keine allgemeingültigen Regeln dafür, wie die Aufteilung sein sollte. Dies hängt erstens vom Projekt und der zu bewältigenden Aufgabe ab, zweitens aber auch von den beteiligten Personen, beispielsweise davon, inwieweit die Entwickler selbst das Feindesign erstellen können oder auch nur, ob Entwickler und Designer engen Kontakt haben oder womöglich sogar räumlich getrennt arbeiten. Daher kann im allgemeinen weder dem Entwickler noch dem Designer vorgeworfen werden, er hätte am Optimum vorbeigearbeitet. Diese müssen sich im allgemeinen an externe Vorgaben halten, beispielsweise den im Projektplan festgesetzten Terminen. Aber auch demjenigen, der den Projektplan erstellt hat, kann oft kein Vorwurf gemacht werden, da er zum Zeitpunkt der Erstellung gar nicht über alle notwendigen Detailinformationen verfügte, um dieses Optimum genau zu treffen.
Und so gibt es noch hunderte von Beispielen dafür, dass selbst in dem Fall, dass jeder im Projekt seine Arbeit vorbildlich erledigt, trotzdem der Gesamtfortschritt im Projekt wesentlich schlechter ist als er sein könnte. Daher ist die Aufgabe des Produktivitäts-Managements sicherzustellen, dass im Projekt jeweils der optimale Weg beschritten wird, der mit minimalem Aufwand und minimalen Kosten in kürzestmöglicher Zeit zum Ziel führt.

Daher wird entweder die Erstellung einer Produktivitätsanalyse oder (bei einem großen Projekt) die Einrichtung der Position eines Produktvitäts-Managers empfohlen, dessen Aufgabe es ist, in all diesen Fällen jeweils die optimalen Wege zu finden und aufzuzeigen, gegebenenfalls auch zeitnah. Diese Aufgabe kann auch vom technischen Projektleiter übernommen werden, sofern dieser noch über freie Kapazitäten sowie die nötigen zusätzlichen Kompetenzen in Hinsicht auf Bestimmung der Produktivität verfügt.

Weitere Beispiele dafür, wie es in Softwareprojekten passieren kann, dass die Gesamtproduktivität im Projekt schlecht ist, obwohl jeder seine Arbeit sehr gut erledigt, finden Sie auf der Seite Beispiele für Produktivitäts-Tuning-Maßnahmen.

Zurück zur Übersichtsseite