Entwickler-Onboarding, Das in Woche Eins Liefert

Das Onboarding von Entwicklern wird meist daran gemessen, wie lange die Einführung dauert, und das ist das falsche Ende des Problems. Die Zahl, auf die es ankommt, ist eine andere: wie lange es dauert, bis eine neue Entwicklerin etwas ändern kann und dabei sicher ist, nichts anderes kaputtgemacht zu haben. In den meisten Teams misst sich das in Monaten statt in Tagen.

Die Verzögerung liegt selten an der Person. Sie liegt daran, wie viel vom System ausschließlich in den Köpfen anderer existiert, und daran, wie viel der ersten beiden Wochen damit vergeht, es Unterbrechung für Unterbrechung wieder herauszuholen.

Die eine Kennzahl, die sich zu verfolgen lohnt: wie lange es dauert, bis die erste Änderung in Produktion ankommt. Nicht der erste Commit, der auch eine korrigierte Tippfehlerzeile sein kann, sondern eine Änderung, die zählte und live ging. Dauert das länger als eine Woche, liegt das Hindernis fast nie an der Fähigkeit. Es liegt an einem Einrichtungsprozess, den niemand kürzlich von null durchgespielt hat, oder an einer Codebasis, deren Einstiegspunkte ohne Führung nicht auffindbar sind.

Womit das Entwickler-Onboarding konkurriert

Drei Kosten, und nur eine davon ist die Zeit der neuen Person.

Ihre Zeit, die sichtbare, die alle optimieren. Die Zeit des Teams, denn jede Frage unterbricht jemanden, der gerade etwas anderes tat, und dieser Posten ist größer als der erste. Und die Kosten der nie gestellten Fragen, wenn eine neue Entwicklerin lieber rät, als an einem Vormittag zum fünften Mal zu stören, und der Versuch auf eine Weise falsch ist, die erst zwei Monate später auffällt.

Diese dritte Position ist die, die gutes Onboarding tatsächlich beseitigt. Dokumentation lohnt sich nicht deshalb, weil Lesen schneller ginge als Fragen, sondern weil sie es erlaubt, um elf Uhr abends etwas nachzuschlagen, ohne die soziale Rechnung für die nächste Nachfrage aufzumachen.

Bringen Sie zuerst die Umgebung in Ordnung

Der größte einzelne Faktor für die erste Woche ist, ob das Projekt auf einer frischen Maschine ohne fremde Hilfe läuft.

Teams unterschätzen das durchgängig, weil alle bereits eine funktionierende Umgebung haben und niemand seit zwei Jahren eine neu aufgesetzt hat. Währenddessen verweist das Einrichtungsdokument auf eine Version, die es so nicht mehr gibt, lässt die Umgebungsvariable weg, die jemand im vergangenen Frühjahr ergänzt hat, und setzt Zugriff auf einen Dienst voraus, den die neue Person nie bekommen hat.

Die Abhilfe ist unspektakulär. Lassen Sie die nächste Neueinstellung das Dokument exakt befolgen, ohne etwas zu verändern, und protokollieren Sie jede Stelle, an der es scheitert. Diese Liste ist Ihr tatsächlicher Einrichtungsprozess. Besser noch: Reduzieren Sie ihn auf einen einzigen Befehl, der ein laufendes System mit brauchbaren Testdaten erzeugt, denn jeder manuelle Schritt ist ein Schritt, der wegdriften wird.

Zugänge gehören zur Umgebung. Wer den Code hat, aber nicht die Rechte im Repository, die Zugangsdaten für die Staging-Umgebung oder den Ticket-Tracker, ist nicht eingerichtet. Legen Sie Konten vor dem ersten Arbeitstag an, statt die Lücken am ersten Morgen zu entdecken.

Geben Sie sofort eine echte Aufgabe

Der Impuls, eine neue Person zwei Wochen lang vor echter Arbeit zu schützen, ist gut gemeint und kontraproduktiv. Eine Codebasis ohne Zweck zu lesen lehrt sehr wenig, weil es nichts gibt, woran sich das Gelesene festmachen ließe.

Eine kleine, echte, auslieferbare Änderung am zweiten oder dritten Tag lehrt den gesamten Weg bis zur Auslieferung: wo der Code liegt, wie Tests laufen, wie Reviews funktionieren, wie deployt wird und wem man Bescheid gibt. Genau diesen Weg braucht eine neue Entwicklerin am dringendsten, und genau er steht am seltensten irgendwo geschrieben.

Wählen Sie etwas, auf das ein echter Nutzer wartet, keine erfundene Übung. Menschen merken den Unterschied, und der Unterschied entscheidet darüber, ob sie die Rückmeldung ernst nehmen.

Und arbeiten Sie dann gemeinsam daran. Eine Stunde neben jemandem, der das System kennt, vermittelt mehr als ein Tag Lektüre, und wer dabei die erfahrene Rolle übernimmt, entdeckt meist selbst etwas Neues über die eigene Codebasis.

