Magazin & Blog

Kommunikation auf neuem Level

  • Cléa Fierz

In der internationalen Zusammenarbeit für den Flughafen Zürich erreichte die Kommunikation ein ganz neues Niveau. Jedes Projektmitglied kommunizierte offen und transparent, sodass alle jederzeit informiert waren. Die Stimmung im Team war fantastisch und die gesamte Atmosphäre klasse, trotz des engen Zeitplans und der vielen Herausforderungen im Projekt. Marta Imos-Merska, die seit 2013 in Polen als Senior Software Engineer für uns arbeitet, berichtet aus Sicht einer Backend-Entwicklerin über die internationale Zusammenarbeit und die technischen Herausforderungen.

Wir haben das Gespräch auf Englisch geführt – Sie lesen hier die deutsche Übersetzung.

Wie ein Team über Landesgrenzen hinweg kommuniziert

Marta, du bist seit 2013 bei Unic an Bord und hast als Software-Entwicklerin schon zahlreiche Projekte umgesetzt. Wie würdest du deine Arbeit für Unic und ihre Kund*innen am Standort in Polen beschreiben?

Da wir uns nicht persönlich über Ideen und Probleme austauschen können, ist bei unserer Arbeit von Polen aus effektive Kommunikation das Wichtigste. Das ganze Team in Polen und der Schweiz muss immer auf dem gleichen Stand sein. Also machen wir viele Video-Calls, chatten ständig und müssen vor allem immer reagieren. Das heisst: «Ignoriere nichts.» Auch wenn du gerade keine Zeit zum Chatten hast, gib deinem Gegenüber immer kurz Bescheid, stell dich nicht einfach tot.

Zu Beginn eines Projekts ist es immer hilfreich, wenn ein gut vorbereitetes Kickoff-Meeting stattfindet, bei dem wir mehr über die Regeln, die Ziele und den Entwicklungsprozess im Projekt erfahren können. Damit folgen dann alle Teammitglieder, egal wo sie sitzen, denselben Vorgaben.

Meistens läuft die Zusammenarbeit auch remote ohne Probleme. Wir sind ja schließlich ein IT-Unternehmen und sollten uns mit digitaler Kommunikation und technischen Tools auskennen (lacht).

Um Erfolg zu haben, müssen wir reaktionsstark sein. Ignoriere nichts!

Gute Verständigung und hervorragende Zusammenarbeit

Wie lief die Zusammenarbeit beim Flughafenprojekt im Vergleich mit anderen Projekten, in denen du vorher gearbeitet hast?

Wir kommunizieren immer gut in unseren Projekten, aber beim Flughafenprojekt haben wir in Sachen Kommunikation noch mal ein ganz neues Niveau erreicht. In den vergangenen Jahren habe ich in keinem Team eine so gute Verständigung oder eine so hervorragende Zusammenarbeit erlebt wie in diesem Projekt.

Wir haben zum Beispiel sehr viel über Kanäle in Microsoft Teams kommuniziert. Dabei haben wir fast ausschliesslich öffentliche Kanäle genutzt, die jeder einsehen konnte, auch der Kunde. Private Chats haben wir nach Möglichkeit vermieden. Das hat nicht nur zu einer sehr transparenten und offenen Kommunikation im Team und mit dem Kunden geführt, sondern auch dazu, dass das Team gut über alle gestellten und beantworteten Fragen, alle grösseren Sorgen, alle getroffenen Entscheidungen und vieles andere Bescheid wusste.

In den vergangenen Jahren habe ich in keinem Team eine so gute Verständigung oder eine so hervorragende Zusammenarbeit erlebt wie in diesem Projekt.

Wertvoller Austausch in der grossen Runde

Wie hat das Team zusammengearbeitet? Wie habt ihr abgesehen vom Teams-Chat kommuniziert?

Wir haben jeden Tag ein Daily mit dem ganzen Team gemacht. Und mit «ganzem Team» meine ich Backend-Entwickler*innen, Frontend-Entwickler*innen und die Testerinnen aus Polen und der Schweiz. Erst hat jede und jeder kurz ein Status-Update zu den jeweiligen Aufgaben gegeben. Anschliessend gab es eine offene Runde mit Informationen und Fragen. Anfangs war ich mir nicht sicher, ob offene Fragen in einer so grossen Gruppe, in der so viele unterschiedliche Fachgebiete vertreten sind, funktionieren würden. Ich konnte mir nicht vorstellen, dass Frontend-Fragen für Backend-Entwickler*innen spannend sein könnten und umgekehrt. Da habe ich mich getäuscht. Diese Runde war tatsächlich sehr wertvoll. Alle haben von den Informationen profitiert, und dadurch war das ganze Team gut informiert und wusste über die Probleme Bescheid.

