Kritisieren oder schweigen? Diskussionskultur in IT-Projekten

In IT-Projekten gibt es eine ganze Menge Dinge, die niemand hören möchte. Zum Beispiel, dass das Webformular eine Sicherheitslücke aufweist, das automatische Backup seit einer Woche nicht mehr funktioniert oder das bereits beworbene Feature ohne größeren Codeumbau nicht machbar ist.

Oft genug sieht sich der Überbringer der schlechten Nachricht selbst Kritik ausgesetzt. Kein Wunder also, dass viele genau überlegen, wie offen sie ihre Meinung in einem IT-Projekt äußern.

Alex Kirsch ist IT-Beraterin, Coach und freie Wissenschaftlerin. Mit ihrem Hintergrund in Künstlicher Intelligenz, User Experience Design und Entscheidungsfindung macht sie Software- und Entwicklungsteams fit für die harte Realität.

Schweigen und seine Folgen

Ob jemand Mängel anspricht oder sich Kritik verkneift, hat viel mit Erziehung, Kultur und Erfahrung zu tun. Was für eine Person ein technisches Argument ist, empfindet die nächste als Egotrip. Die unterdrückte Antwort: Diplomatie oder Heuchelei? Über persönliche Moralvorstellungen und Einzelfälle lässt es sich trefflich diskutieren. Der springende Punkt sind vielmehr die Auswirkungen auf das Projekt.

Ein ungeklärtes Problem ist wie ein unerkanntes Krebsgeschwür. Es kann wachsen, bis es sich irgendwann nicht mehr ignorieren lässt. Ein Beispiel dafür ist eine größere Aktualisierung einer Library. Die dafür notwendigen Änderungen im Code mitsamt Testen würden vielleicht eine Woche Zeit kosten. Niemand hat eine Woche Zeit übrig, also passiert nichts. Für die nächste größere Änderung der Library haben Entwicklerinnen und Entwickler natürlich noch weniger Zeit übrig. Irgendwann schlagen die Auswirkungen der veralteten Library im eigenen Code durch. Sie ist zu allem inkompatibel, moderne Funktionen sind unerreichbar. Das Problem: Statt eines Updates braucht es jetzt eine Neuimplementierung der betroffenen Stellen. Aus einem alltäglichen Stolperstein ist ein unüberwindbarer Wall geworden.

Manchmal bleiben Probleme einfach unerkannt. Das ist Pech. Oder Entwicklerinnen und Entwickler erkennen sie und entscheiden sich bewusst dafür, sie zu ignorieren. Das ist eine Ermessensfrage. Aber wenn Teammitglieder Probleme verschweigen, dann ist das eine verpasste Chance. Insofern wäre es in IT-Teams folgerichtig, das Ansprechen von Problemen aktiv zu fördern.

Bildungslücken bei der Diskussionskultur

Doch die Realität sieht anders aus; nicht nur, weil Diskussionskultur nicht zum Lehrinhalt eines Informatikstudiengangs zählt, sondern vor allem, weil IT-Projekte von Zeitdruck, überzogenen Erwartungen und mangelnder Management-Unterstützung geprägt sind.

Ein kaputtes Projekt macht alle kaputt. Die letzten drei Deadlines gerissen, Fachbereich oder Marketingabteilung sind sauer und machen Druck, im Team schiebt man sich gegenseitig die Schuld zu. Entdeckt ein Teammitglied jetzt ein neues Problem, wird es je nach Naturell entweder noch weniger bereit sein, es anzusprechen (wozu auch, es hat ja niemand Zeit, das Problem zu beheben) oder es besonders laut und aggressiv zur Sprache bringen (es ist fünf vor zwölf, jetzt muss endlich etwas passieren!). Das Problem bleibt bestehen und verkommt zum Streitfall, der das Projekt noch weiter verzögert und gefährdet.

Schade, dass es oft so weit kommt. Denn eigentlich wollen alle das gleiche: funktionierende Software, die jemandem das Leben in irgendeiner Form erleichtert und worauf Entwicklerinnen oder Entwickler stolz sein können. Und das wird umso unwahrscheinlicher, je weniger das Team Probleme offen ausdiskutiert.

Das einzelne Teammitglied könnte jetzt die IT-Welt verfluchen und Dienst nach Vorschrift erledigen – oder sich der Realität stellen und die Situation als persönliche Herausforderung annehmen. Die Rahmenbedingungen eines Projektes kann es üblicherweise nicht ändern und hat auch die Stimmung im Team nicht direkt in der Hand. Teammitglieder können jedoch Strategien entwickeln, um den eigenen Argumenten mehr Gehör zu verschaffen.

Fragen statt sagen

