// HEISE ONLINE — MODA & SOCIETÀ
Kritisieren oder schweigen? Diskussionskultur in IT-Projekten
Bleiben Probleme unausgesprochen, leidet das Projektergebnis. Teams und Einzelpersonen können aber einiges tun, um ihre Anliegen wirksam vorzubringen.
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.
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.
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.