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
|
|