Fragen sind ein didaktisches Instrument und helfen oft weiter als die Demonstration von Fachkompetenz. Wer ein Problem selbst erkennt, macht niemanden anderes dafür zum Sündenbock. „Dein Code ist Schrott!“, greift persönlich an und erzeugt schlechte Stimmung. „Dein Code könnte eine kleine Überarbeitung gebrauchen“, ist noch schlimmer, denn die angesprochene Person wird oft nicht einmal verstehen, dass es ein Problem gibt. Probieren wir es konstruktiv: „Dieser Code ist ineffizient, weil er innerhalb der Schleife dieselbe Berechnung mehrfach durchführt. Wir sollten diese aus der Schleife herausziehen“, oder „Diesen Code finde ich schlecht lesbar, weil ich die Aufteilung in Funktionen nicht nachvollziehen kann.“ Bei diesen Aussagen geht es um den Code, nicht um die Fähigkeiten der Person, die ihn produziert hat. Das Problem wird direkt benannt und lässt sich beheben.

„Das geht nicht!“, kann die Adressatin oder der Adressat der Kritik leicht als inkompetent oder bockig auslegen. Was genau geht denn nicht? Die notwendige Technik ist noch nicht erfunden? Also versuchen wir eine Lösung zu finden: Warum wird diese Funktion gebraucht? Welche Effekte wie Kosteneinsparung oder Fehlerreduzierung sollen dadurch entstehen? Mit ein paar Fragen macht man entweder die Sinnlosigkeit offensichtlich oder findet gemeinsam eine Lösung.

Oder ist das „geht nicht“ eine Zeitfrage? Dann vielleicht „Ich/Wir als Team arbeite/n gerade an Feature X, Test Y und Dokumentation Z. Wie sollen wir diese neue Anforderung priorisieren? Welche der anderen Aufgaben, die aktuell geplant sind, sollen wir hinten anstellen?“.

Antennen ausfahren

Jeder Mensch pflegt eine andere Diskussionskultur, vielleicht sogar unterschiedliche je nach Kontext. Es lohnt sich, die eigene Antenne für Befindlichkeiten gut zu kalibrieren.

Im alltäglichen Umgang mit Teammitgliedern ergeben sich viele Gelegenheiten zur Beobachtung. Ist der Mensch ein Morgenmuffel? Dann die heiklen Themen erst nach der Mittagspause auftischen. Geht es mit rationaler Begründung voran oder hilft es, auf den Angst- oder Belohnungs-Knopf zu drücken? Wie bringt das Teammitglied selbst Argumente vor? Ein schöner Zeitvertreib in langweiligen Meetings ist, sich vorzustellen, was die einzelnen Leute gerade denken oder warum sie überhaupt zu diesem Termin erschienen sind.

In einem gut eingespielten Team muss man nicht jedes Wort auf die Goldwaage legen. Zum Beispiel kommt die Chirurgin mit einem einfachen „Skalpell!“ durch, ohne zeitraubende Höflichkeiten wie „Würden Sie mir bitte das Skalpell reichen?“ Deshalb lohnt es sich, gegenseitiges Vertrauen aufzubauen und auch eigene Grenzen klarzumachen.

Kritik verarbeiten

Kritiker können auch selbst zur Zielscheibe von Kritik werden. Sei es durch eine andere Meinung zur abgelieferten Arbeit, ein Gegenargument in einer Diskussion oder durch einen offenen persönlichen Angriff. Wie geht man am besten damit um? – Erst einmal einen Schritt zurücktreten, tief durchatmen und analysieren. Worum geht es und warum fühle ich mich angegriffen?

Gibt es eine unterschiedliche Sichtweise der Situation? Ist die Sicherheitslücke in der Library ein Grund zur Panik oder ein theoretisches Angriffsszenario, das im Kontext gar nicht relevant werden kann? Entwicklerinnen und Entwickler müssen die Meinung des anderen nicht übernehmen, sondern sich nur bemühen, die andere Sichtweise nachzuvollziehen. Vielleicht kennt der andere nicht alle Fakten, hat weniger Erfahrung oder ein höheres Sicherheitsbedürfnis.

Oder will jemand nur Dampf ablassen und ein Sündenbock war gerade greifbar? Manchmal haben Motive für Kritik und Diskussionen gar nichts mit der Sache zu tun oder machen eine Kleinigkeit zur Staatsaffäre. Dann sollte man ruhig bleiben, Gegenfragen stellen und versuchen, auf eine sachliche Ebene zu kommen oder auch das Gespräch vertagen.

Selbst wenn ein Argument sachlich und korrekt ist, mag es uns nicht gefallen. Oft beschleicht einen das unangenehme Gefühl, etwas falsch gemacht zu haben. Dabei sollten wir nicht vergessen, dass auch das größte Genie mal daneben liegt. Gut vorgebrachte Kritik ist ein Zeichen dafür, dass das Team funktioniert. Immerhin macht sich jemand die Mühe, uns darauf hinzuweisen.

In vielen Fällen stört uns auch einfach die Konsequenz des Gesagten, wenn daraus weitere Arbeit folgt. Fertig geglaubter Code muss geändert werden oder nicht eingeplante Aufgaben verzögern den Zeitplan. Darüber freut sich niemand. Trotzdem sollten wir uns hüten, die Meinungsäußerungen anderer zu ignorieren, als irrelevant abzutun oder den eigenen Unmut am Nachrichtenüberbringer auszulassen. Wer selbst den Respekt fordert, gehört zu werden, sollte ihn auch anderen zuteilwerden lassen.