Nehmen Sie an, Sie sind Softwarearchitekt. Jetzt kommen Sie am ersten Tag in ein neues Projekt, in welchem Sie tätig sein sollen. Was tun Sie als erstes? Na klar: Sie stellen sich für den Start auf und bereiten alles vor, um von Anfang an erfolgreich zu sein. Hier die ersten drei Schritte, die Sie nicht auslassen sollten, denn Sie können das ganze Projekt lang davon zehren:
Schritt 1: Stakeholder treffen
Reisen Sie. Treffen Sie alle wichtigen Stakeholder, von denen Sie glauben, dass die Einfluss auf die Softwarearchitektur haben werden, und zwar persönlich! Den Projektleiter, die jetzigen oder späteren Benutzer des Systems, den Kunden der bezahlt, die Requirements-Ingenieure, die Entwickler, die professionellen Tester, die User Experience-Spezialisten, Mitglieder der Betriebsmannschaft.
Gehen Sie mit denen essen. Reden Sie. Finden Sie heraus, was die umtreibt. Welche Stakeholder sind für das Projekt, welche dagegen? Glauben die Leute an Architektur-Arbeit, wissen die überhaupt, was das ist und was diese Arbeit für das Projekt bedeutet?
Ein Beispiel: Der Projektleiter
Projektleiter sollen ein Projekt ins Ziel steuern. Als Projektleiter wollen Sie, dass das Ergebnis zum richtigen Termin kommt, dass unterwegs möglichst wenige Risiken übersehen werden und möglichst wenige davon eintreten. Sie möchten als Projektleiter wissen, wo das Projekt steht. Wie weit sind wir, wie weit müssen wir noch gehen, was fördert uns und was steht uns im Weg? Wenn ein besonderes Ereignis auftritt, z.B. irgendein Feature einfach nicht funktionieren will, dann wollen Sie wissen, was die Projektmannschaft und Sie selbst jetzt tun sollen.
Als Projektleiter wollen Sie möglicherweise erst einmal nicht wissen, was nach dem Projekt passieren wird. Was, das System soll in Betrieb gehen und jahrelang laufen? Und soll auch noch wartbar und veränderbar sein? Naja, schau’n wir erst einmal, dass dieses Projekt ins Ziel kommt – um den Rest kümmern wir uns später!
Als Softwarearchitekt sollten Sie verstehen, was der Projektleiter will. Wodurch er belohnt wird. Was er unter Erfolg versteht. Was seine Schmerzen sind. Was ihn nachts wach hält. Sie als Softwarearchitekt müssen sich von Anfang an als idealer Partner und Herausforderer des Projektleiters positionieren:
Hallo Heinz, ich helfe Dir, das Projekt so smooth wie nur irgend möglich zu steuern. Ich weise Dich darauf hin, was alles in Deinem Projekt passiert. Ich sage Dir, was das bedeutet, über das die Entwickler da den ganzen Tag reden. Ich sage Dir, ob es eine Katastrophe ist oder ob es jeden Tag passieren kann. Ich helfe Dir, herauszufinden, ob das, was die Requirements-Ingenieure als Anforderungen aufschreiben, die Gesetze des Universums bricht oder ob es wahrscheinlich eine Kleinigkeit für die Entwickler sein wird. Aber, pass auf: Ich sage Dir auch, wo Du kurzsichtig bist. Ich sage Dir, was das Projekt leisten muss, um auch ein wartbares System zu bauen, das noch Jahre Bestand hat, selbst wenn Dein Projekt, Heinz, schon lange vorbei sein wird. Ich gebe Dir womöglich richtig Kontra, doch das geschieht nur zum Besten des Systems, das wir hier alle gemeinsam bauen werden.
Sprechen Sie stark, eindeutig, entschlossen. Von Anfang an. Wie einer, der weiß, wovon er redet (selbst wenn Sie sich am Anfang noch gar nicht so fühlen). Einer, der versteht, was abgeht. Sie sind der Experte für das System, das entsteht. Sie sind der Anwalt des Kunden, der versucht, das wahr werden zu lassen, für das der Kunde bezahlt. Der Projektleiter und Sie – das ist ein Duo, das sich manchmal fetzt und das doch zusammen steht. Ihre Ziele sind nicht immer dieselben. Und das ist auch O.K. so. Als Architekt werden Sie dem Projektleiter helfen, dass alles gut geht – selbst dann, wenn Sie ihn manchmal mit hartem Feedback konfrontieren müssen. Egal, alles zum Besten des lauffähigen, wartbaren Systems und des Kunden.
Schritt 2: Ihren Wert darstellen
Wissen die Stakeholder eigentlich, was Sie als Softwarearchitekt für einen Wert darstellen? Oben habe ich geschrieben, wie Sie mit dem Projektleiter sprechen. Was ist zum Beispiel mit den Entwicklern? Denen fällt ein, dass sie am liebsten nicht nur in einer Programmiersprache programmieren, sondern gleich zwei im Projekt einsetzen wollen, um bestimmte Dinge einfach besser in den Griff zu bekommen. Die möchten sich nicht um Grenzen kümmern, die Sie als Architekt ihnen setzen müssen.
Woher nehmen Sie eigentlich das Recht, den Entwicklern Vorschriften zu machen, Leitplanken zu setzen, Fels in der Brandung zu sein und zu sagen: Leute, wir müssen bestimmte Randbedingungen einhalten, sonst wird das alles teuer, was wir da machen? Welchen Wert liefern Sie als Architekt, wo die Entwickler doch diejenigen sind, die die Arbeit machen und die Wahrheit erzeugen?
Stellen Sie sich vor, die Entwickler sind eine Expedition, die sich durch den Urwald schlägt. Stellen Sie sich vor, Sie als Architekt sitzen in einem Flugzeug, das weit über dem Urwald fliegt und der Expedition helfen soll, durchzukommen. Sie sehen, wohin das Team läuft, weil Sie die Rauchwolken aus dem Urwald aufsteigen sehen. Sie sehen, dass das Team auf einen Fluss oder eine Schlucht zusteuert und funken eine Warnung zum Boden. Aber: Sie sehen eben nicht, dass das Team gerade gegen einen Tiger kämpft oder in eine Fallgrube getreten ist und sich erst wieder befreien muss. Ihre große Flughöhe ist Ihre Stärke als Architekt, und Ihre Schwäche zugleich.
Reden Sie mit den Entwicklern. Stellen Sie klar, was Sie beitragen können und was die Entwickler viel besser können als Sie. Etablieren Sie Funkkontakt mit ihnen – „hallo Urwaldteam, hier der Luftaufklärer. Was seht Ihr gerade? Von hier oben sieht es gefährlich aus, Sumpf voraus!“ Etablieren Sie von Anfang an eine Beziehung: Sie helfen den Entwicklern, indem Sie Schnittstellen klar ziehen, Verantwortung von Komponenten definieren, Sicherheits- und Skalierbarkeitsanforderungen auf mögliche Lösungen abbilden, vorausschauen, was im Backlog so kommt und was das für die Architektur und für den Fortschritt bedeutet. Und, indem Sie mit den Stakeholdern bereits geredet haben und verstehen, wie die ticken. Die Entwickler können sich so auf die eigentliche Arbeit konzentrieren und brauchen sich um die (aus deren Sicht) Seltsamkeiten der Stakeholder nicht zu kümmern.
Achso, und außerdem: Wenn Sie mehrere Teams im Projekt haben, dann haben Sie als Architekt natürlich längst dafür gesorgt, dass nicht zu viele Abhängigkeiten zwischen den Teams entstehen. Klar, bvor ein Arbeitspaket überhaupt in ein Team gelangt, haben Sie bereits geholfen, die Arbeit so zu schneiden, dass sie möglichst wenig Anlässe liefert, dass ein Team auf die Zulieferung eines anderen warten muss.
Cool, oder? Meine Güte, was Sie als Architekt alles leisten – ist das nicht einfach großartig? Ist doch logisch, dass jeder im Projekt Sie bei schwierigen Entscheidungen zuerst fragt, oder?
Schritt 3: Den eigenen Arbeitsstil finden
Hey, für all das brauchen Sie natürlich Ihren eigenen Arbeitsstil. Was heißt, der Projektleiter möchte Sie jetzt unbedingt sprechen? Und danach gleich der Leiter des Qualitätsmanagements? Und der Kunde gleich danach, um 13 Uhr?
Hmmm… am besten, Sie organisieren sich gleich von Anfang an so, dass es Ihren Stärken entspricht. Als Beispiel: Wann haben Sie Ihre produktivste, kreativste Zeit am Tag? Sind Sie ein Morgen- oder ein Abend-Mensch? Ich zum Beispiel kann komplizierte Zusammenhänge am besten allein darstellen, an meinem Schreibtisch. Also gehe ich zwischen 09:30 Uhr und 10:00 Uhr zu den Entwicklungsteams, setze mich dann hin und entwerfe. Dann gehe ich in Ruhe Mittagessen. Nachmittags treffe ich Stakeholder zu Einzelgesprächen in der Cafeteria der Firma. Oder andere Architekten, die in einer anderen Subdomäne des Projektes arbeiten als ich. Das Suppenkoma überwinde ich, indem ich mit anderen Menschen rede. Intensiv. Persönlich. Ich erzähle über meine Entwürfe und kassiere Feedback. Nicht immer angenehmes Feedback, doch was soll’s? Das Universum hat niemals behauptet, andere Menschen seien dazu da, um mir zu gefallen.
Abends dokumentiere ich noch ein bisschen und schaue in den RSS-Feed des Wikis, in dem die Entwickler wieder neue Seiten mit Doku angelegt haben, weil sie etwas Neues programmiert haben. Ich plane dann noch ganz kurz den nächsten Tag und gehe heim.
Wie arbeiten Sie selbst? Sie sind eine andere Person und haben Ihren eigenen Stil. Finden Sie ihn. Definieren Sie gleich am Anfang: Das bin ich, so arbeite ich. Wenn Ihr was von mir wollt, kann ich zu der und der Tageszeit am besten unterstützen, weil ich voll da bin. Was, Ihr wollt einen Termin? Ihr erreicht mich am besten dann und dann.
Machen Sie sich nicht verrückt, sondern leben Sie Ihre Realität. Sie sind eine wertvolle Person, und es gibt einen Grund, warum Sie hier in diesem Projekt sind. Sie haben eine Mission, Sie sind einzigartig. Alle anderen im Projekt werden sich um Sie reißen und Sie zuerst fragen, wenn es um wichtige Dinge geht.