Sie haben ein Offshore / Nearshore IT Entwicklerteam oder betreiben gar ein IT Nearshore / Offshore Entwicklungszentrum? Dann setzen Sie sich sicherlich mit dem Thema Fluktuation auseinander; zum einen geht es darum, Fluktuation grundsätzlich zu vermeiden (TIPPS hierzu vgl. in diesem Artikel: Wie sich Fluktuation minimieren lässt). Zum anderen sollten Sie Organisation und Prozesse darauf ausrichten, im Falle von Fluktuation (diese lässt sich nicht immer durch gutes Management vermeiden) die Risiken zu minimieren und die Produktivität des Teams von Softwareentwicklern aufrecht zu erhalten.
Sie finden nachfolgend einige zentrale Tipps, um Risiken der Fluktuation in Ihren Nearshore / Offshore Entwicklerteams zu neutralisieren
Erstens: Systematisches Knowledge Management und Dokumentation. Es ist im Grunde ein no-brainer, aber die Praxis bei Softwareunternehmen zeigt, dass Dokumentation in Softwareteams nicht selten vernachlässigt wird. Die Gründe reichen von sportlichen Roadmaps für die Produktentwicklung bis hin zu der Tatsache, dass Dokumentation eine ungeliebte Aufgabe ist.
Bei Nearshore / Offshore Teams sollte Dokumentation allerdings höher priorisiert werden. Es empfiehlt sich, für diese Aufgabe von Anfang an in Projekten und Projektzeitplänen etwa Zeit vorzusehen. Dokumentation findet hierbei nicht etwa einfach am Ende eines Projektes statt, wo das Softwaredesign / die Architektur dokumentiert werden, Methoden beschrieben werden und derlei mehr. Es geht auch darum, dass die Kommentierung im Programmiercode auf täglicher Basis gepflegt wird, dass in Ticketsystemen (JIRA, Version One, Redmine und Ähnliche) Methoden dokumentiert werden. Dies sollte regelmäßig überprüft werden und eingefordert werden.
Zweitens: Das Softwareteam sollte so organisiert sein, dass sich keine Kopfmonopole bilden, also: Softwareentwickler/Innen, die exklusives Wissen besitzen. Eben dies ist ja als Prinzip in Projektmanagementmethoden wie Scrum verankert (Stichwort: Full-Stack Developer). Leben Sie diese Methode!
Drittens: Wenn sich neue Entwickler/Innen in ein Projekt einarbeiten müssen, dann ist nicht nur die gute Dokumentation entscheidend. Je besser der Code strukturiert ist, je besser Coding Standards umgesetzt sind (z.B. kein Spaghetti-Code), desto schneller kann sich ein neues Teammitglied einarbeiten. Zu diesem Zweck müssen derartige Coding Standards transparent und verbindlich sein; es hat sich bewährt, etwa zu Peer Code Review sicherzustellen, dass solche Vorgaben nicht nur graue Theorie bleiben.
Viertens: Kommt es zur Fluktuation im Team, ist schnelle Reaktion gefordert. Der/Die ausscheidende Entwickler/In hat die Aufgabe, Knowledge Transfer zu leisten; das Management / die Teamleitung sollte schnell jemanden benennen können, der das Knowledge entgegennimmt. Im Idealfall gibt es geeignete Entwickler, die diese Lücke füllen können (z.B. die „Bench“ bei IT Softwaredienstleistern). Es gibt in IT Hubs auch Dienstleister, die sehr kurzfristig Personal bereitstellen können, das zunächst als „Leihkraft“ im Team startet, aber dann mit einem eigenen Arbeitsvertrag an das Unternehmen gebunden werden kann. Es ist auch denkbar, Entwickler aus anderen Projekten abzuziehen – das dürfte allerdings eine seltene Ausnahme bleiben, da dies voraussetzt, dass andere Projekte durch derartiges Team Re-Shuffling nicht gefährdet werden.
Fünftens: Im Falle von Fluktuation geht es darum, dass Knowledge nicht verloren geht; gerade bei komplexeren Softwareentwicklungsprojekten ist Zeit für den Knowledge Transfer ein kritischer Engpassfaktor. Darum ist darauf zu achten, dass Kündigungsfristen von Entwicklern/Innen auf deren Bedeutung im Entwicklerteam abgestimmt sind: Je wichtiger ein/e Entwicklerin im Team, je komplexer das Projekt, desto länger sollte die Kündigungsfrist im Arbeitsvertrag eines solchen KnowHow-Trägers sein.
