Aufgrund immer größer werdender Komplexität in Webprojekten, müssen wir uns als Webentwickler auch mit Softwarearchitektur auseinandersetzen. Hier geht es nicht nur darum UML Diagramme zu erstellen und technische Vorgehensweisen zu planen, sondern auch die Zusammenarbeit des Teams zu unterstützen, seine eigenen Überlegungen dem Kunden verständlich nahe zu bringen und dies jenseits von 100seitigen Pflichtenheften, die sich keiner durchliest und oft wenig konstruktiv sind.
Wie in vielen anderen Bereichen des Lebens, ist auch hier die innere Einstellung bzw. Motivation zum Thema und das Verhalten gegenüber des Teams und der Arbeit wichtig und besonders ausschlaggebend.
Als zusätzliche Unterstützung haben wir uns das Buch Knigge für Software Architekten zu Gemüte geführt, in dem es nicht um technische Aspekte der Planung geht, sondern um das Verhalten und die Arbeitsweisen eines Software Architekten und dessen Team.
Trotz des etwas steifem Titels ist das Buch sehr unterhaltsam und aufschlussreich geschrieben. Es werden zwar direkt Software Architekten angesprochen, aber die beschriebenen Punkte können zumeinst auch auf andere, zum Beispiel nicht technische Bereiche umgelegt werden. Kurz zusammengefasst geht es darum, verschiedene Typen von Menschen vorzustellen die einem während eines Projekts begegnen können. Dabei werden positive und negative Rollen beschrieben, wobei eine negativ behaftete Rolle auch positiv sein kann, wenn sie mit einem passenden positiven Typen zusammengebracht wird. Im folgenden möchte ich euch ein paar der im Buch vorgestellten Rollen vorstellen.
Positiver Typ: “Strukturierte Faulheit”
Der Mensch der die strukturierte Faulheit praktiziert, hat erkannt, dass das Rad nicht immer neu erfunden werden muss. Komponenten aus vergangenen Projekten können oft übernommen werden, man kann sich selbst Vorlagen basteln und diese für jedes Projekt adaptieren und wieder verwenden. Auch ist es immer hilfreich sich Dinge aufzuschreiben, damit man den Kopf freier bekommt und mehr Platz für kreative Ideen und Kommunikation mit dem Team hat. Auch bei Dokumentationen sieht man, dass diese kurz und knackig gehalten sein müssen, damit andere sie lesen (auch gern lesen) und verstehen. Bereits beschriebene Dinge sollten nicht erneut erklärt werden – auf diese soll einfach verwiesen werden à la DRY Prinzip (Don’t repeat yourself). Zusammengefasst lässt sich zu diesem Typ sagen, dass er weiß was er wiederverwenden kann und dass kurze aussagekräftige Dokumentationen oder Planungsdokumente brauchbarer sind, als dicke Wälzer die das Projekt zu tode dokumentieren.
Positiver Typ: “Der edle Ritter”
Dieses Kapitel des Buches ist besonders schön geschrieben:
Bis an die Zähne bewaffnet mit methodischer, technischer und auch fachlicher ‘Ausrüstung’ begleiten Sie Kunden, Auftraggeber und das Entwicklungsteam durch die oftmals gefährliche Reise durch die raue Wirklichkeit. […] Heimlich eingeschleust verbreitet sich schlechter Quellcode wie eine Seuche, die Ihre Entwickler blendet.
Bei diesem Kapitel musste ich sehr viel lachen :).
Hier werden die “ritterlichen Tugenden” des Software Architekten beschrieben. Diese Tugenden sind unter anderem: Ehre – besagt beispielsweise, dass man dem Kunden nichts versprechen sollte was man nicht halten kann. Lebensfreude – eine positive Einstellung motiviert das ganze Team. Treue – es geht hier um die Wünsche des Kunden und nicht um die eigenen.
Positiver Typ: “die Kommunikatorin”
Kommunikation ist immer wichtig wenn in Teams gearbeitet wird. Ob es nun darum geht an technischen Lösungen vor dem Whiteboard zu tüfteln oder Dokumentationen zu verfassen. Besonders Dokumentationen sind bei großen Projekten sehr wichtig (das kann gar nicht oft genug gesagt werden). Wie beim Punkt “Strukturierte Faulheit” bereits beschrieben worden ist, ist kurz und knackig hier das anszustrebende Ziel. Beim schreiben muss auch immer bedacht werden wer diese Dokumentation lesen wird, weswegen es auch sein kann, dass für unterschiedliche Projektbeteiligte unterschiedliche Versionen der Dokumentation nötig sind. Das spart allen Beteiligten Zeit und Nerven. Des weiteren ist auch die Sprache wichtig – das geschriebene soll verständlich sein und darf auch keine einschläfernde Wirkung haben.
Negativer Typ: “Der Diktator”
Dieser Typ ist wohl eindeutig negativ behaftet und glücklicherweise gibt es bei uns niemanden der sich als Diktator aufspielt. Diktatoren oder “Architoren”, wie sie dann im Buch auch genannt werden, zeichnen sich dadurch aus, dass sie wichtige Entscheidungen alleine treffen und Meinungen, sowie Inputs anderer Teammitglieder ignorieren. Klar, kann nicht immer alles mit dem Team abgesprochen werden und irgendjemand muss letztendlich entscheiden, aber grundsätzlich einfach “sein Ding” durchzusetzen macht einen nicht beliebt. Wenn man sich in der Position des Entscheiders befindet, ist es immer wichtig seine Begründungen erläutern zu können und seine Macht nicht blind zu demonstrieren.
Negativer Typ: “Der Code-Held”
Diese Rolle ist nicht durch und durch negativ zu sehen. Natürlich ist Code wichtig, da das Projekt ja auch in irgendeiner Form umgesetzt werden muss. Code soll aber als Ergebnis von Planung entstehen, denn Code allein sagt nichts aus über das Konzept und die Gründe der Vorgehensweisen aus.
Die negativen Eigenschaften des Code-Helden sind seine Gier danach alles selbst schreiben zu wollen und die Meinung, dass spärlich kommentierte Programme ausreichen müssen. Bei großen Projekten arbeiten aber meist mehrere Programmierer zusammen die bei weitem besseres zu tun haben, als stundenlang Programmcode zu lesen, um zu verstehen was eigentlich der Sinn des ganzen ist und was der Code eigentlich macht.
Konzepte alleine genügen nie als Input für Compiler, aber Quellcode genügt halt nicht als Input für Menschen!
Als Code-Held ist hier nicht der Software Architekt gemeint – aber die Aufgabe des Architekten ist es Konzept und Code richtig zu mischen – so, dass von beidem so viel wie nötig vorhanden ist.
Negativer Typ: “Der Perfektionist”
Der Perfektionist will immer alles perfekt sauber geplant, umgesetzt und dokumentiert haben. Die Gestaltung der Dokumentation muss natürlich auch einwandfrei sein und die Teamorganisation läuft wie am Schnürchen. Womit der Perfektionist aber nicht rechnet sind die anderen Menschen die ihm alles verderben! Sauberes und gewissenhaftes Arbeiten ist sehr wichtig, aber wenn man beispielsweise anfängt stundenlang Dokumentationen zu formatieren ist das reine Zeit- und somit Geldverschwendung. Ein guter Architekt weiß einfach wann genug des guten ist.
Wahrscheinlich treffen diese Typen nicht genau auf eine Person zu, stattdessen wird sich eine Person in mehreren Rollen wiederfinden. Das Buch pickt sich einfach diese Grundtypen heraus, beschreibt diese und gibt verschiedene Tipps für diese Rollen.
Ich hoffe ich habe nun ein wenig Interesse für das Buch geweckt (A5, ca 200 Seiten mit Bildern 😉 ). Wir finden das Thema Software Architektur im Hinblick auf Webprojekte sehr spannend – es zeigt wieviel Know How und Arbeit es allein von der technischen Seite braucht, um erfolgreich ein großes Projekt auf die Beine zu stellen. Was mir abschliessend noch wichtig ist, ist der Beweis, dass es bei der Planung und Umsetzung von Software jeglicher Art nicht nur um logisches Denken geht. Kreativität, Geduld, Sprache und ganz besonders soziale Kompetenzen spielen eine tragende Rolle.
Du willst mit jemanden über das Thema plaudern?
Einen kostenlosen Termin mit CEO Susanne vereinbaren!
UX Snacks Vol.08
Vergangene Woche gingen die 8. UX Snacks über die Bühne und es war wie immer ein Vergnügen unsere heiligen Hallen in der Schlossgasse gefüllt zu sehen.
Jetzt lesen
Folge #62 mit Susanne Liechtenecker
In Folge 62 besinnt sich Susanne auf die Anfänge dieses Podcasts und begrüßt keinen Gast, sondern erzählt über das Buch "Jäger, Hirten, Kritiker" von Richard David Precht und warum es sie inspiriert hat.
Jetzt anhören