Golo & Götz (02)
von Götz Martinek
"Golo & Götz" ist eine gemeinsame Serie von Golo Roden und Götz Martinek. Der eine ist CTO von the native web GmbH, der andere Geschäftsführer von sodge IT GmbH. Was die beiden vereint, ist ihre große Leidenschaft für die Entwicklung von Software. Seit September 2019 nehmen sie sich monatlich ein Thema vor, zu dem dann jeder seine individuelle Perspektive beschreibt, ohne den Artikel des jeweils anderen im Vorfeld zu kennen. Der zugehörige Artikel von Golo findet sich in seinem Blog auf heise.de/developer.
Die Fragestellung zu diesem Beitrag lautete: "Können und wollen wir wirklich orts- und zeitunabhängig arbeiten?"
Global 24/7 ftw
Globale Zusammenarbeit in Softwareprojekten ist ein Thema, bei dem sich auf Konferenzen ganze Hallen füllen. Von Zusammenarbeitsmodellen, Prozessen über Kommunikations(platt)formen bis zum Tooling. Das ganze für den Einsatz in kleinen Firmen, bei OpenSource Projekten und in Konzernen. Was ich hier kurz anreißen will, ist die global verteilte Zusammenarbeit von Teams in Softwareprojekten im kommerziellen Umfeld.
Wer arbeitet?
Noch wichtiger als in lokalen Projekten ist die richtige Zusammenstellung eines Teams. Damit meine ich neben der richtigen Wahl der fachlichen Fähigkeiten der Teammitglieder auch deren Arbeitsweise. Es hat keinen Sinn den technisch guten aber betreuungsintensiven Kollegen in einer Zeitzone zu haben die mit dem restlichen Team nur kurz überlappt.
Gerade in globalen Projekten kommen neben sprachlichen Hürden auch kulturelle Unterschiede, wie zum Beispiel Ansprechen von Problemen oder das Befolgen von Hierarchien, auf das Projektteam zu.
Die Projektleitung sollte sich hierfür in der Identifikation und Behebung von Missverständnissen auskennen. Vornehmlich so, dass alle Beteiligten ihr Gesicht wahren können. So kann ein einfaches Testtool viel besser (schmerzloser) und schneller aufzeigen, dass etwas nicht so wie erwartet umgesetzt ist, wie eine wöchentliche Telefonkonferenz.
Wie wird gearbeitet?
Da bei der verteilten Zusammenarbeit die Kommunikation einen markanten Anteil einnimmt, sind die passenden Werkzeuge um die Kommunikation zu erleichtern und nachvollziehbar zu machen noch wichtiger als sonst. Das Management sollte auf keinen Fall ins Mikromanagement verfallen, Teammitglieder sollten befähigt werden Entscheidungen selbst zu treffen. Dazu sollten die Ziele klar und nachvollziehbar definiert sein. Nicht nur als Big Picture, sondern auch anhand von Beispielen oder Referenzen, ggf. sogar quantifiziert. Ein Vertrauensvorschuss des Managements ist wichtig und kann auch offen kommuniziert werden.
Das ganze Konzept des verteilten Arbeitens sollte auch vom Management getragen werden, wenn Zellen enstehen, die in der Kommunikation bevorzugt werden und andere Teile des Teams abgeschnitten erscheinen, wird schnell die Stimmung in den abgeschnittenen Teilen des Team kippen. So eine Situation kann schnell entstehen, selbst wenn sich alle stark bemühen als ein Team zu agieren. Hier muss dann informiert und schnell reagiert werden um bei den abgeschnittenen Teamteilnehmern nicht auf den Arbeitsmodus 'nine-to-five' zu wechseln. Manchmal reicht es schon die Zuständigkeiten und Verantwortlichkeiten der einzelnen Teammitglieder besser gegeneinander abzugrenzen.
Warum wird gearbeitet?
Der wohl entscheidendste Punkt ist die Identifikation mit dem zu erstellenden Projekt. Warum entwickeln wir das Projekt und was ist unsere Vorstellung davon? Wenn hier genügend Motivation und eine gemeinsame Vision vorhanden ist, unterstützt das die gemeinsame Entwicklung enorm.
Was können wir tun?
Was können wir als Manager tun:
- Nachfragen von Entwicklern nicht als Details abtun, Diskussionen ggf. vertagen aber nicht vergessen
- Bemerkungen zum Gemeinschaftsgefühl von Teammitgliedern wahrnehmen und hinterfragen
- An Problemlösungen mit arbeiten und nicht nur zwischen möglichen Lösungen wählen
Was können wir als Entwickler tun:
- Frühzeitig das Management oder die Produktmanager auf fehlende Anforderungen hinweisen
- Probleme benennen und Beispiele zum besseren Verständnis bieten, vielleicht ist das Problem gar nicht Teil der angebotenen Lösung
Was können wir als Personen tun:
- Gelesenes immer entspannt entgegennehmen. Grundsatz: "Du darfst erst beleidigt sein wenn Du nachgefragt hast."
- Bei der Kommunikation und Dokumentation die Zeit nehmen, so zu schreiben, wie man es selbst gerne lesen würde
- Versuchen die Probleme der anderen zu verstehen und gemeinsam an einer Lösung für alle Seiten arbeiten
Das alles sollten wir eigentlich auch in lokalen Teams tun. Beim verteilten Arbeiten fallen diese Punkte, vor allem wegen der oben genannten Hürden, stärker ins Gewicht. Aus diesem Grund ist es für eine Firma, meiner Meinung nach, eine Grundsatzentscheidung ob man den Weg zum verteilten Arbeiten gehen will oder nicht. In kleineren lokalen Projekten lässt sich vieles schneller und nebenher klären, als wenn ich erst ein Meeting mit vier Teilnehmern und einer wackeligen Telko einberufen muss.
Es ist mir völlig bewusst, dass globale Teams vor allem bei großen Konzernen notwendig sind. Der zusätzliche Aufwand, gerade in Kommunikation und Transparenz, ist dann das notwendige Übel.
Aber viele Projekte lassen sich oft einfacher und schneller lokal lösen, da alle im gleichen Team/Raum sind und der Kommunikationsoverhead geringer ist. Daher sollten Projekte nicht nur nach Kapazität und Lieferdatum geplant werden, sondern auch die örtliche Zusammenstellung des umsetzenden Teams beachtet werden.
Manchmal ist es vielleicht langfristig doch besser die Kirche im Dorf, bzw. das Projekt vor Ort zu lassen!