Dank Christian Hahnloser und Oriol Torrent als Requirements Manager hatten wir immer einen hervorragenden Überblick über die Funktionalitäten, sowohl was die technischen als auch was die geschäftlichen Anforderungen angeht. Auf unsere Fragen und Einwände zu den Anforderungen haben sie immer Antworten gefunden.

Die Teammitglieder haben sich auch persönlich getroffen. Insgesamt hatten wir drei Projektmeetings, bei denen alle dabei waren. Wenn die Corona-Pandemie nicht gewesen wäre, hätten wir uns auch noch öfter gesehen. Wir haben uns einmal in Zürich und zweimal in Wrocław getroffen. Ich glaube, diese Projekttage sind für den Erfolg eines Projekts nicht zwingend erforderlich, aber ich fand sie sehr wertvoll. Es war eine grosse Bereicherung, das ganze Team in einem Raum zu haben, miteinander zu reden und zu brainstormen. Und wenn man Menschen persönlich kennt, läuft die Zusammenarbeit automatisch besser.

Insgesamt war die Atmosphäre im Team klasse – wir haben viel gelacht! Das hat uns geholfen, Spannung abzubauen, vor allem, weil wir mit unseren Deliverables unter immensem Zeitdruck standen.

Marta Imos-Merska, Senior Software Engineer bei Unic
Marta Imos-Merska, Senior Software Engineer bei Unic

Viel Lachen statt Missverständnisse

Was war deine Rolle im Projekt?

Ich habe als Backend-Entwicklerin Features im Backend umgesetzt – die Verarbeitung und die Bereitstellung von Daten über die API und die Vorbereitung der Sitecore Content-Struktur, damit sich für die Content-Autor*innen alles richtig anfühlt. Als Senior Developer habe ich bei Bedarf auch die weniger erfahrenen Entwickler*innen unterstützt. Ich habe Fragen beantwortet, bei Problemen geholfen und stand für Brainstorming zur Verfügung.

Gab es kulturelle Unterschiede? Kam es deswegen zu Missverständnissen?

Nicht wirklich – mir sind keine kulturellen Unterschiede aufgefallen. Am Anfang gab es vielleicht Unterschiede im Arbeitsstil, wodurch es zu Missverständnissen kommen konnte. Aber sobald unsere Teams-Kanäle und unsere Dailys aufgesetzt waren und klar war, dass Reaktionsstärke gefordert ist, liefen sowohl die Arbeit als auch die Kommunikation reibungslos.

Bei jedem Projekt kann es natürlich zu technischen Missverständnissen kommen, was verschiedene Aspekte der Spezifikation angeht. Aber das ist nichts, was wir nicht lösen können, wenn wir miteinander reden (lächelt).

Deswegen haben bei diesem Projekt Frontend- und Backend-Entwickler*innen bei allen Features, die wir umgesetzt haben, sehr eng zusammengearbeitet. Wir haben detailliert darüber gesprochen, was im Frontend und was im Backend abgewickelt werden sollte. Das hat uns ungemein dabei geholfen, technische Missverständnisse zu vermeiden.

Alle mussten dazulernen, und zwar schnell!

Von Schmetterlingen, sauberem Code und einer durchdachten Architektur

Welche technischen Herausforderungen gab es?

Wo soll ich anfangen? (lacht) Es war ein ziemlich anspruchsvolles Projekt. Für uns war alles neu: Für die Backend-Entwickler*innen waren es die Headless-Architektur mit Sitecore JSS und Azure Stack einschliesslich des Build-Systems – was auch für unser Operations-Team neu war. Für das Frontend war der Headless-Ansatz in Sitecore neu und für manche Frontend-Entwickler*innen auch die Arbeit mit React. Alle mussten also dazulernen, und zwar schnell!

  • Wir haben auch zum ersten Mal mit einem node.js-Proxy gearbeitet hatten Schwierigkeiten damit, die Ownership für diesen Teil der Lösung klar zuzuordnen. Letztendlich haben sowohl die Frontend- als auch die Backend-Entwickler*innen dort Änderungen vorgenommen.
  • Für uns Backend-Entwickler*innen war der Sitecore-JSS-Ansatz neu. Wir mussten lernen, wie sich das Standard-Sitecore mit MVC von Sitecore JSS unterscheidet. Dadurch wurde auch das Testen zeitaufwändiger, weil wir prüfen mussten, ob jedes Feature in beiden Modi richtig funktioniert.
  • Dann waren da noch die Herausforderungen, die wir durch die Verwendung von neuen Librarys und Plugins in fast jedem Projekt haben. Aber das ist es ja, was unsere Arbeit so spannend macht – wir müssen immer dazulernen.
  • Eine andere Herausforderung war die Einrichtung eines komplett neuen Build-Systems in Azure DevOps, aber damit hatte ich persönlich nichts zu tun.

Was uns trotz aller Herausforderungen immens geholfen hat, ist dass die Architektur der Plattform enorm gut durchdacht ist. Sie baut auf Helix-Prinzipien und Sitecore-JSS-Grundlagen auf, was es uns ermöglicht, klaren Code zu schreiben, effizient zu arbeiten und so einfach wie nur möglich auf einen Headless-Ansatz umzusteigen.

Was ist dir in Sachen Technik, Kunde und Team am meisten im Gedächtnis geblieben?

Was beim Headless-Ansatz toll ist, ist dass das Backend nicht auf das Frontend warten muss! Keiner hält den anderen auf. Wir haben am Anfang einen Contract definiert, der beschreibt, welche Daten zwischen Backend und Frontend ausgetauscht werden, und dann konnten wir dieselben Funktionalitäten parallel im Backend und im Frontend entwickeln. Nur für den abschliessenden Test der Integration mussten sowohl Backend- als auch Frontend-Teile fertiggestellt sein. Lesen Sie hier mehr zu Contract Driven Development.

Ausserdem ist der Code von aussergewöhnlich guter Qualität. Wir bemühen uns natürlich immer darum, guten Code zu schreiben, aber in diesem Projekt haben wir es geschafft, bis ganz zum Schluss alle Code-Reviews sehr gründlich zu machen, und das trotz des engen Zeitplans. Wir haben uns bis zum Go-live darum bemüht, noch besser zu werden. Wir haben immer die Zeit gefunden, sorgfältig und gewissenhaft zu coden.

Wie schon erwähnt, haben wir in diesem Projekt viel über Teams zusammengearbeitet. Der Kunde hatte auch Zugriff auf unsere Teams-Kanäle, also waren wir in unserer Kommunikation sehr offen. Normalerweise stehen «nur» die Requirements Engineers in regelmässigem Kontakt mit unseren Kunden. Das war auch hier der Fall, aber der Kunde hatte auch die Möglichkeit, das gesamte Team direkt zu kontaktieren, mit uns Dinge zu besprechen und Fragen zu stellen. Der Kommunikationsstil war sehr offen und sehr unkompliziert. Das war eine sehr angenehme Art, zusammenzuarbeiten.

Was das Team angeht, kann ich nur noch einmal wiederholen, dass die Stimmung wirklich klasse war. Wir haben sehr informell und trotzdem sehr respektvoll miteinander kommuniziert. Es hat viel Spass gemacht, mit so vielen tollen Leuten im Team zusammenzuarbeiten.

Kannst du uns zum Schluss noch eine Anekdote aus dem Projekt erzählen? Irgendetwas, was sich hinter den Kulissen zugetragen hat?

Naja, ich habe ja schon gesagt, dass wir in unseren Meetings viel Spass hatten. Wir haben auch viele GIFs in unsere Code-Reviews eingebaut. Diese Pull Requests durchzugehen, macht eine Menge Spass, wenn man mal eine Aufmunterung braucht.

Der Codename für das Projekt war «Butterfly» – wir haben einen Schmetterling gebaut, der eine ganz besonders erlesene User Experience ermöglichen sollte. Also gab es viele Wortwitze zum Thema Schmetterling. Wir haben deswegen auch eine ganze Reihe von GIFs aus dem Film «Das große Krabbeln» gebastelt, um verschiedene Projektsituationen darstellen zu können. Vor allem dann, wenn eine Funktionalität fast, aber eben noch nicht ganz, fertig war und das Sprintende schon nahte, haben wir dieses GIF verwendet.

Flughafen Zürich Hochmoderne Multisite-Plattform

Mit technologisch hochinnovativen Lösungen und einer klaren UX-Ausrichtung decken wir mit der neuen Multisite-Plattform die gesamte Systemlandschaft des Flughafens Zürich ab und begegnen somit den vielfältigen Bedürfnissen.

Experten-Blog Contract Driven Development verbindet Frontend und Backend

Konzepte und Ideen zu Headless CMS und den möglichen Anwendungsfällen sind derzeit in aller Munde. Für unser Sitecore-Team begann die Reise in diese Welt mit der Einführung von Sitecore Javascript Services JSS für die neue Multisite-Plattform für den Flughafen Zürich. Tobias Studer hat das Neuland Schritt für Schritt erschlossen und gibt einen Einblick in die Überlegungen und die Herausforderungen, welche die finale Lösung geprägt haben.