Besserer Weg, um neue Mitarbeiter auszubilden [geschlossen]

Das Team, in dem ich mich gerade befinde, hat einen relativ hohen Umsatz, wobei Mitglieder normalerweise zu verschiedenen Projekten innerhalb desselben Unternehmens wechseln. Derzeit besteht unsere "Schulung" für neue Mitglieder darin, sie mit einem Hauptkontakt (normalerweise der jüngsten Person, die ihre Schulung abgeschlossen hat) zu verbinden, der ihnen praktische Erfahrung vermittelt und mehr leitende Entwickler fragt, ob die neuere Einstellung den Mentor etwas fragt weiß es nicht. Es bietet dem neuen Mitarbeiter die Möglichkeit, sich schnell zu engagieren, und fordert den Mentor auf, auch sein Verständnis des Systems zu verbessern.

Wie Sie sich vorstellen können, ist diese Art des Trainings jedoch sehr zeitaufwändig und bietet keinen sehr guten Wissenstransfer (Missverständnisse breiten sich aus, Lücken vergrößern sich).

Ich wurde beauftragt, Dokumentationen und Schulungsmaterialien für unsere zukünftigen Neueinstellungen zu erstellen. Ich mache bereits gelegentlich technisches Schreiben, aber es ist für den Endbenutzer und sehr spezifisch mit vielen Screenshots und nimmt viel Zeit in Anspruch.

Das Erstellen der neuen Dokumentation für Neueinstellungen wird als niedrige Priorität angesehen, und ich habe derzeit nur ca. 40 Stunden Zeit, um daran zu arbeiten. Wenn ich das System so dokumentiere, wie ich es derzeit schreibe, würde die technische Dokumentation in 40 Stunden kaum die Oberfläche zerkratzen. Vor allem, wenn man bedenkt, dass ich nicht nur über die Codebasis, sondern auch über Bereitstellungen und Support dokumentieren muss.

Wie kann ich schnell Unterlagen schreiben, um neue Mitarbeiter so schnell wie möglich auf den neuesten Stand zu bringen, ohne viel Zeit in das Schreiben der Unterlagen zu investieren?

Zusätzliche Informationen:
Wir haben derzeit sowohl ein Wiki als auch einige Schulungsunterlagen, beide sind jedoch eher spärlich.

Gute Frage. Die Ausbildung von Programmierern am Arbeitsplatz wird sehr selten ernst genommen und es wird auch nicht oft darüber gesprochen.

Einige Ideen, die ich gesehen habe, funktionieren gut:

• Haben Sie in Ihrem Wiki ein neues Rampup-Dokument (das, das Sie schreiben). Beschreiben Sie in diesem Dokument die Aufgaben, die der neue Mitarbeiter in den ersten 1-2 Wochen ausführen wird. Wo ich arbeite, gibt es von Anfang an viel zu wissen, von interner Software / Tools über Prozesse bis hin zu Orten mit bestimmten Arten von Informationen. Bearbeiten> Wir haben Anweisungen wie "x, y, z in der richtigen Reihenfolge installieren" mit Screenshots zur Konfiguration usw. Wenn Sie also ein System oder eine Farm (VMs) mit Win Server, SQL Server, SharePoint, BizTalk konfigurieren, ist unsere Software nicht so einfach wie sie Geräusche. Dies gilt für die anderen Versionen der von uns unterstützten Anwendungen.
• Übungsprobleme. Wo ich bin, haben wir ein Produkt, das eine groß angelegte API verfügbar macht. Daher ist es für uns immer von Vorteil, unsere eigene Produktdokumentation durchzugehen, um (vorab festgelegte) Erweiterungen zu schreiben, so wie es unsere Kunden / Kunden tun würden. Wenn Sie also eine Mathematikbibliothek als Teil der API Ihres Produkts hatten, haben Sie ein Übungsproblem: "Schreiben Sie einen Taschenrechner mit unserer API" oder ähnliches.
• Mentoren sind gut. Behalte sie. Wir machen das auch hier und es ist nicht nur eine gute Möglichkeit, Leute zu treffen / Freunde zu finden, sondern sie sind auch als Lernquelle von unschätzbarem Wert. Ich empfehle , dass es nicht die letzte Person ist, die die Schulung beendet, da sie nicht über die Unternehmenswissensgeschichte verfügt, die eine andere Person möglicherweise hat. Lassen Sie es alle bei einer Rotation machen.
• Wir machen (ungefähr) wöchentliche Präsentationen / Tech Talks. Lassen Sie die neuen Mitarbeiter etwas aus Ihrem Produkt auswählen (oder zuweisen) und nach der 3. Woche eine Präsentation durchführen. Stellen Sie sicher, dass sie wissen, dass sie falsch liegen können, und das Team kann sie korrigieren, wenn sie irgendetwas in der Präsentation durcheinander bringen.
• Lassen Sie die neuen Mitarbeiter zu Beginn an der Dokumentation arbeiten. Es zwingt sie, es zu lesen.

