In der Projektarbeit ist es oft erforderlich, dass sich mehrere Personen eine Rolle teilen. Zum Beispiel, wenn die für eine Rolle vorgesehenen Aufgaben besonders komplex sind oder wenn das begrenzte Budget keine andere Möglichkeit zulässt. Projektleiter, Auftraggeber, Software Architekten, Software Tester, etc. sind Beispiele für Rollen, die in der Praxis oft auf mehrere Personen aufgeteilt werden. Dieser Beitrag verdeutlicht die negativen Auswirkungen der Rollenteilung. Er zeigt, wie wichtig Vorsorgemaßnahmen sind, um unerwünschte Folgen in Grenzen zu halten, beziehungsweise zu vermeiden.
Für die Philosophen vergangener Zeiten war die Welt leicht erfassbar. Auf der eine Seite herrschte das Chaos, also Durcheinander und Instabilität, und auf der anderen der Kosmos - also Ordnung und Stabilität. Über die zeitliche Abfolge war man sich einig: Zuerst kam das "böse" Chaos, danach der "gute" Kosmos. Irgendwann würde alles seinen Platz finden.
Was schließen wir heute daraus? Die Philosophen von damals haben wahrscheinlich nie ein Projekt durchgeführt!
Ein gewisses Maß an Chaos lässt sich in Projekten nie ausschließen. Projektleiter müssen immer mit dem Faktor Unsicherheit rechnen. Damit umzugehen ist meist verwirrend. Software-Projekte sind darüber hinaus Opfer eines ganz besonderen "modernen Leidens": Das fürchterlichste Chaos kann plötzlich aus dem schönsten Kosmos heraus entstehen. Mit anderen Worten: Konfusion entsteht nicht unbedingt immer aus unorganisiertem Verhalten der Projektmitarbeiter, sondern wegen deren "vernüftigem" Handeln.
Nehmen wir an, ein Unternehmen hat den Auftrag, ein Auto herzustellen. Es setzt ein Projekt mit drei Gruppen und drei Gruppenleitern auf: "Mechanik" (Frau Gaber), "Elektronik" (Herr Weiß) und "Design" (Herr Walter). Am ersten Projekttag schickt der Kunde Frau Gaber eine E-Mail mit den aktuellsten Motor-Spezifikationen zu ("motorspec.doc"). Die E-Mail ist - natürlich - verschlüsselt.
Frau Gaber möchte ihre Kommunikation mit dem Kunden dokumentieren. Deshalb speichert sie das verschlüsselte Dokument auf dem Server des Unternehmens, um später darauf zurückgreifen zu können.
Gleichzeitig möchte sie aber auch die Kollegen über die neuen Anforderungen informieren. Sie entschlüsselt das Dokument, damit es alle lesen können, speichert es auf dem Server und schickt es per E-Mail an die Kollegen weiter. Klingt vernünftig, oder?
Herr Weiß bekommt das Dokument per E-Mail. Er begreift, dass es wichtig ist und dass deshalb alle Projektteilnehmer Zugriff darauf haben sollten. Also speichert er es auf dem Server. Doch Herr Weiß hat Erfahrung und weiß, wie schnell Spezifikationen veralten. Um den Überblick zu behalten fügt er das Eingangsdatum an den Dokumentennamen an ("motorspec_20031231.doc"). Auch das klingt vernünftig.
Gleichzeitig erhält auch Herr Walter das Dokument. Wie Herr Weiß möchte er die unterschiedlichen Spezifikationen, die eingehen, vorbildlich dokumentieren. Deshalb öffnet er das Dokument, liest die Version und ergänzt den Dokumentennamen um eine Versionsbezeichnung ("motorspec_v01.doc"). Dann speichert er es ebenfalls auf dem Server - was ebenfalls vernünftig ist.
Lassen Sie uns nun einmal überprüfen, welche Konsequenzen diese drei - an sich völlig rationalen -Verhaltensweisen haben. Versuchen Sie, das Beispiel nicht "von oben" zu betrachten. Versetzen Sie sich statt dessen in die Lage von Frau Gaber, Herrn Weiß und Herrn Walter. Auf dem Server liegen inzwischen vier verschiedene Dokumente mit gleichem Inhalt:
