Hallo Habr! Mein Name ist Andrey Gomenyuk, ich bin der Teamleiter eines der
Badoo Server-Entwicklungsteams.
Beim May
Badoo Techleads Meetup , das sich dem Entwicklungsmanagement widmete,
teilte ich
die Erfahrung der Integration von Neuankömmlingen in das Team. Und heute teile ich eine durch Text ergänzte und verbesserte Version meines Berichts.
Stellen Sie sich vor, heute ist Ihr erster Arbeitstag bei Badoo. Welche Kenntnisse und Fähigkeiten erwartet die Abteilung von Ihnen und insbesondere von mir, dem Leiter? Zumindest solche:

Beachten Sie, dass es nichts Schöneres gibt als "In PHP schreiben" und "MySQL kennen". Wir fragen im Interview danach. Und auf dieser Liste stehen alle unsere Tools, Technologien und Begriffe sowie allgemeine Dinge, die wir höchstwahrscheinlich nicht allen anderen gefallen. Und je früher Sie das alles kennenlernen, desto besser.
Onboarding bei Badoo
Der Begriff
Onboarding bedeutet, eine Person in ein Team aufzunehmen und sie in das Projekt und die Prozesse einzuführen. Da sich unsere Serverentwicklungsabteilung in den letzten Jahren verdoppelt hat (jetzt sind es mehr als vierzig von uns), haben wir uns als erste in Badoo um die intensive Anpassung von Neuankömmlingen und deren Integration in die Arbeit gekümmert.
Ich hebe zwei Hauptziele des Onboarding hervor.
Der erste ist kurzfristig. Wir, wie die meisten IT-Unternehmen, möchten die Person wirklich am ersten Tag auf den Code setzen und ihre Tickets in der ersten Woche in Produktion bringen, damit sich die Person so schnell wie möglich daran gewöhnt. Dies ist jedoch nicht die Hauptsache für uns.
Das zweite Ziel ist langfristig. Wir möchten, dass eine Person so schnell wie möglich ein bestimmtes Maß an
Unabhängigkeit erreicht und beginnt, die Aufgaben effektiv zu lösen.
Dazu führen wir den Anfänger durch fünf nicht sehr explizite Phasen. Bevor ich jedoch der Reihe nach darüber spreche, stelle ich zwei gleich wichtige Punkte fest.
Wer wird den Neuankömmling treffen
Am ersten Arbeitstag treffen wir sicher einen Anfänger. Dies sollte vom Leiter durchgeführt werden, und wir in der Abteilung versuchen, diese Regel einzuhalten. Lead trifft einen Mann, zeigt ihm das Büro und stellt ihn dem Team vor. Anschließend findet ein vorab geplantes Treffen mit der Personalabteilung statt, bei dem Dokumente erstellt werden.
QuelleEs scheint, dass es danach bereits möglich ist, eine Person an den Tisch zu setzen, aber es gibt noch ein weiteres wichtiges Detail.
Wer wird den Anfänger "führen"
In einigen Unternehmen ist der gesamte Onboarding-Prozess an Mentoren gebunden. Dies sind die Leute, die alles erklären, zeigen, was, wo und wie, die Fragen des Anfängers beantworten und ihn mit den richtigen Leuten zusammenbringen.
Wir verwenden keinen solchen Begriff, aber wie das berühmte Lied sagt, gibt es einen Mentor, aber keine Worte. Es ist nur so, dass diese Rolle dem Lead zugewiesen wird, der sie an einen der Mitarbeiter delegieren kann. In der Regel ist ein Lead (oder eine von ihm ernannte Person) ein Ausgangspunkt für einen Anfänger in allen Fragen. In einem kurzen Meeting stellt er den Newcomer in das Projekt vor und spricht über die vom Unternehmen angewandten Prozesse. Dies ist der Beginn des Transfers unserer Kultur auf eine Person, die zuvor in anderen Unternehmen gearbeitet hat und es gewohnt ist, Dinge anders zu machen. Und es ist sehr wichtig, dass der Anfänger versteht, was, wie und
warum wir tun.
Stufen des Onboarding
Ich werde mir erlauben, unseren gesamten Prozess in mehrere Phasen zu unterteilen, von denen jede eine Art Ergebnis hat:
- Mann sitzt an einem Laptop
- mit einer angepassten Arbeitsumgebung
- und macht Tickets.
- Kann eine neue Funktion entwerfen
- und unabhängig arbeiten.
Als nächstes überlegen Sie, was in jeder Phase passiert.
1. Laptop

