Wie Entwickler ihr Standing eigenständig verbessern können
Wie Entwickler ihr Standing eigenständig verbessern können
Trotz hoher Gehälter und rosiger Zukunftsaussichten gibt es auch im Bereich der Softwareentwicklung schlechte Arbeitsbedingungen. Insbesondere für Außenstehende ist das meistens nur schwer nachvollziehbar. Aber viele Entwickler leiden an unzumutbaren Arbeitsbelastungen, die sich negativ auf ihre Motivation und Produktivität auswirken. Allerdings sind sie nicht völlig wehrlos, sondern können ihr Standing im Unternehmen selbstständig verbessern – dafür müssen sie ihre Lage aber zunächst verschlechtern.
Als Softwareentwickler hat man eine rosige Zukunft, denn die Softwareentwicklung hat ihr schlechtes Image längst abgelegt. In Zeiten prekärer Arbeitsverhältnisse und wiederkehrender Finanzkrisen wartet der IT-Sektor mit hohen Gehältern und sehr guten Zukunftsperspektiven auf. Dieser Eindruck wird häufig unterstrichen durch die vielfältigen Mythen, die sich rund um das Silicon Valley ranken. Für die meisten sind diese Geschichten schon Motivation genug, um sich nach einem Job in der IT-Branche umzusehen.
In vielen Fällen überblenden diese Versprechungen den Umstand, dass die Erwartungen an ITler ziemlich hoch sind. Ihre Aufgaben sind fordernd und setzen, da sich der Markt im ständigen Wandel befindet, die Bereitschaft zum permanenten Lernen voraus.
Daneben wird eine weitere Hoffnung ebenfalls recht schnell enttäuscht: (fast) niemand ist in der Lage, das nächste große Ding in der IT-Welt alleine auf die Beine zu stellen. Zwar treten in der Softwareentwicklung immer wieder schillernde Persönlichkeiten auf den Plan; aber letztlich zeigt der Arbeitsalltag von Entwicklern, dass erfolgreiche Projekte hauptsächlich gemeinsam im Team umgesetzt werden.
Überzogene Erwartungen und falsche Hoffnungen wirken sich oft negativ auf den langfristigen Ansporn von Softwareentwicklern aus. Das Scheitern ambitionierter Projekte ist deswegen vielmals auf die mangelnde Motivation technischer Teams zurückzuführen. Immer mehr Unternehmen werden sich diesem Umstand bewusst und versuchen, durch entsprechende Maßnahmen die Arbeitsbedingungen ihrer Belegschaft und den Teamzusammenhalt zu verbessern.
Mitarbeitergestützte Prozesse und Agile-Methoden sollen helfen, die Eigenverantwortung der Teams zu stärken sowie technische und kulturelle Barrieren im Unternehmen zu überwinden. Gefördert werden soll eine produktive Unternehmenskultur, in der jeder Einzelne wertgeschätzt und seine Meinung respektiert wird. Der Fokus wird auf Innovationsreichtum, Transparenz, kollaborative Prozesse und gemeinsam geteiltes Wissen gesetzt. Aber auch die Etablierung einer Fehlerkultur im Unternehmen, sprich das dezidierte Lernen aus Fehlern statt Schuldzuweisungen, lohnt sich.
Aber was können Softwareentwickler tun, wenn zwar die beschriebenen Probleme bestehen, die Unternehmensführung aber keine Anstalten macht, in irgendeiner Weise dagegen vorzugehen? Beschwerden bei Freunden und Bekannten werden schnell als überhebliche Anklagen abgetan, da wie selbstverständlich davon ausgegangen wird, dass in der Softwareentwicklung hervorragende Arbeitsbedingungen herrschen. Stößt man mit seinen Anliegen auch in den Führungsetagen und bei den Teammitgliedern auf taube Ohren, ist Frust vorprogrammiert. Bleibt dann als einzige Option die Kündigung?
Nein – so zumindest lautet die Aussage von Andrew McDermott in seinem Artikel „Why You Should Make the Worst Parts of Web Development Even Worse“. Seiner Meinung nach sind Softwareentwickler nicht ausschließlich auf das Wohlwollen der Unternehmensführung angewiesen, sondern können viele Probleme, die die eigene Produktivität und Motivation gefährden, selbstständig in Angriff nehmen und ihr Standing im Konzern verbessern.
Kurioserweise werden laut McDermott positive Ergebnisse zumeist dann erzielt, wenn belastende Situationen durch eigene Anstrengungen zunächst weiter verschlimmert werden; zwei Beispiele verdeutlichen diesen Zusammenhang.
Laut McDermott kommen Entwickler in der Frühphase eines Projekts vielfach nicht drum herum, schlecht gecodeten Applikationen vorangegangener Tech-Teams zu reparieren, weil sie sich bereits im Live-Einsatz befinden. Diese sehr nervenaufreibende und zeitintensive Arbeit wird häufig dadurch erschwert, dass ausführliche Dokumentationen gänzlich fehlen.
Doch statt den Kopf in den Sand zu stecken und nur so viel Arbeit zu investieren, wie nötig ist, rät McDermott, sich intensiv mit den Codeversatzstücken auseinanderzusetzen und sie bis ins letzte Detail zu studieren. Diese äußerst mühsame Arbeit wird von den meisten Entwicklern gemieden; sie zahlt sich aber langfristig aus.
Durch den persönlichen Mehraufwand lernt man das System besser als alle anderen kennen und kann dadurch Veränderungen und Erweiterungen auf den Weg bringen, die sich positiv auf die Gesamtarchitektur auswirken. Anfallende Probleme können so wirklich gelöst und nicht lediglich kurzfristig beseitigt werden. Dieses Vorgehen verhindert beispielsweise, dass die Anzahl der Bugs durch fehlerhafte Fixes unnötig in die Höhe getrieben wird.
Auf diese Weise wird man zu einem unverzichtbaren Bestandteil des Unternehmens. Die sich daraus ergebenden Privilegien sorgen nicht nur in schwierigen Zeiten für eine Jobgarantie, sondern versetzen einen ebenfalls in die Lage, Forderungen und Ansprüche zur Verbesserung der eigenen sowie der Arbeitsbedingungen aller anderen stellen zu können.
Ein weiteres Szenario, das von McDermott beschrieben wird, befasst sich mit unzumutbaren Erwartungen seitens der Geschäftsführung. Er hat folgendes Szenario im Kopf: Ein Chef kommt zu seinem Entwickler und fordert von ihm, wichtige Features und Funktionen innerhalb der nächsten 24 Stunden zu implementieren; das ist jedoch allein aus technischen Gründen nicht machbar. Er wird allerdings nicht müde zu betonen, dass es sich um einen Notfall handelt und er die fristgerechte Integration den Auftragsgebern bereits vor Wochen versprochen hat.
Wiederum rät McDermott, auf die nachlässige Planung nicht mit Vorwürfen zu reagieren, sondern in die Forderungen einzuwilligen; allerdings darf die Einwilligung nicht ohne Auflagen erfolgen. Statt den offenen Streit mit dem Chef zu suchen, sollte klar formuliert werden, unter welchen Voraussetzungen die Aufgaben geleistet werden können und welche Arbeiten dafür zwangsläufig auf der Strecke bleiben müssen. Wichtig ist es, die Führungskräfte in den Sachverhalt aktiv mit einzubeziehen, sie um Hilfe zu bitten und ihnen die Erledigung bestimmter Pflichten anzutragen.
Auf diese Weise werden sie mit in die Verantwortung genommen und können sich ihr – wenn das Projekt scheitert – nicht entziehen. Der Vorteil liegt darin, dass die Beweislast, warum kein erfolgreicher Abschluss gefunden werden konnte, nicht mehr ausschließlich beim Personal liegt: Wenn der Chef seinen Verpflichtungen nicht nachkommen kann, kann er das von seinem Personal ebenfalls nicht erwarten. Und sollte er sich deshalb generell weigern, Hilfe zu leisten, büßt er seinen Status als Teamplayer ein. Um seine eigene Position nicht zu untergraben, muss er deshalb allgemeine Maßnahmen zur Optimierung der Arbeitsabläufe einleiten und Verantwortlichkeiten eindeutig zuteilen.
Wie die beiden Fallbeispiele zeigen, sind Softwareentwickler schlechten Arbeitsbedingungen nicht vollständig ausgeliefert. Durch Eigeninitiative kann der persönliche Einfluss im Unternehmen vergrößert werden; davon profitieren aber nicht nur sie, sondern auch alle anderen. Es ist also manchmal sinnvoll, unangenehme Belastungen weiter zu verschlimmern – denn am Ende kann das gesamte Team daraus Vorteile ziehen.