Software-Agentur · Entwicklung
Entwickler-Onboarding in ein Kundenprojekt
Bringen Sie einen Entwickler, der in ein laufendes Projekt einsteigt, schnell zu einer ersten gemergten Änderung, ohne Tage für Zugänge und Einrichtung zu verlieren. Der Kunde stimmt dem neuen Teammitglied über einen öffentlichen Link zu und richtet Zugänge ein, und Sprint-Arbeit bleibt gesperrt, bis der Engineering Lead bestätigt, dass der Entwickler bereit ist.
- Dauer: 1 bis 2 Wochen
- Wie oft: Jedes Mal, wenn ein Entwickler in ein Projekt einsteigt
- Schritte: 9 Schritte
- KI-Agenten: 1 KI-Agent
- Freigaben: 1 Freigabe
Kostenloser Plan, keine Kreditkarte nötig.
Was sich mit dieser Vorlage ändert
Ohne Vorlage
Der neue Entwickler wartet tagelang auf Zugänge vom Kunden.
Die Einrichtungsanleitung ist veraltet, und jeder Neue verliert einen Tag damit.
Onboarding besteht aus einem Call und einem Link zum Repository.
Der Kunde erfährt in einer Sprint-Demo von einem neuen Teammitglied.
Mit der Vorlage
Der Kunde stimmt zu und richtet Zugänge über einen Link ein, vor dem Starttermin.
Jeder Entwickler notiert die Lücken, und die Anleitung wird aktualisiert, bevor er freigegeben wird.
Ein Buddy führt den Entwickler durch den Code und reviewt seine erste Änderung.
Der Kunde stimmt jedem neuen Entwickler zu, bevor dieser Zugang bekommt.
Die Vorlage, Schritt für Schritt
Jeder Schritt zeigt, wer ihn erledigt: jemand aus Ihrem Team, ein KI-Agent oder der Kunde über einen öffentlichen Link. Eine Freigabe hält alle folgenden Schritte gesperrt, bis sie erteilt ist.
- Erledigt von Ihrem Team
- Erledigt von einem KI-Agenten
- Erledigt vom Kunden, über einen öffentlichen Link
Beginnt, wenn
Ein Entwickler steigt in ein laufendes Kundenprojekt ein, neu im Unternehmen oder aus einem anderen Projekt. Der Projektmanager startet eine Ausführung mit dem Namen des Entwicklers und dem Starttermin.
- 1
Entwickler ankündigen und Kunden-Link teilen
Vor Tag 1Projektmanager · Team
Mailen Sie dem Kunden, wer ab wann, in welcher Rolle und mit welcher E-Mail-Adresse einsteigt, und senden Sie den öffentlichen Link für seine Zustimmung und die Zugänge, die er einrichten muss.
Checkliste
- Vertrag erlaubt die Änderung im Team
- Vertraulichkeitsvereinbarung vom Entwickler unterschrieben
- Öffentlichen Link an den Kunden gesendet
Auszufüllende Felder
- Name des Entwicklers (Pflichtfeld)
- E-Mail des Entwicklers (Pflichtfeld)
- Starttermin im Projekt (Pflichtfeld)
- 2
Kunde stimmt zu und richtet Zugänge ein
Vor Tag 1Ansprechpartner beim Kunden · Öffentlicher Link
Über den öffentlichen Link stimmt der Kunde dem neuen Teammitglied zu und richtet Zugänge zu seinen Systemen ein, oder er notiert, was vorher passieren muss, etwa seine eigene Sicherheitsschulung.
Checkliste
- Zugang zum Code-Repository eingerichtet
- Zugang zur Staging-Umgebung eingerichtet
- Kundenkonten oder VPN eingerichtet
Auszufüllende Felder
- Zustimmung (Pflichtfeld)
- Bedingungen vor dem Zugang
- 3
Zugänge und lokale Umgebung einrichten
Tag 1 bis 2Entwickler · Team
Nehmen Sie jede Einladung an, richten Sie das Projekt nach der Einrichtungsanleitung lokal ein und notieren Sie, wo die Anleitung falsch oder unvollständig war. Fehlt ein Zugang, markieren Sie die Ausführung als blockiert und notieren Sie, welcher.
Checkliste
- App läuft lokal
- Tests laufen lokal
- Staging und Issue-Tracker funktionieren
Auszufüllende Felder
- Lücken in der Einrichtungsanleitung
- 4
Durch den Code führen
Tag 2 bis 3Onboarding-Buddy · Team
Führen Sie den Entwickler durch Architektur, wichtigste Abläufe, Deployment und Teamkonventionen, und stellen Sie ihm die Ansprechpartner und festen Termine des Kunden vor.
Checkliste
- Architektur und wichtigste Abläufe erklärt
- Regeln für Branches, Reviews und Releases erklärt
- Ansprechpartner und Termine des Kunden vorgestellt
Auszufüllende Felder
- Themen zum Nacharbeiten
- 5
Eine erste kleine Änderung liefern
Tag 3 bis 5Entwickler · Team
Wählen Sie mit dem Buddy ein kleines Ticket, setzen Sie es mit Tests um und eröffnen Sie einen Pull Request.
Checkliste
- Ticket mit dem Buddy vereinbart
- Tests ergänzt
- Pull Request eröffnet
Auszufüllende Felder
- Link zum Pull Request (Pflichtfeld)
- 6
Die erste Änderung gemeinsam reviewen
Im öffentlichen Link ausgeblendetTag 4 bis 5Onboarding-Buddy · Team
Reviewen Sie den Pull Request mit dem Entwickler, erklären Sie das Feedback und mergen Sie ihn, wenn er den Standards des Teams entspricht.
Checkliste
- Mit dem Entwickler reviewt
- Feedback erklärt
- Gemergt
Auszufüllende Felder
- Worauf er sich als Nächstes konzentriert
- 7
Bereitschaft prüfen
Im öffentlichen Link ausgeblendetTag 5Bereitschaftsprüfer · KI-Agent
Der Bereitschaftsprüfer vergleicht Checklisten und Felder aller vorherigen Schritte mit der Onboarding-Liste aus seinen Anweisungen, nennt, was noch offen ist, und schreibt eine kurze Zusammenfassung zur Bereitschaft.
Auszufüllende Felder
- Offene Punkte
- Zusammenfassung zur Bereitschaft (Pflichtfeld)
Geprüft von: Der Engineering Lead schließt die offenen Punkte und bestätigt die Bereitschaft in Schritt 8.
- 8
Bestätigen, dass der Entwickler bereit ist
Im öffentlichen Link ausgeblendetTag 5Engineering Lead · Team
Lesen Sie die Zusammenfassung, schließen oder planen Sie die offenen Punkte und bestätigen Sie, dass der Entwickler Sprint-Arbeit übernehmen kann.
Checkliste
- Offene Punkte geschlossen oder geplant
- Einrichtungsanleitung um die gefundenen Lücken ergänzt
Freigabe: Sprint-Arbeit bleibt gesperrt, bis der Engineering Lead bestätigt, dass der Entwickler bereit ist.
- 9
Entwickler in den Sprint aufnehmen und Kunden informieren
Woche 2Projektmanager · Team
Nehmen Sie den Entwickler in den nächsten Sprint und in die Teamliste des Projekts auf, und informieren Sie den Kunden, dass das Onboarding abgeschlossen ist.
Checkliste
- In die Sprint-Planung aufgenommen
- In die Teamliste aufgenommen
- Kunde informiert
Auszufüllende Felder
- Start des ersten Sprints (Pflichtfeld)
Fertig, wenn
Der Entwickler hat funktionierende Zugänge, kennt den Code und hat eine erste Änderung reviewt und gemergt, und der Kunde weiß, wer dazugekommen ist.
Passen Sie sie an. Benennen Sie Schritte um, ändern Sie Verantwortliche und ergänzen Sie Checklistenpunkte, Felder oder Freigaben. Die Vorlage ist ein Ausgangspunkt für die Arbeitsweise Ihres Teams.
Die KI-Agenten in dieser Vorlage
Ein Agent arbeitet nur an seinen eigenen Schritten, und jemand aus Ihrem Team prüft, was er getan hat. Alles, was ein Agent in eine verbundene App schreibt, wartet auf Freigabe, sofern Sie es nicht ausdrücklich erlauben.
Bereitschaftsprüfer
Prüft, was im Onboarding noch offen ist, und fasst zusammen, wo der Entwickler steht.
Was er tut
- Liest Checklisten und Felder aller vorherigen Schritte
- Vergleicht sie mit der Onboarding-Liste aus seinen Anweisungen
- Nennt offene Punkte und schreibt eine kurze Zusammenfassung zur Bereitschaft
- Schließt seinen Schritt ab, damit der Engineering Lead prüfen kann
Geprüft von: Der Engineering Lead schließt die offenen Punkte und bestätigt die Bereitschaft in Schritt 8.
Fragen, die diese Vorlage beantwortet
Holen Sie zuerst Zustimmung und Zugänge vom Kunden ein, dann folgen lokale Umgebung, Code-Einführung und eine kleine erste Änderung. Diese Vorlage führt das der Reihe nach durch, von der Zustimmung des Kunden in Schritt 2 bis zur Prüfung durch den Engineering Lead in Schritt 8.
Peilen Sie eine kleine, reviewte Änderung in der ersten Woche an, damit Probleme mit der Umgebung und Wissenslücken früh sichtbar werden. In Schritt 5 liefert der Entwickler eine erste kleine Änderung mit Tests, und in Schritt 6 reviewt der Onboarding-Buddy sie mit ihm.
Sagen Sie dem Kunden, wer ab wann einsteigt, und lassen Sie ihn zustimmen, bevor Zugänge vergeben werden. In Schritt 2 stimmt der Kunde dem neuen Teammitglied über den öffentlichen Link zu und richtet Zugänge ein, oder er notiert zuerst seine Bedingungen.
Lassen Sie jeden neuen Entwickler ihr Wort für Wort folgen und festhalten, wo sie falsch war. In Schritt 3 notiert der Entwickler die Lücken in der Einrichtungsanleitung, und in Schritt 8 prüft der Engineering Lead, ob die Anleitung aktualisiert wurde.
Lassen Sie KI prüfen, was im Onboarding noch offen ist, und das zusammenfassen, und lassen Sie die Entscheidung beim Engineering Lead. In Schritt 7 nennt der Bereitschaftsprüfer die offenen Punkte und schreibt eine Zusammenfassung, und Schritt 8 ist eine Freigabeprüfung, in der der Engineering Lead bestätigt, dass der Entwickler bereit ist.
Geben Sie jedem Wechsel dasselbe Onboarding, mit Buddy und Bereitschaftsprüfung, statt eines kurzen Übergabe-Calls. In Schritt 4 bis 6 führt der Onboarding-Buddy den Entwickler durch den Code und reviewt seine erste Änderung, und die Ausführung zeigt, was behandelt wurde.
Führen Sie diesen Workflow in OKiDO aus
Richten Sie Schritte, Verantwortliche und Freigaben einmal ein und starten Sie dann für jeden neuen Fall eine Ausführung.