Erstens möchten wir, dass sich der Anfänger auf die Arbeit konzentriert, anstatt über etwas Unwichtiges nachzudenken, und wir versuchen, im Voraus viel zu tun. Deshalb setzen wir uns vorab mit ihm in Verbindung und finden die Wünsche für die Ausrüstung heraus: was der Monitor, Laptop, Tastatur, Maus wollen. Wir erstellen alle Konten für Anfänger und erteilen Berechtigungen, fügen sie Gruppen und Chats hinzu. Viele dieser Vorgänge sind automatisiert, während andere in Checklisten eingetragen sind, damit die Person am ersten Tag nicht im Büro herumläuft und herausfindet, warum sie nicht in Jira einsteigen kann oder warum sie das ihm zugewiesene Ticket nicht sieht.
2. Arbeitsumgebung
Dann setzt sich die Person an den Laptop, um eine Arbeitsumgebung einzurichten. Aber das ganze Setup ist, dass er in eine spezielle Schnittstelle geht, einen Benutzernamen auswählt und einen SSH-Schlüssel lädt. Fertig.
Tatsache ist, dass wir eine Entwicklungsplattform haben, ein Analogon unserer Produktionsinfrastruktur, die im Büro aufgebaut ist. Darüber hinaus verfügen wir in beiden Büros über eine Entwicklungsplattform, um mehrere DCs zu emulieren: in London und in Moskau. Dieser Ansatz hat viele Vorteile. Der Entwickler hat immer die aktuelle Version des Codes und die neueste Software - absolut die gleiche wie in der Produktion. Auch wenn etwas nicht funktioniert, können Sie sicher sein, dass bereits jemand das Problem löst. Tatsächlich klont der Neuling nur das Repository, öffnet die IDE - und ist bereit zu arbeiten. Es reicht für Lida, um sicherzustellen, dass er in der Lage war, alle Chats zu führen und Post zu erhalten.
Zu diesem Zeitpunkt bin ich bereit, dem Anfänger das erste Ticket zu geben.
3. Tickets
Nehmen wir an, das erste Ticket kam so:

Oder so:

Wahrscheinlich haben diese Tickets für Sie nur eines gemeinsam - nichts ist klar. Ich habe die Wörter, die Ihnen wahrscheinlich die meisten Fragen stellen, orange hervorgehoben, und selbst wenn nicht, werde ich Ihnen trotzdem davon erzählen.