Wie Dan McGrath bemerkt, ist es eine gute Idee, neue Mitarbeiter zu ermutigen, das Wiki auch für sie zu verbessern.

Zunächst würde ich vorschlagen, dass Sie Ihr neues Einstellungsdokument nicht so gründlich gestalten müssen, wie Sie es für einen Kunden schreiben würden. Es muss technisch genug sein, damit ein neuer Entwickler es als Leitfaden verwenden kann, aber nicht so detailliert, dass es jede Kleinigkeit umreißt. Sie können mit dem Team sprechen, wenn sie schließlich Fragen haben.

Was sind die Top 10 Dinge, die ein neuer Mitarbeiter wissen muss, um für Ihr Team nützlich zu sein? Konzentrieren Sie sich auf diese Dinge. Machen Sie sie zu Ihrer Trefferliste, damit ein neuer Entwickler genug zu tun hat und genügend Informationen, um sie am Laufen zu halten. Wenn Sie zu viele Dinge auf der Liste haben, fragen Sie sich, ob sie dies in den ersten zwei oder drei Wochen tun werden. Wenn sie in dieser Zeit nichts unternehmen, sollte es vielleicht nicht im On-Boarding-Guide stehen.

Stellen Sie für jeden Abschnitt Ihres Leitfadens sicher, dass oben eine Kontaktperson hervorgehoben ist. Auf diese Weise wissen die neuen Mitarbeiter, an wen sie sich wenden können, wenn sie Fragen haben. Stellen Sie außerdem sicher, dass nicht ein Teammitglied für zu viele Abschnitte der Ansprechpartner ist. Sie möchten sich nicht die Zeit einer Person mit neuen Einstellungsfragen nehmen, wenn sie nicht der Mentor ist.

Verbringen Sie nicht Ihre ganze Woche mit diesem Dokument. Lassen Sie sich etwas Zeit, um es anzupassen, nachdem Sie mindestens einen neuen Mitarbeiter eingestellt haben. Sehen Sie, was gut funktioniert, was nicht und beheben Sie es.

Ich habe kürzlich an meinem Arbeitsplatz mit einem ähnlichen Dokument begonnen, mit ähnlichen zeitlichen Einschränkungen. Ich kann nachvollziehen, dass es leicht ist, es auf einer sehr detaillierten Ebene schreiben zu wollen, wie ich es zuerst auch getan habe, aber das könnte tatsächlich kontraproduktiv sein.

Wenn jemand Neues in einer Rolle anfängt, wird er wahrscheinlich in den ersten Wochen mit Informationen überschwemmt. Die anfängliche Ausbildung ist ein Brain Dump eines Entwicklers, der seit mehreren Jahren in einem Unternehmen tätig ist. Meiner Meinung nach wird dies das, was jemand in den ersten Monaten oder sogar im ersten Jahr in dieser Position wissen muss, weitaus komplizierter machen. Halten Sie es auf einem hohen Niveau, versuchen Sie, Standardjargon und -konzepte zu verwenden, und erweitern Sie diese dann mit den Besonderheiten innerhalb der Unternehmensprozesse.

Für mich ist die erste Iteration dieses Dokuments lediglich ein Überblick über den SDLC, den wir an meinem Arbeitsplatz verwenden, mit einer Liste der Rollen, die jedem Schritt zugeordnet sind, einigen Beispielen für Personen, die diese Rollen erfüllen, und spezifischen Checklisten, die damit verbunden sind jeder Schritt des Lebenszyklus auch. Ich persönlich finde Checklisten für Schulungszwecke unverzichtbar, aber auch für fast alles andere, was ich bei der Arbeit mache. Zum Beispiel:

