Wie man das Onboarding neuer Entwickler_innen automatisiert (und sie bei Laune hält)

  • Veröffentlicht

Ein gutes Onboarding ist wie ein erstes Date – es entscheidet über eine langfristige Beziehung oder über eine schnelle Trennung. Tatsächlich ist die Wahrscheinlichkeit um 58 % höher, dass Mitarbeiter_innen (und damit auch Entwickler_innen) nach drei Jahren noch im Unternehmen sind, wenn sie ein ordentliches Onboarding erhalten.

Leider passiert es am Anfang aber noch immer oft genug, dass neue Entwickler_innen wie verwirrte Touristen in einer fremden Stadt herumirren müssen. Ohne Wegbeschreibung. Ohne Karte. Sie müssen auf eigene Faust durch schmale Gässchen navigieren und tagelang auf Informationssuche gehen (Stichwort: Equipment und Dokumentation). Es ist wie in einer Warteschlange im Supermarkt: Man will eigentlich sofort bezahlen, muss aber warten, bis es endlich weitergeht. Und wenn es dann endlich weitergeht, fällt vielleicht die Kassa aus oder die Bankomatkarte funktioniert nicht. Für Entwickler_innen bedeutet das: Sie müssen sich mit der lokalen Entwicklungsumgebung herumschlagen und die unternehmenseigene Software zum Laufen bringen. Das dauert.

Doch es geht auch anders: Die Einrichtung der Entwicklungsumgebung könnte auch via Knopfdruck per Self-Service funktionieren. Standardisiert. Schnell. Einfach. Aber beginnen wir ganz am Anfang. Mit der Geschichte von Entwicklerin Sarah.

Die Nicht-So-Tolle-Onboarding-Geschichte von Entwicklerin Sarah

Sarah, eine neue Entwicklerin, hat gerade ihre erste Woche in einem neuen Unternehmen begonnen. Sie war aufgeregt: “Traumjob gefunden.” Sie war von Anfang an von dem Unternehmen begeistert.

Doch schon am ersten Tag wurde ihre Vorfreude getrübt. Der versprochene Laptop und Zugangsdaten wurden nicht bereitgestellt. 

Trotz Nachfrage konnte ihr kein genauer Zeitpunkt genannt werden, wann das Equipment bereit steht und sie endlich richtig zu arbeiten anfangen konnte. Sie musste also warten. 

Nach einem Tag war immer noch kein Laptop und keine Zugangsdaten in Sicht. Sarah wurde ungeduldig und fragte noch einmal nach. Ein paar Stunden später wurde ihr endlich ein Laptop und alles weitere ausgehändigt. Der Laptop war allerdings relativ alt und schwach. Aber ok. Zumindest konnte es jetzt losgehen. 

Jetzt ging es an die Einrichtung der lokalen Entwicklungsumgebung – der IDE, die zu entwickelnde Software…eben alles was dazugehört. Das dauerte. Und dauerte. Und dauerte. Die Dokumentation war minimalistisch und teilweise veraltet. Als sie mit einem Kollegen wieder einmal an einem Problem saß, meinte der nur: “Ist halt bei so komplexer Software so. Wir kämpfen regelmäßig mit unseren Entwicklungsumgebungen.” Bis endlich alles funktionierte, vergingen einige Tage. 

Die Einrichtung war dann doch irgendwann abgeschlossen. Aber als nach ein paar Tagen ein Testing-Tool gestartet wurde, schmierte der Laptop komplett ab. Alles umsonst.

Sarah war enttäuscht und frustriert. Sie hatte das Gefühl, dass ihre Zeit verschwendet wurde. Sie fragte sich, ob das Unternehmen und die Software wirklich so gut war, wie sie es sich vorgestellt hatte. Leider ist Sarahs Erfahrung kein Einzelfall. Viele Entwickler_innen haben ähnliche Erfahrungen gemacht.

Technisches Onboarding: Hardware, Software, Dokumentation und Zugangsdaten – Effizienz sieht anders aus