Wie zuvor
Als ich vor sieben Jahren nach Badoo kam, war es so etwas. Lead setzt sich zu dem Neuankömmling und beginnt zu sagen:
„Schauen Sie, wir haben Warteschlangen, ein Skript-Framework. Sie arbeiten so. Achten Sie darauf. In diesem Ticket musst du das tun .
“Das Problem ist, dass der Lead seine Arbeitszeit mit diesen Geschichten verbringt. Jedes Mal, wenn er Anfängern dasselbe erklärt, vergisst er immer etwas. Jeder Lead erzählt seinen eigenen Weg.
Natürlich gibt der Lead nur spezifische einleitende Anmerkungen zum Ticket, die sich auf dieses Ticket beziehen, wobei die Punkte fehlen, die der Anfänger derzeit möglicherweise nicht benötigt. Wenn Sie Glück haben, kann dieser einen Link zu einer Beschreibung eines Werkzeugs finden. In der Regel ist die gesamte Dokumentation jedoch für den internen Gebrauch geschrieben, dh es versteht sich, dass der Benutzer bereits mit den Einzelheiten vertraut ist. Die Dokumentation enthält viele Details, die der Anfänger in den ersten Phasen definitiv nicht benötigt. Infolgedessen entwickelte sich eine paradoxe Situation: Eine Person arbeitete ein oder zwei Jahre im Unternehmen, aber es gibt keine Garantie dafür, dass sie sich mit allem vertraut gemacht hat und weiß, wie die gesamte Infrastruktur funktioniert.
Rahmen aus dem Film Groundhog DayNeben Kollegen, die verschiedene Fragen beantworteten, hielt Aleksey Rybak, der zu diesem Zeitpunkt die Plattform leitete, einen Vortrag über Grundprinzipien, Infrastruktur und grundlegende Dienstleistungen für alle neuen Mitarbeiter. Irgendwann hatte er es satt und nahm es auf Video auf. Aber in einer zweistündigen Geschichte werden Sie nicht alles bekommen, es gibt viele Details. Und dann ist diese Vorlesung sehr schwer zu aktualisieren. Natürlich ist es cool, dass es in sieben Jahren ein wenig veraltet ist, aber einige Teile davon sind nicht mehr relevant.
Irgendwann hat jemand eine Begrüßungsseite für neue Entwickler im Wiki erstellt. Sie warfen dort eine Reihe von Links, die es schön wäre, dem Entwickler vorzulesen.
Ich irre mich wahrscheinlich nicht sehr, wenn ich sage, dass es in einem Unternehmen zwei Hauptquellen gibt, um neue Informationen zu erhalten: Dies ist eine Art Wiki-Analogon (oder Google Text & Tabellen) und ein Raucherzimmer. Leider sind die Informationen nur in einem von ihnen aktuell, und dies ist kein Wiki.
Dass unsere Seite keine gemeinsame Struktur hatte. Es füllte sich so auf. Der Leiter eines anderen Teams kommt auf mich zu und sagt:
„Andryukha, Ihren Entwicklern geht es schlecht. Um es gut zu machen, habe ich einen Artikel im Wiki geschrieben. Fügte es dem "Willkommen neuer Entwickler" hinzu, so dass alle Ihre Entwickler es lesen müssen .
"
Natürlich hält er seinen Artikel für den wichtigsten, platziert ihn an der sichtbarsten Stelle und hebt ihn fett und rot hervor. Infolgedessen wird eine große Seite mit einer Reihe von Links, die er möglicherweise benötigt, auf den Anfänger verschoben. MUSS LESEN und "Lesen erforderlich!" Mit einer Fülle von
fett gedruckten
Sätzen .
Irgendwann wurde uns klar, dass Vorträge, Videos und Wikis nicht mehr zu uns passen. Wir haben uns entschlossen, das Beste aus diesen Tools zu machen und etwas Neues zu machen. Und er warf uns die richtige Idee ... Laravel Framework. Zählen Sie nicht für Werbung. Es ist nur so, dass wir zu dieser Zeit das Framework für ein Projekt aufgegriffen haben, in der Suchmaschine nach dem „besten PHP-Framework“, das Laravel überhaupt aufgetaucht ist, und wir haben es bekommen. Und darin hat uns der Abschnitt mit der Schnellstart-Dokumentation sehr gut gefallen, in dem die Grundprinzipien und verfügbaren Tools anhand eines realen Beispiels erläutert werden (und nachdem Sie die Grundlagen verstanden haben, können Sie mit dem Lesen der detaillierten Beschreibung beginnen).
Schnellstart
Dieses Format hat uns sehr gut gefallen und wir haben beschlossen, einen ähnlichen Artikel für unsere Anfänger zu schreiben. Aber wie geht das? Es gibt viele Informationen - wie kann ein Gleichgewicht zwischen Prägnanz und Informativität aufrechterhalten werden, während die Möglichkeit einer zeitnahen Aktualisierung erhalten bleibt, damit Neuankömmlinge kein Wissen im Raucherraum beziehen müssen? Und wie kann man dazu ermutigen, ein Dokument von Personen zu lesen, die seit einiger Zeit im Unternehmen arbeiten, aber sicherlich Wissenslücken haben?
QuelleWir haben zunächst eine Liste von Tools, Technologien und Ansätzen zusammengestellt, die unserer Meinung nach jeder Entwickler in der Abteilung kennen sollte. Anschließend strukturierten sie die Informationen in Form eines Inhaltsverzeichnisses, von einfach bis komplex: von Datenbanken und Diensten bis hin zu Leistung und Tests. Dann schrieb eine Person die ersten Kapitel, damit andere verstehen konnten, wie das Material präsentiert wird. Danach haben wir die restlichen Themen freiwillig und gewaltsam an andere Mitarbeiter verteilt und jeweils ein Kapitel geschrieben. Das Ergebnis war ein riesiges Dokument, Wochen nur für zwei Lesungen.
Wir konnten keine gemeinsame Aufgabe für den gesamten Schnellstartabschnitt erstellen. Ja, es wäre unwirksam. Stellen Sie sich vor, Sie geben einer Person eine Aufgabe - eine große Funktion, die alle Abschnitte abdeckt. Er wird ein oder zwei Monate daran arbeiten, und die ganze Zeit kann man ihn nicht mit Tickets ablenken, und dies widerspricht dem ersten Zweck des Onboarding.
Dann haben wir in jedem Abschnitt eine oder zwei Aufgaben platziert, die den realen so ähnlich wie möglich sind. Ein Anfänger liest einen Abschnitt, arbeitet an Aufgaben, macht sich mit bestimmten Werkzeugen vertraut. Wir empfehlen unseren Führungskräften, einige der Aufgaben gemäß dem Standardprozess auszuführen: Ein Ticket wird ausgestellt, eine Person drückt einen Code, ein Code wird überprüft, eine Person erhält viel Feedback. Danach wird die Filiale gelöscht und damit ein Ticket.
Dann stellte sich die Frage, wie die Relevanz dieser gesamten Information aufrechterhalten werden kann. Und hier haben uns die gleichen Aufgaben geholfen. Zum Beispiel haben wir Spots (virtuelle Shards) und einen Dienst, der für den Vergleich von Benutzern und Spots verantwortlich ist. Im normalen Leben müssen Entwickler dies nicht wissen, da sie eine API auf hoher Ebene verwenden. Sie müssen jedoch verstehen, wie dies intern funktioniert.
Wir geben die Aufgabe: Registrieren Sie den Benutzer beim Entwickler, erhalten Sie die Spot-ID an seiner E-Mail-Adresse, holen Sie sich die Datenbankinformationen vor Ort, gehen Sie dort hinein, wählen Sie aus und sehen Sie, was dort ist. Wenn sich an diesem Verfahren etwas ändert, wissen normale Entwickler nichts davon. Sie werden nicht wissen, dass Sie die Beschreibung korrigieren müssen. Aber der Entwickler, der sich gerade damit beschäftigt, wird verstehen: etwas stimmt nicht. Er wird an die Spitze gehen und sagen, dass etwas nicht funktioniert. Der Lead wird sich mit ihm zusammensetzen, es klären - und wir werden das Dokument aktualisieren. Wir versuchen, Entwickler nicht zu ermutigen, den Schnellstart selbst zu ändern, um die Struktur und den Stil der Präsentation nicht zu verletzen. Stattdessen haben wir ein Google Doc erstellt, in das sie ihre Wünsche eintragen können. Diese Liste wird dann von der verantwortlichen Person überprüft, die Änderungen an unserem Artikel vornimmt.
Neue Informationen werden auf die gleiche Weise zu Quick Start hinzugefügt: Jemand stößt auf ein neues Tool, das nicht im Dokument beschrieben ist, und schreibt darüber in Google Doc. Und die Verantwortlichen entscheiden dann, ob dies ein Sonderfall ist, der für die meisten Entwickler nicht interessant ist, oder ob es sich lohnt, in Quick Start darüber zu schreiben.
Die Entwickler selbst fügen dem Dokument manchmal coole "kleine Dinge" hinzu. Beispielsweise wurde jedem Kapitel ein Zähler für die Lesedauer und die Anzahl der Seiten hinzugefügt. Außerdem wurden in einigen Abschnitten Links hinzugefügt, die die gewünschte Klasse in PhpStorm sofort öffnen.
Dann begannen wir zu überlegen, wie wir die alten Leute dazu bringen könnten, das Dokument zu studieren. Immerhin stellte sich der Schnellstart als riesig heraus, und niemand wollte zwei Wochen damit verbringen, ihn zu lesen. Dann haben wir uns einen Test ausgedacht: Auf der Grundlage des Dokuments haben wir ungefähr 100 Fragen zu verschiedenen Themen gestellt, und jedem wurde angeboten, ihn anonym zu bestehen. Jeder Entwickler hatte die Wahl zwischen ungefähr 40 Fragen. Das Ziel war nicht, Wissen zu testen, sondern den Menschen zu helfen, zu verstehen, was sie nicht wussten. Das heißt, der Test war ein Lernwerkzeug, kein Test, und wenn die Frage nicht richtig beantwortet wurde, wurden sofort Eingabeaufforderungen und Links angeboten, über die Sie im Schnellstart lesen können.
Ein Beispiel für eine Frage aus einem TestWir kontrollieren nicht den Durchgang des Tests durch Anfänger. Es wird angenommen, dass dies für sie die logische Schlussfolgerung für das Erlernen des Schnellstarts ist. Gleichzeitig führen wir Statistiken zu allen Antworten. Als die "alten Männer" den Test bestanden haben, haben wir einige Fragen ausgewählt, die sie nicht so beantwortet haben, wie wir es möchten, und erfahrene Leute gebeten, Artikel zu diesen Themen zu schreiben.
Schnellstart und Test sind der beeindruckendste Teil unseres Onboarding-Prozesses.
Weitere Tickets
Normalerweise erhält eine Person zusammen mit dem Schnellstart sofort ein oder zwei einfache Tickets. Allmählich steigt ihre Anzahl und der Lead stellt sicher, dass die neuen Tickets dem entsprechen, mit dem sich der Entwickler vertraut gemacht hat. Somit wird der Lesevorgang mit echter Arbeit verdünnt und alles zusammen dauert ungefähr zwei Monate. Idealerweise sollte die Person am Ende des Testzeitraums mit unserer Infrastruktur, unseren Tools und Ansätzen vertraut sein.
Nachdem Sie Quick Start gelesen haben, wird Ihnen die Bedeutung der oben genannten Tickets viel klarer:

