W-Jax 2015: Der glückliche Java-Entwickler

Und schon sind wir beim Ende der W-JAX-Reihe angelangt. Wie angekündigt wird sich der letzte Teil meines Blogs um glückliche (Java-)Entwickler drehen. Thilo Frotscher hat im letzten Vortrag meines letzten Tages auf der W-JAX einige Faktoren genannt, die dafür verantwortlich sind, dass glückliche Entwickler zu unglücklichen Entwicklern werden und andersherum, und mir dabei aus der Seele gesprochen. Deshalb will ich auf diesen Vortrag besonders ausführlich eingehen.

Die meisten von uns haben diesen Beruf gewählt, weil wir es lieben, technische Aufgaben zu lösen. Wir haben unser Hobby zum Beruf gemacht. Da sollte man doch meinen, wir müssten glücklich sein? Dem ist leider nicht immer so.

Tools

Fangen wir mit der Zeiterfassung an. Ich denke, es ist vernünftig, aufzuschreiben, wie lange man an einer Anforderung/einem Bug gewerkelt hat. Es ist wichtig für die Optimierung des eigenen Zeitmanagements und möglicherweise für die Projektplanung notwendig. Die Frage ist nur in wie vielen Medien man das machen muss? Thilo hat als Beispiel drei Medien mit unterschiedlichen Einheiten genannt. Ich kenne folgende Konstellation aus der Praxis: Stunden werden täglich in eine persönliche, projektübergreifende Excel-Datei eingetragen und dem Projekt, auf dem man gearbeitet hat, zugeordnet. Am Ende des Monats werden diese Zeiten in Personentage (PT) umgerechnet und vom Mitarbeiter in die allgemeinen projektspezifischen Excel-Dateien eingetragen. Eine weitere Konstellation: Zeiten werden in PT im Ticket des Issue-Trackingsystems erfasst, dann im Excel-Sprintbacklog für die Aktualisierung des Burndown Charts. Am Ende des Tages werden diese PT-Angaben in Stunden umgerechnet und im Zeiterfassungssystem bei dem jeweiligen Projekt eingetragen. Wie man unschwer erkennen kann, gibt es bei beiden Konstellationen Verbesserungspotenzial. Der Entwickler muss zwischen Medien wechseln und dieselben Zeiten in unterschiedlichen Einheiten erfassen. Das macht nicht glücklich.

Ein weiteres sehr wichtiges Thema sind die Entwicklungstools. Thilo sagt: „Jeder Entwickler sollte seine IDE selber wählen dürfen“. Jeder von uns hat einen Liebling, bei dem er die meisten (oder alle?) Funktionen und Shortcuts kennt und somit viel schneller entwickeln kann. Zudem sollten die Hardware und die für den Entwicklungsprozess notwendige Software die erforderliche Performance erbringen können. Es gibt nichts, was einen Entwickler mehr ärgert als eine Kombination aus einem langsamen Rechner, einem noch langsameren Change Request Tool und einer unbekannten IDE, die (scheint’s) weniger kann als die gewohnte IDE. Auf einem aktuellen Projekt wird zum Beispiel ein Tool für die Dokumentation der Anforderungen verwendet, welches knapp zehn Minuten braucht, um sich zu öffnen. Ich denke, jeder kann den Frust des Entwicklers nachvollziehen, der in diesem Tool etwas nachschauen muss.

Aufgaben

Wie bereits gesagt lieben Entwickler die Technik. Deshalb haben sie diesen Beruf gewählt. Thilos Erfahrungen decken sich mit meinen: Im Alltag sind Entwickler anzutreffen, die mehr als die Hälfte ihrer Zeit mit anderen Dingen beschäftigt sind. Ich denke, jeder kennt die stundenlangen Meetings, bei welchen man dabei sein muss, obwohl nur zehn Minuten wirklich relevant für einen sind. Oder die Auswertungen und Präsentationen, die für die Projektleitung erforderlich sind. Diese Aufgaben gehören zum Berufsbild dazu, dürfen jedoch nicht überhandnehmen.