• Der Projektmanager (Joe) weist Ihnen eine Aufgabe in Jira zu.
• Legen Sie eine geschätzte Abschlusszeit für die Aufgabe basierend auf Formel x fest.
• Stellen Sie das Ticket als "in Bearbeitung" ein, wenn Sie mit der Arbeit beginnen.
• Erstellen Sie einen Zweig aus Git. Klicken Sie auf den Link, um ein 30-Sekunden-Video zu diesem Fortschritt anzuzeigen.
• Schreiben Sie Komponententests basierend auf Einschränkungen im Konstruktionsdokument. Auf Seite y finden Sie Namenskonventionen für Komponententests.
• Ticket für die Überprüfung festlegen und Code an das Überprüfungssystem senden. 'Usw.

Ihr neuer Mitarbeiter sollte hoffentlich mit den meisten Konzepten vertraut sein und nun eine schrittweise Anleitung zur Anwendung der Prozesse im Unternehmen haben. Ich mache auch eine kurze Demo des Prozesses von Anfang bis Ende mit realen Dokumenten aus Projekten, die meiner Meinung nach gut ausgeführt wurden.

Wie bereits erwähnt, handelt es sich auch um ein lebendiges Dokument, sodass Abschnitte erweitert werden können, wenn festgestellt wird, dass sie weitere Informationen benötigen. Das gesamte Team sollte daran beteiligt sein, es auf dem neuesten Stand zu halten. Es kann ein Wiki sein, ein OneNote-Dokument, was auch immer, aber etwas, das alle Leute bearbeiten und überprüfen können, und dann andere Leute dazu bringen, es zu verbessern, wenn sie hier und da eine freie Stunde haben. Auf diese Weise tut es eine Person nicht und verbreitet ihren eigenen Einfluss auf alle neuen Mitarbeiter.

Lassen Sie sie nach Überprüfung des Prozesses eine kleine Funktion / Fehlerbehebung für ein nicht geschäftskritisches Projekt durchführen und Fragen stellen, die im Dokument nicht behandelt werden. Notieren Sie, was diese Fragen sind, da sie wahrscheinlich die ersten Dinge sein sollten, die Sie dem Dokument hinzufügen, wenn Sie das nächste Mal daran arbeiten.

Sie können so etwas nicht gut machen, ohne Zeit zu investieren. Zumindest, wenn Sie es selbst tun möchten. Sie sollten sich fragen, ob es wirklich notwendig ist, es so genau zu dokumentieren, wie Sie es versuchen?

Die einzige Alternative wäre, die neuen Mitarbeiter die Hauptaufgabe erledigen zu lassen. Lassen Sie sie einige Teile schreiben. Die Zeit, die Sie für die Korrektur dieser Probleme (in Form von Feedback) aufwenden, ist geringer als in Ihren aktuellen Situationen. Stellen Sie einige gute Vorlagen bereit, und Sie müssen sich keine Gedanken über das Layout machen.

Ich glaube, Sie wissen bereits, dass sie Sie mit einer unmöglichen Mission beauftragt haben. Als Schriftsteller kennen Sie wahrscheinlich bereits das Zitat von Mark Twain:

Wenn ich mehr Zeit hätte, hätte ich weniger geschrieben.

Wenn Sie praktisch keine Ressourcen haben, können Sie wahrscheinlich am besten einen Aktenschrank besorgen und alle bitten, eine Kopie des bereits vorhandenen zu erstellen und die Kopie in den Aktenschrank zu legen. Auf diese Weise können Sie zumindest zu dem neuen Mitarbeiter sagen: "Wenn Sie etwas über das System nachschlagen möchten, befindet sich der Startpunkt im Aktenschrank."

Gutes Schreiben braucht Zeit, Zeit. Darüber hinaus muss es auf die Zielgruppe zugeschnitten sein. Was für Endbenutzer funktioniert, ist nicht das, was ein Programmierer benötigt.

Ganz zu schweigen davon, dass eine gute Ausbildung nicht nur auf schriftliches Material beschränkt ist, sondern auch eine ganze Reihe von Bildungsressourcen umfasst, darunter Online, Klassenzimmer, Multimedia usw.

Wie sie sagen: "Wenn Sie denken, dass Bildung teuer ist, versuchen Sie es mit den Kosten der Unwissenheit."

Darüber hinaus ist es selbstverständlich, dass die Betrachtung der Dokumentation als etwas, das nachträglich zu tun ist, anstatt sie vom ersten Tag an zu einem integralen Bestandteil des Prozesses zu machen, auf ein systemisches organisatorisches Problem hinweist.