VON BORIS MAYER

Software-Entwicklung ist Teamsache, und deshalb braucht sie gute Kommunikation. Innerhalb eines Teams fällt sie in der Regel noch leicht. Vor allem, wenn die Kolleginnen und Kollegen im Team die gleichen Aufgaben haben, über einen ähnlichen Hintergrund und Wissensstand verfügen oder gar die gleichen Programmiersprachen gut beherrschen und ihre Bibliotheken auswendig kennen. Schwieriger wird es schon, wenn Entwicklerteams anderer Bereiche dazukommen, etwa Frontend- mit Backend-Entwicklern oder mit einem Datenbank-Team zusammenarbeiten. Richtig schlimm kann es werden, wenn IT-Teams mit Fachabteilungen kommunizieren sollen. Dann passiert es unter Umständen, dass aus Sicht der IT-ler „Außenstehende“ in Unterhaltungen nur jedes zweite Wort verstehen. Und das kann nicht nur nervig sein und Zeit verschwenden, sondern ganze Projekte zum Scheitern bringen. 

Unklares mit Fantasie auffüllen

Ich bin seit vielen Jahren Software-Entwickler und erlebe es in großen Softwareprojekten häufig so: Es wird aneinander vorbeigeredet, im Zweifelsfall nicht nachgefragt, und unklare Stellen werden mit Fantasie aufgefüllt. Es gibt viele Ansätze für gute Kommunikation in Projekten, aber wirklich gelebt wird das alles in den wenigsten Fällen. Man sieht das an den Kommentaren im Ticketing-System und ob Arbeitsschritte eingebaut und ernstgenommen werden, wie zum Beispiel beim Specification Review. Eine ganz einfache Möglichkeit, Missverständnisse aus dem Weg zu räumen, ist der Griff zum Telefon. Nachfragen am Telefon sind gut, praktisch und gehen schnell. Ein Problem dabei ist häufig aber, dass die Erkenntnisse daraus nicht dort landen, wo sie hingehören: in der Dokumentation des Arbeitspakets. 

Besser ist, es gleich richtig machen

Für eine gute Kommunikation in deinem Team und mit anderen Teams braucht es Kommunikationsfähigkeiten auch außerhalb des eigenen Expertengebietes und über Rollengrenzen hinweg. Zur Kommunikation gehören dabei zwei Aspekte. Erstens die Frage: Wie wird richtig kommuniziert? Und zweitens das Wissen darum, was an welcher Stelle schiefgehen kann. Im gesamten Projektteam sollten die Mitarbeiter dazu ermuntert werden, miteinander zu reden. Sie sollten Fragen frühzeitig klären, Probleme, aber auch Lösungsmöglichkeiten ansprechen. Dabei ist es zum Beispiel sehr wichtig, nachzufragen, wenn ein unbekannter Begriff fällt. Am besten landet die Erklärung in einem Glossar im Projekt-Wiki, denn die Wahrscheinlichkeit, dass an dem Meeting alle teilgenommen haben, die den Begriff vorher nicht kannten, ist klein. Man kann es allen leichter machen, wenn eine Projektkultur etabliert wird, bei der bei einer Nachfrage nicht mit den Augen gerollt oder ein genervter Gesichtsausdruck aufgesetzt wird. Ein erklärender Satz geht schnell. 

Und dann ist da noch das menschliche Gehirn

Bei der Frage, wie man richtig kommuniziert, hilft es zudem, sich das Miteinanderreden als Prozess vorzustellen. Wenn ein Mensch einem anderen etwas sagt, wird ein Gedanke in Sprache formuliert, und zwar so, dass es die zuhörende Person verstehen müsste. In diesem Vorgang sind gleich zwei Interpretationsvorgänge enthalten, denen Annahmen zugrunde liegen. Was sich die sprechende Person gedacht hat, muss nicht das sein, was bei der zuhörenden angekommen ist. 

Durch zeitnahe Rückmeldung und Transparenz kann man jedoch schnell erkennen, wenn es mit der Kommunikation nicht geklappt hat, und man kann entsprechend rückfragen. Frühes Testen, am besten schon von Zwischenergebnissen, hilft, Irrwege kurz zu halten, wenn nicht gar zu vermeiden. Eine Rückmeldung, in der Entwickler mit eigenen Worten noch einmal beschreiben, wie sie ein komplexes Problem verstanden haben, kann helfen, Missverständnisse aufzudecken. Das sind gute Kommunikationsfähigkeiten. Die kann man lernen, zum Beispiel mit Hilfe eines unserer Coaches von Shifoo.

Gute Rückmeldungen kosten Zeit

Gute Rückmeldungen zu geben oder gute Fragen rechtzeitig zu stellen, kostet Zeit. Es erfordert, die gestellte Aufgabe zu durchdenken und sich selbst Fragen zu stellen, ob alles, was an Informationen und Wissen benötigt wird, vorhanden ist. Danach kostet es noch einmal Zeit, die Frage oder das Feedback verständlich und möglichst genau zu formulieren, und es kostet auch Zeit, auf eine Antwort zu warten. Es ist schwer, sich diese Zeit zu nehmen, wenn der Druck, dass etwas fertig werden muss, groß ist. Allerdings zahlen sich die investierten Minuten normalerweise schnell aus. Die Teamleitung sollte allzu großen Druck auf die Entwickler, möglichst schnell die ersten Zeilen Code zu tippen, vermeiden. Auf der Fachabteilungsseite ist die Forderung, sich bei den Arbeitspaketen möglichst kurz zu halten, eher schädlich. Gutes Arbeiten sollte nicht nach Anzahl der angelegten oder bearbeiteten Tickets bewertet werden, denn das ist nicht unbedingt sinnvoll. Gutes Coaching anzubieten hingegen schon.

Und was passiert, wenn es doch nicht klappt?

Dass das Problem mit der Kommunikation in der Projekt-Entwicklung schon recht alt ist, zeigt ein Cartoon aus dem Newsletter des University of London Computer Centre aus dem Jahr 1973, von dem es unzählige Variationen gibt. Bei der Baumschaukel geht es nicht um Software-, sondern allgemein um Produktentwicklung. Aber der Gedanke dahinter gilt ohnehin für menschliche Begegnungen aller Art: Wenn aneinander vorbeigeredet wird, klappt es einfach nicht.