Ein weiterer wichtiger Punkt, den Thilo aufgeführt hat, den ich jedoch aus meiner eigenen Berufspraxis nicht bestätigen kann: Neue Projekte werden nur mit externen Mitarbeitern besetzt. Sobald die Entwicklung fertig ist, wird die Wartung den internen Mitarbeiter überlassen. Als Grund wird häufig aufgeführt, dass die internen Mitarbeiter nicht über das notwendige Knowhow verfügen. Wenn man nun in die Haut des internen Mitarbeiters schlüpft und bedenkt, dass man immer nur reparieren darf, was andere verbrochen haben, dann kann man die Unlust förmlich spüren. Meine persönliche Erfahrung und auch die vieler Kollegen ist hingegen, dass die Projekte von Anfang an aus gemischten Teams zusammengestellt werden. Wir als Beratungsunternehmen sind daran interessiert, eine langfristige Kundenbindung aufzubauen, und das funktioniert nur, wenn man kundenorientiert denkt. Im Bezug auf Entwicklungsprojekte heißt das, dass der Kunde von Anfang an ein Teil des Teams ist. Die internen Mitarbeiter bekommen auf diese Weise die Zeit und die Chance, sich mit neuen Technologien und/oder neuen Vorgehensmodellen vertraut zu machen. Zudem entsteht dadurch auch ein Bezug zu der neuen Software. Es ist nichts mehr, was „die“ gemacht haben, sondern etwas, das „wir“ gemacht haben.

Weiterbildung

Beim Punkt Weiterentwicklung muss ich Thilo jedoch recht geben: Trainings für den Ausbau technischer Skills sind bei den meisten Unternehmen Mangelware. Bei Beratungsgesellschaften sieht es dagegen anders aus. Hier wird die Weiterbildung großgeschrieben. Bei der it-economics beispielsweise hat jeder Mitarbeiter zehn Tage Weiterbildungsbudget, um sich bei Trainings oder Konferenzen mit Themen, die ihm Spaß machen und im beruflichen Alltag nützlich sind, auseinanderzusetzen. Zudem wird für diverse Weiterbildungsveranstaltungen ein Arbeitszeit-Kontingent zur Verfügung gestellt. Als Beispiel sei hier die Clean-Code-Reihe genannt. In dieser Veranstaltungsreihe bereiten wechselnde Moderatoren einige Prinzipien und Methoden für sauberen Code auf und präsentieren diese den Veranstaltungsteilnehmern. Danach folgen eine Diskussion der Prinzipien und ein Erfahrungsaustausch, wie diese in den aktuellen Projekten angewendet werden (könnten). Auf meinen Kundenprojekten habe ich bisher keine Trainings angetroffen, die Entwickler als Zielgruppe haben. Die meisten Unternehmen bieten interne oder externe Trainings für Führungskräfte, Fachstab oder Projektleiter an. Veranstaltungen, die sich mit rein technischen Themen beschäftigen und Raum zum Ausprobieren und Austauschen bieten, werden nicht angeboten. In meinem letzten Projekt habe ich die Versuche mitbekommen, einen Jour Fixe für Entwickler zu etablieren. Jedes Teammitglied sollte Vorträge zu seiner aktuellen Projektarbeit und den verwendeten Technologien vorbereiten. Das Ziel war, einen Austausch über den aktuell eingesetzten Technologie-Stack zu bekommen und Verbesserungspotenziale aufzudecken. Das Ganze wurde nach zwei Vorträgen eingestampft. Ein Grund dafür war, dass die Vorträge neben der bisherigen Arbeitslast erstellt werden sollten. Die Teamleitung fand es natürlich toll, dass die Mitarbeiter so etwas machen wollten, hat jedoch keinen Freiraum für die Vorbereitung geschaffen. Ein weiterer Grund war die fehlende Motivation im Team. Jeder fand die Idee mit den Vorträgen und dem Austausch toll, doch keiner wollte moderieren.

Beim Thema Weiterbildung müssen beide Parteien eventuell umdenken und sich entgegenkommen: Die Unternehmen sollten Zeit und Gelegenheit zum Ausbau der technischen Skills bereitstellen und der Mitarbeiter sollte gewillt sein, Selbstverantwortung zu übernehmen, und sich proaktiv für die eigene Weiterbildung engagieren.

Sonstige Themen

Als weitere Themen, die die Zufriedenheit von Entwicklern beeinflussen, wurden von Thilo das Homeoffice, interessante Karrieremöglichkeiten und ein passendes Arbeitsumfeld genannt.

Jeff Atwood hat in seiner „Programmer’s Bill of Rights“ [2] weitere Forderungen formuliert, die erfüllt werden sollten, um produktive und glückliche Entwickler zu bekommen.

Fazit

Die drei Tage W-JAX waren sehr aufschlussreich. Ich durfte bei interessanten Vorträgen dabei sein, tolle Leute kennenlernen und mich über diverse Interessensgebiete austauschen. Veranstaltungen solchen Kalibers sind dazu da, den Entwicklern eine simple Möglichkeit zu bieten, einfach mal aus dem Arbeitsalltag herauszukommen und sich umzuschauen, was die anderen machen und wie sie es machen. Das hinzugewonnene Wissen kann per internem Vortrag oder als Blog in das Unternehmen transferiert werden.

Um es nochmals auf den Punkt zu bringen: Schee war’s!

Links