Shopware-Freelancer Onboarding: Wie Agenturen aus der ersten Projektwoche das Maximum holen

1. Zugänge vor Tag eins, nicht am Tag eins

Die häufigste vermeidbare Reibung sind Zugänge, die noch nicht existieren, wenn der Freelancer das erste Mal die IDE öffnet. Git-Repository, Shopware-Backend, Staging-Server, Logging-Tool, Ticket-System, Passwort-Manager, Slack — jedes fehlende Login frisst zwischen zehn Minuten und einem halben Tag, je nachdem wer im Urlaub ist.

Das Minimum-Set, das vor dem ersten Tag stehen sollte: Lese- und Schreibrechte am Repository, Admin-Zugang zum lokalen Dev-Backend (oder zumindest dem Staging), eine eigene Datenbank-Connection für lokales Arbeiten, und ein Account im Ticket- oder PM-System mit der Übersicht über die zugewiesenen Aufgaben.

Was sich bewährt: eine Onboarding-Checkliste im Repository selbst — als ONBOARDING.md oder im README — die alle benötigten Zugänge und Tools auflistet. So sieht der Freelancer am ersten Tag selbst, was fehlt, und kann gezielt nachfragen, statt jeden Zugang einzeln zu rekonstruieren.

2. Lokales Setup in unter zwei Stunden

Ein Shopware-6-Projekt lokal lauffähig zu bekommen ist nicht trivial. PHP-Version, Node-Version, MySQL-Variante, Redis, OpenSearch, MinIO, Mailhog — die Liste der Abhängigkeiten ist je nach Projekt-Setup lang. Wenn jeder Freelancer das selbst aus der Plugin-Liste rückwärts ableiten muss, gehen schnell ein bis zwei Tage drauf.

Das Ziel sollte sein: git clone, ein Befehl, lauffähiges Backend. In der Praxis erreicht man das mit DDEV, Docker Compose oder einem dedizierten Devbox-Script. Welche Variante egal ist — die Hauptsache ist, dass sie im Repository liegt und reproduzierbar funktioniert.

Ergänzend hilft ein Demo-Datensatz: ein anonymisierter SQL-Dump mit Beispielprodukten, einer Handvoll Bestellungen und mindestens je einem B2B- und B2C-Kunden. Ohne realistische Daten lassen sich viele Bugs nicht reproduzieren — und der Freelancer fragt entweder nach einem Prod-Dump (Datenschutz-Thema) oder klickt sich Daten manuell zusammen.

3. Eine kurze Architektur-Tour, kein Wikipedia-Artikel

Ausführliche Architektur-Dokumentationen werden selten gelesen. Was tatsächlich hilft, ist ein 30- bis 45-minütiges Walkthrough — entweder live per Screen-Share oder als kurzer Loom-Mitschnitt — durch die fünf bis zehn wichtigsten Stellen im Code:

• Wo liegen die Custom Plugins?custom/plugins/ oder, bei Composer-installierten Plugins, vendor/ — und welche davon sind eigene, welche fremde?
• Wie ist die Storefront-Theme-Struktur?Eigenes Theme, geerbtes Theme, Admin-Theme, Frontend-Build-Pipeline.
• Welche externen Systeme sind angebunden?ERP, PIM, Payment, Versand, CRM — und wo läuft das jeweils technisch durch (Plugin, Symfony Messenger, Cron, externer Service)?
• Welche Subscriber, Decorators, Custom Entities existieren?Genau die Stellen, an denen Shopware-Default-Verhalten umgebogen wurde — und damit die Stellen, die ein Freelancer bei seinem ersten Bug am häufigsten betreten wird.

Diese Tour beantwortet zehn Fragen, die der Freelancer sonst eine ganze Woche lang einzeln stellt — und ist gleichzeitig der schnellste Weg, ihm zu zeigen, wo die echten Eigenarten des Projekts liegen.

4. Erste Aufgabe: klein, abgeschlossen, repräsentativ

Die erste Aufgabe entscheidet, wie schnell der Freelancer ankommt. Sie sollte drei Eigenschaften haben: klein genug, um in zwei bis drei Tagen abgeschlossen zu werden; abgeschlossen genug, um ohne weitere Abstimmung mergebar zu sein; repräsentativ genug, um die wichtigsten Tool-Pfade zu durchlaufen — Repo klonen, Branch erstellen, lokal testen, Pull Request öffnen, Code Review, Merge, Deployment.