Neben vielen anderen Bereichen ist das “technische” Onboarding wohl einer der Wichtigsten. Denn ohne Equipment und ohne Tools kann nicht gearbeitet werden. Ohne Zugriffsmöglichkeiten auf die Dokumentation oder ein Wiki, das erklärt, wie die Software funktioniert und die Entwicklungsumgebung eingerichtet werden soll, steht alles still. Idealerweise ist alles vorbereitet und funktionstüchtig. In der Praxis sieht es leider meistens etwas anders aus.

Statt eines reibungslosen Starts müssen Entwickler_innen tagelang warten, bis endlich alles vorhanden und funktionstüchtig ist. Und selbst dann stoßen Entwickler_innen auf die nächste Hürde: Die Dokumentation ist auf das Minimalste reduziert, veraltet oder noch schlimmer – es gibt sie gar nicht. Dann müssen Stunden, oft tagelang recherchiert und probiert werden, nur um endlich die lokale Entwicklungsumgebung zum Laufen zu springen. Tatsächlich ist das eine der größten Hürden, um mit der tatsächlichen Arbeit beginnen zu können. 

Probleme mit der lokalen Entwicklungsumgebung setzen sich dann auch noch fort und kosten wertvolle Zeit – so sagen 61 % der befragten Usern in einer Umfrage von GitLab, dass sie zumindest einmal im Monat und 31 % zumindest einmal in der Woche mit Troubleshooting ihrer Entwicklungsumgebung verbringen.

Diesen frustrierenden Prozess haben Entwickler_innen, Manager_innen und auch die HR nicht verdient. Gerade in Zeiten eines Entwickler_innen-Mangels ist es umso notwendiger, von Anfang an eine gute Einarbeitung zu bieten.

Das automatisierte Onboarding mit Remote Development Environments (RDEs)

Remote Development Environments von Cloudomation helfen, das “technische” Onboarding in Sekunden zu erledigen. Mit RDEs stehen Entwicklungsumgebungen sofort und per Mausklick zur Verfügung. Das das ständige Troubleshooting von lokalen Entwicklungsumgebungen wird auf 0 reduziert.

Mehr dazu: Was sind RDEs?

Entwickler_innen können sofort mit der Arbeit beginnen und sich auf das Wesentliche konzentrieren: Das Schreiben von Code. Dafür können sie weiterhin ihre Lieblings-IDE verwenden, da mit Cloudomaton RDEs alle Sourcen über ein File Mount eingebunden werden. Branch wechseln wird zum Kinderspiel, da nur mehr die RDE gewechselt werden muss. Kompilieren, Testing – das wird alles auf einem Remote-Server durchgeführt. Damit ist auch das Ressourcenproblem gelöst. Leistungsschwache Laptops sind kein Problem. Theoretisch können Entwickler_innen auch am Tablet entwickeln.

Für Sarahs Fall hätte das bedeutet: Einen Tag auf das Equipment warten. Aber dann sofort und ohne Wartezeit loslegen können.

Mehr über RDEs im Whitepaper erfahren: Die Produktivität Ihres IT-Teams mit Remote Development Environments auf das nächste Level heben

Für DevOps-Teams sind RDEs ein Traum: Sie definieren RDEs so, wie es für das Unternehmen und die Softwareentwicklung am besten ist. Entwickler_innen können die RDEs dann per Self-Service starten.

Manager_innen erhalten ein System, das Code-Diebstahl vorbeugt, da die RDEs die Möglichkeit bieten, Air-Gapped zu laufen. Mit der Standardisierung ist ein effizientes Arbeiten gewährleistet. 

Und HR? HR kann sich über ein schnelles Onboarding und einen langfristig im Unternehmen bleibende_n Entwickler_in freuen.

Reduzieren Sie die Onboarding-Zeit. Befreien Sie Entwicklerinnen wie Sarah von zeitraubenden Aufgaben. Standardisieren Sie mit Cloudomation RDEs Ihre Entwicklungsumgebungen – Jetzt mehr erfahren.

Jetzt den Cloudomation-Newsletter abonnieren

Werden Sie Cloudomation-Insider. Immer am Ende des Monats neue News zum Thema „Remote Development Environments“ und „DevOps“ erhalten. 




    Johannes Ebner

    Marketing Manager