T2 11.30 – Verständnisprobleme bei der Architektur
Viele der Studenten hatten ja während der Netzwerklosen Zeit die Gelegenheit über die Gesamtheit des Projektes zu sinnieren und mit anderen darüber zu philosophieren. Leider blieb dabei die Vollständigkeit des Konzeptes undurchschaut. Als dann noch der Professor kleine Bedenken zur Architektur geäußert hatte, war auch das letzte Vertrauen in die Anordnung der Komponenten zerstört. Da durch das vorhandene Autoritätsproblem – Aussage Prof gegen Aussage externer Architekt – vollständige Demoralisierung der Teams ausbreitete, fanden wir einen Konsens:
Wir erarbeiten mit Hilfe der GPMs und PMs eine neue Architektur, um für allgemeine Zustimmung des Teams zu erhalten. Dies schien mir einfacher, als auf einer Architektur zu bestehen, die beim Team auf Unverständnis stößt und zu unmotivierter Arbeit führt. Dieser Prozess dauerte zwar einige Zeit und verlangte viel Argumentationsarbeit, aber wir hatten eine „neue“ Architektur. Zu meinem persönlichen Triumph handelt es sich bei der neuen Architektur um die alte Architektur, nur, dass die Komponenten etwas anders angeordnet sind. Ich sehe aber zwei klare Gründe, warum die Studenten mit der neuen Architektur nun wunderbar klar kommen: Einerseits haben sie diese Konstruktion nun, mit Unterstützung meiner Argumentation, warum Dinge so sind, wie sie sind, selbst gebaut und somit auch „durchlebt“, wie alles zusammen arbeitet und andererseits erinnert mich die neue Anordnung der Komponenten an ein altes und in der klassischen Softwareentwicklung bewährtes Konzept: Das Schichtenmodell. Die einzelnen Teile waren nun den Schichtenfunktionen Frontend, Anwendungslogik und Datenzugriff zugeordnet.
Auch wenn die selbe Architektur erneut entstanden ist, betrachte ich diesen Schritt keineswegs als Zeitverschwendung. Denn im Nachhinein bin ich mir sicher, dass nun endlich das vollkommene Verständnis für meine Grundidee da ist und die Leute, mit denen ich das erarbeitet habe, nun diese Idee auch weitertragen. Das merkt man nun auch an den Argumentationen der GPMs bei Schnittstellenverteidigungsgesprächen. Ich bin froh!
Fazit 1: Autoritätskonflikte können das ganze Team demoralisieren!
Fazit 2: Eine Architektur muss unbedingt von den beteiligten Managern verstanden werden, sonst läuft das Projekt in die falsche Richtung.