Schlecht geeignet für die erste Woche: ein Greenfield-Feature, an dem noch fünf Architekturentscheidungen offen sind. Oder ein vager Bug, den niemand reproduzieren kann. Oder etwas, das ein Code-Review von drei Stakeholdern braucht, die alle erst nächste Woche zurück sind.

Gut geeignet: ein abgegrenzter Bug mit klarem Reproduktionsweg, ein kleines isoliertes Feature in einem bestehenden Plugin, eine Refactoring-Aufgabe in einer überschaubaren Datei. Idealerweise etwas, das man am Freitag deployen kann — das schafft auf beiden Seiten das Gefühl, dass die Woche etwas gebracht hat.

5. Eine klare Eskalations-Linie

Wenn der Freelancer in den ersten Tagen einen Blocker hat — fehlender Zugang, kaputter Build, unklare Anforderung — muss klar sein, wer angesprochen wird, und wie schnell mit einer Antwort zu rechnen ist.

In Agenturen mit zehn parallelen Projekten ist das nicht trivial. Der Projektleiter ist im Kunden-Workshop, der Lead-Entwickler im Sprint-Planning, der DevOps in einem Incident — und die Frage, ob ein bestimmtes Plugin auf Staging schon deployt ist, bleibt drei Stunden im Slack stehen.

Was hilft: eine benannte Person als technischer Ansprechpartner, die in der ersten Woche bewusst freie Slots für den Freelancer hat. Idealerweise jemand, der das Projekt gut kennt — und nicht nur die Person, die zufällig in der Channel-Mitgliederliste oben steht. Plus eine klar kommunizierte Antwortzeit für nicht-dringende Rückfragen (z.B. "innerhalb von vier Stunden während der Kernarbeitszeit").

6. Conventions, die niemand sonst erwähnt

Jedes Projekt hat ungeschriebene Regeln, die für das interne Team selbstverständlich sind und für einen Außenstehenden unsichtbar bleiben — bis sie beim ersten Pull Request angemerkt werden:

• Branch-Namensschemafeature/SW-1234-kurze-beschreibung oder PROJEKT/123/kebab-titel?
• Commit-Message-FormatConventional Commits, JIRA-Ticket-Prefix, oder freier Text?
• PR-Template & Review-ErwartungenWer reviewt, wie viele Approvals werden gebraucht, gibt es Pflicht-Felder im PR-Body, ist Squash-Merge oder Merge-Commit Standard?
• Plugin-Version vs. Composer-VersionWird die Version in composer.json, CHANGELOG_de-DE.md oder beidem gepflegt? Gibt es ein Skript, das Versionen synchronisiert?

Eine kurze CONTRIBUTING.md mit drei bis fünf solcher Punkte spart in der ersten Woche mehr Zeit als jedes Architektur-Dokument.

7. Was Agenturen vom Freelancer erwarten dürfen

Onboarding ist keine Einbahnstraße. Ein erfahrener Shopware-Freelancer sollte in der ersten Woche selbst proaktiv vorgehen: Setup-Probleme dokumentieren, statt sie zu umgehen; bei der ersten Aufgabe lieber einmal zu viel nachfragen als eine Annahme falsch interpretieren; Lücken in der vorhandenen Doku direkt mit einem kleinen PR füllen, statt sie als Excuse für Verzögerungen zu nutzen.

Konkret: Wer am Mittwoch der ersten Woche immer noch keinen lokalen Build laufen hat und am Donnerstag das erste Mal davon im Standup berichtet, hat seinen Teil des Onboardings nicht erfüllt. Die Initiative, früh zu eskalieren, gehört zur Senior-Erwartung dazu.

Wenn beide Seiten ihren Teil vorbereiten, ist eine produktive erste Woche realistisch — sogar bei einem komplexen Shopware-Projekt mit zehn Custom Plugins und einer ERP-Anbindung. Ohne diese Vorbereitung wird die erste Woche fast immer eine reine Setup-Woche, und die Agentur zahlt die Stunden für etwas, was sie selbst hätte schneller liefern können.

Was du vor der ersten Anfrage wissen solltest — welche Fragen du klären musst, welche Projekttypen besonders gut für externe Unterstützung geeignet sind — erkläre ich ausführlich im Artikel Shopware 6 Freelancer für Agenturen: Was du wirklich brauchst.