Was aufgeschrieben gehört und was nicht

Dokumentation verfällt, schreiben Sie also nur, was wahr bleibt und den Pflegeaufwand zurückzahlt.

Lohnt sich: wie man das System aufsetzt und startet, wie man es deployt, welche Form die Architektur hat und warum sie so ist, die Entscheidungen, die sonst immer wieder neu ausgefochten werden, und wer wofür zuständig ist. Unser Leitfaden zur technischen Dokumentation behandelt das Pflegeproblem ausführlicher.

Lohnt sich nicht: alles, was der Code bereits deutlich sagt, Schritt-für-Schritt-Beschreibungen von Bildschirmen, die sich monatlich ändern, und von Hand gepflegte vollständige API-Referenzen. Das veraltet am schnellsten und führt am stärksten in die Irre.

Das wertvollste Dokument ist in den meisten Teams eine kurze Architekturübersicht, die erklärt, welches die großen Bausteine sind und warum sie getrennt wurden. Sie kostet einen Nachmittag, ändert sich selten und beantwortet die Frage, deren Rekonstruktion jede neue Entwicklerin ihre erste Woche kostet.

Onboarding ist ein Test für das Team

Alles, womit eine neue Person kämpft, ist etwas, das das Team unsichtbar mitgetragen hat.

Wenn die Einrichtung drei Tage dauert, waren diese Kosten immer schon da, bezahlt in kleinen Raten von allen, die je eine Maschine neu aufgesetzt haben. Wenn niemand erklären kann, warum eine Komponente existiert, kostet diese Unklarheit längst Entscheidungen. Wenn der Deployment-Prozess eine bestimmte Person braucht, war diese Abhängigkeit schon vorher ein Risiko, und es ist dasselbe, das in der technischen Due Diligence und in jedem ernsthaften Notfallplan zutage tritt.

Behandeln Sie die ersten Wochen also als kostenloses Audit. Bitten Sie die neue Person, alles aufzuschreiben, was sie verwirrt hat, und behandeln Sie diese Liste als Backlog, nicht als Aussage über ihre Fähigkeiten. Es ist die ehrlichste Beschreibung Ihres Systems, die jemand je liefern wird, denn nach zwei Monaten fällt es auch ihr nicht mehr auf.

Mecanik steigt im Rahmen unserer Arbeit in der Softwareentwicklung regelmäßig in bestehende Codebasen ein, führt diesen Test also beruflich an fremden Systemen durch. Die Teams, die schnell einarbeiten, sind nicht die mit der besten Dokumentation. Es sind die, in denen jemand kürzlich seine Umgebung neu aufgesetzt und repariert hat, was dabei zerbrach.

Häufig gestellte Fragen

Wie lange sollte das Entwickler-Onboarding dauern? Messen Sie die Zeit bis zur ersten bedeutsamen Änderung in Produktion, nicht die Länge der Einführung. Dauert das länger als eine Woche, liegt das Hindernis selten an der Fähigkeit. Meist liegt es an einem Einrichtungsprozess, den niemand kürzlich von null durchgespielt hat, oder an einer Codebasis, deren Einstiegspunkte ohne Führung nicht zu finden sind.

Was sollte eine neue Entwicklerin in den ersten Tagen tun? Eine kleine, echte, auslieferbare Änderung, auf die ein echter Nutzer wartet. Eine Codebasis ohne Zweck zu lesen lehrt wenig, weil der Bezugspunkt fehlt, während eine einzige echte Änderung zeigt, wo der Code liegt, wie Tests laufen, wie Reviews funktionieren, wie deployt wird und wem man Bescheid gibt.

Warum dauert das Einrichten der Umgebung so lange? Weil alle bereits eine funktionierende haben und niemand seit Jahren von null aufgesetzt hat, driftet das Dokument weg. Die Abhilfe: Die nächste Neueinstellung folgt ihm exakt, verändert nichts und protokolliert jedes Scheitern. Diese Liste ist der echte Prozess, und ihn auf einen einzigen Befehl zu reduzieren verhindert das nächste Wegdriften.

Welche Dokumentation lohnt sich für das Onboarding? Wie man das System aufsetzt und startet, wie man deployt, welche Form die Architektur hat und warum, Entscheidungen, die sonst neu ausgefochten werden, und wer wofür zuständig ist. Sparen Sie sich alles, was der Code schon sagt, Beschreibungen monatlich wechselnder Bildschirme und handgepflegte API-Referenzen.

Was verrät ein langsames Onboarding über ein Team? Dass die Kosten, die das Team unsichtbar getragen hat, real sind. Drei Tage Einrichtung wurden immer schon in kleinen Raten von allen bezahlt, die eine Maschine neu aufsetzten. Eine Komponente, die niemand begründen kann, kostet längst Entscheidungen. Ein Deployment, das nur eine Person ausführen kann, war schon vor der Neueinstellung ein Risiko.