Als Hinweis muss ich mir hier nur eine kleine Einführung geben: Es gibt ein Feld an der Stelle und ein Feld im Dienst, sie sind nicht für den Benutzer synchronisiert; Sie müssen den Fehler beheben und synchronisieren. Und der Anfänger weiß bereits, welches Skript auszuführen ist und wie dies zu tun ist.
Oder ein zweites Beispiel:

Hier das gleiche: Das Foto landete im falschen Album, höchstwahrscheinlich hat der Kunde einfach das falsche Album gesendet; Sie müssen verstehen, ob es noch solche Fälle gibt, und es beheben.
Tickets sind in der Tat einfach, für eine Stunde Arbeit.
4. Entwerfen einer neuen Funktion
Mit „Entwerfen“ meine ich nicht die Organisation von Klassen und Code, sondern wie der Anfänger mit Daten arbeitet, wo er Tabellen erstellt, welche Ereignisse er hinzufügt, wo sie übertragen werden, auf welche Dienste eine Person zugreifen wird. Zu diesem Zeitpunkt ist der Anfänger bereit, technische Entscheidungen darüber zu treffen, wie Funktionen ausgeführt werden. Dies wird normalerweise durch Übung erreicht. Je mehr Aufgaben, desto mehr Wissen und Erfahrung.
Dies ist zwar nicht immer möglich, da nicht für jeden Anfänger eine ausreichende Anzahl interessanter Aufgaben gefunden werden kann. Im Test sind solche Themen oft schwer zu behandeln, da die Situationen unterschiedlich sind. In verschiedenen Fällen müssen Sie auf verschiedene Dienste und überall auf Ihre eigenen Merkmale zugreifen.
Als Ergebnis haben wir einfach ein Dutzend wirklich großer Funktionen gesammelt, die verschiedene Dienste, Warteschlangen, Spots umfassten, und die Entwickler haben kurze Beschreibungen für sie erstellt (ein Analogon zur technischen Aufgabe). Wenn der Neuankömmling bereit ist, hat der Lead die Wahl zwischen einer Aufgabe. Er denkt einige Zeit darüber nach und berichtet, dass er bereit ist, die Lösung zu besprechen. Es ist ein Treffen mit dem Autor des Features geplant, bei dem der Entwickler sein Schema erklärt: Er würde dies tun, einen solchen Dienst in Anspruch nehmen, die Daten hier speichern und solche Ereignisse abonnieren. Als Antwort erzählt der Autor, wie er es getan hat und worauf er aufmerksam gemacht hat. Infolgedessen lernt der Entwickler viele neue Dinge, er beginnt, das allgemeine Bild aufzunehmen. Er versteht, wie dieser oder jener Prozess funktioniert, wie wir Entscheidungen treffen. Es ist in Ordnung, wenn er im Voraus in den Code eingetreten ist und ausspioniert hat, wie die Funktion implementiert ist. Dies ist sogar noch wahrscheinlicher ein Plus.
Am Ende des Meetings sammelt der Lead Feedback und kann dem Entwickler anbieten, einen Abschnitt sorgfältig zu studieren und über das nachzudenken, was er gelernt hat.
5. Selbständige Arbeit
Die fünfte Stufe wird in keiner Weise ausgedrückt. Dies sind die Dinge, die wir während unserer Arbeit im Unternehmen tun. Wir schätzen den Wunsch des Entwicklers sehr, mit anderen Teams zu kommunizieren und herauszufinden, wie das funktioniert. Wenn etwas nicht funktioniert, müssen Sie wissen, an wen Sie sich wenden können, um Hilfe zu erhalten. Die Aufgabe des Leads ist es, den Neuankömmling allen vorzustellen, zu zeigen, wer wo sitzt, wem und in welchem Fall Sie Kontakt aufnehmen können.
QuelleEine Person sollte in unseren Prozessen angeleitet werden. Obwohl wir Scrum und Agile nicht haben, ist der Workflow recht flexibel. Wir wissen es wirklich zu schätzen, wenn ein Entwickler unsere Prozesse nicht nur gedankenlos verfolgt, sondern auch versteht, warum sie sind und welche Aufgaben er löst. Dies ermöglicht es ihm in einigen Situationen, Problemumgehungen zu finden. Zum Beispiel, um zu verstehen, dass ein bestimmtes Ticket gesendet werden kann, ohne vollständige Tests durchzuführen, und das andere muss schneller erledigt werden.
Wir sagen, an wen Sie sich wenden und wie Sie Prioritäten setzen müssen, damit das Ticket heute funktioniert.Wir erwarten vom neuen Entwickler, dass er sich während des Testzeitraums mit dem maximalen Satz unserer Funktionen und Komponenten vertraut macht. Wenn die Probezeit endet, kennt er im Idealfall eine Komponente oder Funktion, die tief genug ist, um sie begleiten zu können.Wir fügen der Leistungsüberprüfung auch sofort eine Person hinzu , damit sie nicht nur von ihrem Lead, sondern auch von jedem, mit dem er interagiert, Feedback erhält: vom Produkt-, QS- und Kundenteam.Zusammenfassung
Hier sind vielleicht die fünf Hauptkomponenten unseres Inbetriebnahmeprozesses für Neulinge:- . , ( ) .
- Quick Start. , . , , .
- . Quick Start, .
- .
- . , .
Ergebnisse
, . , , , «» .
.
. - . , , — .
QuelleWas weiter
— Quick Start , , . Quick Start.
, . Quick Start , , , , , , . , - . , . , .
Erinnern Sie sich schließlich an das erste Bild mit einer Reihe von Begriffen? Sie haben wahrscheinlich gedacht: "Warum so viel?" Es sieht so aus, als wäre alles zu kompliziert für uns und der Entwickler muss wahrscheinlich nicht alles darüber wissen. Beim Lesen von Quick Start ist es sehr einfach, Dinge zu erkennen, die vereinfacht werden können, und wir arbeiten in diese Richtung.