Software-Entwicklung: Wenn alle aneinander vorbeireden
(Bild: Pixabay)
Ein Erfahrungsbericht von Boris Mayer veröffentlicht am
Wenn große Software-Projekte nerven oder sogar scheitern, liegt das oft daran, dass Entwickler und Fachabteilung nicht die gleiche Sprache sprechen.
Die Zeiten, in denen Software quasi von einer Person allein entwickelt wurde, liegen Jahrzehnte zurück. Das Bild des einsamen Software-Entwicklers aus den 90ern, der in einem abgedunkelten Kellerraum sitzt, hin und wieder durch einen briefkastenähnlichen Schlitz oder eine Klappe mit großen Mengen warmer oder kalter Pizza, Cola, Kaffee und Chips versorgt werden muss, stimmt einfach nicht mehr.
Stellenangebote spiegeln dies wider: Gefragt sind heute auch bei Programmierern Kommunikations- und Teamfähigkeit. Innerhalb eines Teams fällt die Kommunikation dabei in der Regel 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. Die Teammitglieder können sich dann in ihrer eigenen Sprache unterhalten.
Schwieriger wird es schon, wenn Entwicklerteams anderer Bereiche dazukommen. Wenn etwa Frontend- mit Backend-Entwicklern zusammenarbeiten oder mit einem Datenbank-Team. Richtig schlimm kann es werden, wenn IT-Teams mit Fachabteilungen kommunizieren sollen. Dann passiert es unter Umständen, dass "Außenstehende" - aus Sicht der ITler - in Unterhaltungen nur jedes zweite Wort verstehen. Und das kann nicht nur nervig sein und Zeit verschwenden, sondern ganze Projekte zum Scheitern bringen.
Jeder Bereich hat seine eigenen Fachausdrücke
Zu Außenstehenden aus Sicht eines IT-Teams können auch schon IT-Projektkollegen gehören, die nicht der eigenen Gruppe angehören. Etwa die Kollegen, die fachliche Funktionen oder Prozesse spezifizieren: Sie wissen vielleicht nichts von Arrays oder Strings, eine Datenbank ist bei ihnen gerne mal eine "Datei" und eine Tabelle ist das, was auf dem Bildschirm zu sehen ist, nicht unbedingt das, was in der Datenbank liegt.
Dafür kennen sie andere Begriffe, von denen Programmierer vor einem Projekt in einer anderen Branche noch nie gehört haben. Auf dem Bau gibt es da zum Beispiel die Fluchtlinie, in der Landwirtschaft einen Schlag und beim Finanzamt den Grenzsteuersatz. Die beiden Gruppen sprechen unterschiedliche Sprachen, trotzdem müssen sie zusammenkommen und den jeweils anderen verstehen, damit aus einer fachlichen Spezifikation ein Programm wird, das die gewünschte Aufgabe erfüllt.
Unklares mit Fantasie auffüllen
Ich bin seit vielen Jahren Software-Entwickler, mit meinem Studium zum Diplom-Informatiker habe ich fast auf den Tag genau vor 25 Jahren angefangen. Zu der Zeit studierte man noch ein paar Jahre länger, arbeitete 20 Stunden pro Woche nebenher und in den Semesterferien in Vollzeit als gut bezahlter Software-Entwickler. Ich habe also viel Praxiserfahrung und deswegen auch in Sachen Kommunikation schon so manches erlebt wie große Softwareprojekte, die sich verzögern und teurer werden als geplant oder scheitern.
Nicht immer ist mangelnde Kommunikation zwischen den Projektbeteiligten der Grund, manchmal war auch einfach die Planung schlecht oder das Projekt zu groß. Oft ist es aber schon so: Es wird aneinander vorbeigeredet, im Zweifelsfall nicht nachgefragt und unklare Stellen werden mit Fantasie aufgefüllt.
Erfahrene Software-Entwickler wissen, dass kein Projekt ohne eine neue Geschichte zum Thema schiefgelaufene Kommunikation vergeht. Denn auch, wenn sich die Vorgehensweise in Projekten seit den 1990er Jahren stark geändert hat - vom streng hierarchischen Wasserfallmodell über das (in Behörden mitunter immer noch verwendete) V-Modell bis hin zu aktuelleren Modellen wie Extreme Programming oder Scrum mit immer mehr Kommunikation und Rückmeldung: Wirklich gelebt wird das alles in den wenigsten Fällen. Es lassen sich immer Gründe finden, warum etwas auf die spezielle Situation in einem Projekt nicht ganz passt.
"Auf die aktuelle Situation in dem Projekt nicht passen" ist Business-Sprache und bedeutet eigentlich: "Das erscheint uns nicht sinnvoll, hier können wir sparen." Häufig werden dann wichtige inkompatible Rollen in einer Person vereint oder Planungsmeetings, Schätzungsrunden und Feedback-Mechanismen zusammengestrichen - alles Einsparungen, die die Kommunikation innerhalb des Projekts stark einschränken. Gerade in Projekten, bei denen Mitarbeiter zu viel zu tun haben und die unbedingt zu haltenden Termine eigentlich zu knapp sind, sprechen die Sub-Teams weniger miteinander; stattdessen entsteht ein Gegeneinander.
Seit ich als Freiberufler arbeite, sind mir diese Probleme noch einmal bewusster geworden. Denn als Freelancer komme ich oft in Projekte, die schwierig sind und bei denen in einem letzten Rettungsversuch ein paar neue, erfahrene Entwickler dazugeholt werden. Ein Vorgehen, das so verbreitet ist, dass Freiberufler untereinander davon sprechen, "auf tiefrote Projekte gekippt zu werden".
Steigt man in ein solches Projekt ein, sieht man immer wieder die gleichen Probleme - und zwar viel deutlicher als Kollegen, die von Anfang an dabei waren und in der Zeit mit angesehen haben, wie sich die Dinge in die falsche Richtung entwickelt haben, immer nur ein kleines bisschen weiter, kaum wahrnehmbar. Man sieht es an den Kommentaren im Ticketing-System, ob und was da eingetragen wird, am Miteinander in Meetings und wie diese organisiert sind, und daran, wer mit wem überhaupt spricht, einfach so auf dem Gang.
Wenn im Specification Review alles abgelehnt wird
Und man sieht es daran, ob Arbeitsschritte eingebaut und ernstgenommen werden und welche die Kommunikation unterstützen - wie zum Beispiel das Specification Review. Es soll sicherstellen, dass einzelne Arbeitspakete hinreichend eindeutig spezifiziert sind, alle Informationen enthalten, die für eine Umsetzung benötigt werden, und dass abschätzbar ist, wie viel Zeit eine Umsetzung braucht. Im Scrum-Prozess ist dies Teil der Backlog-Pflege, die gemeinsam von Product Owner und dem Entwicklerteam durchzuführen ist.
Wird dem nicht genug Zeit eingeräumt, nehmen sich einzelne Entwickler oft ein Arbeitspaket-Ticket vor, schauen kurz drüber, entscheiden, dass da was fehlt, verpassen ihm den Eintrag "nicht genügend spezifiziert" - und geben es damit an die Kollegen aus der Fachabteilung zurück.
Das ist wenig hilfreich, denn es ist keine fundierte Kritik mit offenen Fragen, sondern eine Ablehnung, aus der die spezifizierende Person nichts lernen kann. Die Chance, dass der zweite Wurf dadurch besser wird, ist gering. Die Folge ist, dass beide Seiten früher oder später voneinander genervt sind: Niemand weiß, was die jeweils andere Person eigentlich will.
Unspezifisches Feedback ist keine Hilfe
Geholfen ist damit niemandem, das Arbeitspaket wird nicht fertig, es wird nur immer wieder blind mehr Zeit investiert: auf der Spezifikationsseite mit dem Fischen im Trüben, was noch fehlen könnte, auf der Entwicklerseite mit dem Durchsehen des Arbeitspakets und dem Versehen mit einem nichtssagenden Kommentar.
Die Folge ist ein verlangsamtes Projekt. Vielleicht steckt es noch nicht ganz fest - es ist aber höchstwahrscheinlich kurz davor.
In manchen Projekten gibt es als Zwischenschritt deshalb die technische Spezifikation. Eigentlich ist die Tech-Spec dafür gedacht, das Design der Software festzulegen, einen Überblick darüber zu geben, was alles zu tun ist, eine zeitliche Abschätzung des Projekts vorzunehmen und damit auch zu zeigen, wie viel ein Projekt oder auch ein Teil eines Projekts kosten wird.
Doch in einigen Projekten wird die technische Spezifikation für etwas anderes verwendet, nämlich als Übersetzung der fachlichen Anforderungen in eine technische Sprache, die ein Informatiker ohne großes Vorwissen in der Branche versteht.
Was zunächst gut klingt, hat den entscheidenden Nachteil, dass die eigentliche technische Spezifikation damit unter den Tisch fällt. Zudem führt dies eine zusätzliche Ebene der Trennung zwischen den fachlichen Auftraggebern und den ausführenden Entwicklern ein. Begriffe werden nicht mehr durchgängig verwendet, mal werden sie übersetzt, mal nicht.
Es entstehen zwei Sprachen im Projekt. Ohne Übersetzer - konkret ist das eine Person, die in dem Projekt nichts anderes tut und deren Urlaubs- oder Krankheitstage sofort als problematische Engstelle bemerkbar sind - verstehen sich beide Seiten immer noch nicht. Für Tests und Bugs hat das die Konsequenz, dass auch sie erst einmal wieder übersetzt werden müssen. Eine Folge kann sein, dass die Entwickler das Feedback als ungenau und schlecht empfinden und das fachliche Team kein Verständnis dafür aufbringt, dass es nicht verstanden wird: Jede Seite hält die andere für Trottel.
Wer jedoch die Kollegen aus der anderen Rolle allesamt für Trottel hält, wird Schwierigkeiten mit der Motivation bekommen. Ein gerne gehörter Satz in solchen Situationen lautet: "Ist doch egal, das verstehen die sowieso nicht." Wenn beide Seiten das voneinander denken, entsteht ein Teufelskreis. Irgendwann geht im Projekt gar nichts mehr voran, bis jemand es von außen ganz ausschaltet.
Stille Post oder mündliches Übermitteln mit Informationsverlust
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: nämlich in der Dokumentation des Arbeitspakets. Denn ein abgeschlossenes Arbeitspaket als Feature ist Teil der vorgenommenen Änderungen - und wenn eine Klarstellung benötigt wurde, gehört sie in die Dokumentation.
Fehlen solche Klarstellungen, wirkt sich das insbesondere negativ aus, wenn ein Arbeitspaket auf halbem Wege von einem anderen Entwickler übernommen werden muss. Undokumentiert heißt dann: nicht vorhanden. Die Klärung erfolgt erneut oder wird einfach nicht berücksichtigt.
Letztlich ist das die altbekannte Dokumentationsfalle. Eine ganz alte Regel in der Software-Entwicklung besagt, dass, wenn die Zeit knapp wird, die Dokumentation als erstes drangegeben wird. Es entsteht undokumentierter Quellcode, der in der Zukunft Probleme bereiten wird: Die Änderbarkeit sinkt, weil Änderungen nur schwer einzuführen sind, wenn nicht nachvollziehbar ist, was bisher eigentlich wo genau gemacht wurde.
Das wirkt sich nicht erst bei zukünftigen Änderungen aus, sondern sofort. Der Code wird zäh, in den Entwicklungsdokumenten entspricht vieles nicht dem aktuellen Stand - und wenn ein Mitarbeiter das Projekt verlässt oder auch nur für eine Woche ausfällt, wird es schwer, weiterzumachen.
Neben der Dokumentationsfalle habe ich in meiner Zeit als Software-Entwickler noch eine weitere Falle ausgemacht: die Zeitfensterfalle. Die Idee des Zeitfensters ist einfach: Um die Produktivität zu steigern, soll in Ruhe und störungsfrei gearbeitet werden können. Deshalb wird verabredet, dass Meetings und Telefonate nur am Vormittag abzuhalten sind und auch E-Mails nur in diesem Zeitraum beantwortet werden sollen. Damit haben alle am Nachmittag die Möglichkeit, in Ruhe an den eigenen Aufgaben zu arbeiten, ohne dass das Telefon klingelt, man auf den Posteingang achten muss oder gar jemand persönlich im Büro vorbeischaut.
Mit etwas Pech hat man sogar darauf geachtet, die Zeitfenstervorgabe auch auf das Ticket-System auszudehnen. Die Folgen sind katastrophal, denn im Zweifelsfall ergibt sich in den ersten fünf Minuten nach der Mittagspause eine wichtige Frage, die geklärt werden müsste, um vernünftig weiterarbeiten zu können.
Eine Nachfrage ist aber offiziell erst am nächsten Vormittag möglich, also wird mit der wahrscheinlichsten Vermutung weitergearbeitet. Das hat zur Folge, dass die Arbeit von fünf Stunden für die Tonne sein könnte, weil die Annahme schlichtweg falsch war. Nach ein paar Bekanntschaften mit der Tonne, wird an den Nachmittagen dann mitunter doch lieber erst mal die Festplatte aufgeräumt oder es werden die Bookmarks sortiert.
Erfahrene Entwickler wissen das, können sich aber nicht immer dagegen wehren. Denn um trotzdem erfolgreich eine Kommunikation aufzubauen, muss die andere Seite mitunter entgegen der Arbeitsanweisungen handeln. Sollte das unter der Hand passieren, führt das zusätzlich zum Problem der stillen Post: Man will ja nicht auch noch dokumentieren, dass man sich nicht an die Anordnungen gehalten hat.
Das landet an der Wand
Die Projekte, in denen einer oder in wenigen Fällen auch mehrere dieser Fehler passieren, landen gerne an der Wand. Dem Startup geht das Geld aus und die nächste Finanzierungsrunde scheitert. Oder der Mutterkonzern der Softwarefirma hat irgendwann genug, macht den Laden zu und kauft stattdessen ein Produkt von der Stange. Kleinere Projekte braucht man plötzlich nicht mehr, sie werden eingestellt, weil es aufwendiger ist und mehr Geld kostet, das Tool weiterzuentwickeln, als es nicht zu haben.
Manch ein Projekt wird aber auch mit Gewalt durch die Wand gedrückt und endet tatsächlich mehr oder weniger erfolgreich - wenn auch vielleicht in einem anderen Umfang als ursprünglich geplant. Oder wie es ein freiberuflicher Kollege in einem Kaffeepausengespräch einmal resümierte: "Wir sind in der Wand eingeschlagen, hatten aber genug Schwung, um durchzubrechen. Wesentliche Teile sind zwar dabei an der Wand hängen geblieben und abgerissen worden, aber durch ist durch."
Besser ist: Es gleich richtig machen
Damit die Sache mit der Wand gar nicht erst passiert - egal ob mit oder ohne Durchschlag: schmerzhaft ist die Wand auf jeden Fall -, braucht es gar nicht so viel: nämlich die bereits genannten 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 ansprechen, aber auch Lösungsmöglichkeiten.
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 gering.
Das Nachfragen fällt nicht immer leicht. Menschen geben ungern zu, etwas nicht zu wissen und so kann es durchaus vorkommen, dass gerade in größeren Meetings ein Fachbegriff fällt und niemand eine Regung zeigt, niemand fragend oder verwirrt dreinschaut, niemand Anstalten macht, zu einer Nachfrage anzusetzen. Die Angst davor, als womöglich einzige anwesende Person etwas nicht zu wissen und das auch noch vor versammelter Gruppe zuzugeben, hält davon ab, um eine Erklärung zu bitten.
Die Anwesenheit von Vorgesetzten kann ein weiterer Grund für Hemmungen sein. Und dann ist da noch die Meetingkultur ganz allgemein: In vielen Projekten werden Meetings als nicht besonders sinnvoll angesehen und gerne dauern sie auch noch sehr viel länger als vorgesehen. Wer will da schon ständig unterbrechen und dafür sorgen, dass sich das lästige Treffen noch länger hinzieht? Vielleicht hilft es, wenn man sich klarmacht, dass andere Meeting-Teilnehmer wahrscheinlich froh sind, dass wenigstens einer sich getraut hat zu fragen.
Nicht nur Startschwierigkeiten
Nachfragen werden umso schwieriger, je länger ein Projekt schon läuft. Der Erklärungsbedarf von Fachbegriffen verschwindet aber nicht, wenn ein Projekt erst einmal der Startphase entwachsen ist. Gute Gründe für den Bedarf gibt es viele: Es kommen neue Mitarbeiter hinzu, andere verlassen das Projekt und besonders bei umfangreichen Entwicklungen kommt es vor, dass einzelne Kollegen erst nach Jahren den ersten Berührungspunkt mit einer bestimmten Thematik haben. Ab einer gewissen Projektgröße lässt sich ziemlich sicher sagen, dass niemand alles weiß.
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 braucht nicht viel mehr Zeit. Wenn die genaue Erklärung umfangreicher wird, kann man meist in wenigen Worten eine grobe Erklärung geben und anbieten, sich nach dem Meeting für fünf Minuten zusammenzusetzen und das genauer zu erklären.
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.
Dabei werden Annahmen getroffen, wie es um den Kontext und das Vorwissen bestellt ist. Die zuhörende Person wiederum nimmt die Worte auf und entwirft so eine Vorstellung davon, was der Sprecher oder die Sprecherin meint. Auch hier spielen wieder Kontext und angenommenes Vorwissen des Anderen eine Rolle.
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. Wenn ein Arbeitspaket fachlich spezifiziert ist und einer der Entwickler sich der Problemlösung angenommen hat, gilt es zunächst einmal, Unklarheiten durch Rückfragen zu beseitigen.
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.
Gute Rückmeldungen zu geben oder gute Fragen rechtzeitig 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 - und zwar jedes Mal, wenn schnelles Loslegen und Sehen, wie weit man kommt, dazu führt, dass Dinge erledigt werden, die so gar nicht angefragt waren: Rechtsklick und Revert für alle geänderten Dateien in der Changelist.
Richtiges Nachfragen und das Geben von Feedback will gelernt sein - genauso aber auch Feedback und Fragen anzunehmen oder zu beantworten. Insbesondere bei rein schriftlicher Kommunikation ist die Form wichtig: Ein zwischendurch hingeklatschter Satz wirkt schnell wie ein Angriff. Gute Umgangsformen wie ein einfaches Danke oder ausgeschriebene "viele Grüße" statt "mfg" dagegen kosten nur Sekunden, tragen aber viel zu einem guten Miteinander bei.
Daran hat auch die Teamleitung einen großen Anteil. Sie 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 die Kommunikation nicht klappt?
Dass das Problem mit der Kommunikation in der Projekt-Entwicklung schon recht alt ist, zeigt übrigens ein Klassiker, der Tree Swing Cartoon. Die erste erhaltene Version davon stammt aus dem Jahr 1973, es gibt aber unzählige Variationen - inzwischen auch in Farbe. Gerüchteweise stammt die erste, jedoch verloren gegangene Version bereits aus den 1960ern.
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.
Individuelle Unterstützung zu Themen rund um Job & Karriere gibt Shifoo, der Service von Golem.de - in 1:1-Videosessions für IT-Profis von IT-erfahrenen Coaches und Beratern.