Die ersten 30 Tage der Zusammenarbeit planen: Beobachten, entscheiden, nachsteuern

Vor dem Start die Voraussetzungen auf Kundenseite klären

Die ersten Wochen zeigen oft, ob eine Rolle zum Bedarf passt. Sie verlaufen aber nur dann aussagekräftig, wenn die Fachkraft eine konkrete Aufgabe, erreichbare Ansprechpartner und die nötigen Zugänge erhält. Ein Kalender mit Lieferterminen ersetzt keine Vorbereitung. Halten Sie deshalb fest, was die Person in der ersten Woche beobachten darf, wer Fragen beantwortet und welche Freigaben fehlen.

• Aufgabe eingrenzen: Nennen Sie ein reales Arbeitspaket und die fachlichen Kriterien, an denen Sie eine gute Lösung erkennen.
• Kontaktpersonen bestimmen: Wer priorisiert Produktarbeit, wer beantwortet fachliche Fragen, wer prüft Änderungen und wer entscheidet über Abnahme?
• Arbeitsumgebung einrichten: Bereiten Sie Entwicklungsumgebung, Testdaten, Zugang zu Dokumentation, Kommunikationskanäle und nötige Berechtigungen vor.
• Arbeitsregeln vereinbaren: Klären Sie gemeinsame Arbeitszeiten, Sprache, Rückmeldeweg, Besprechungen und Umgang mit blockierten Aufgaben.
• Entscheidungen erreichbar machen: Legen Sie fest, wer Fragen vertritt, wenn die primäre Ansprechperson ausfällt.
• Abbruch- und Wechselweg kennen: Prüfen Sie die schriftlichen Bedingungen für Testphase, Wechsel und Beendigung, bevor die Arbeit startet.

Wenn ein Zugang nicht rechtzeitig freigegeben werden kann, benennen Sie eine sichere Ersatzaufgabe. Nutzen Sie keine echten Kundendaten, wenn Testdaten genügen. Der erste Arbeitstag sollte nicht davon abhängen, dass eine einzelne Person spontan alle Hindernisse beseitigt.

Die 30 Tage als vier kurze Lernabschnitte nutzen

Der folgende Vorschlag ist ein Beobachtungs- und Entscheidungsplan. Er verspricht keine bestimmte Menge an Code, Funktionen oder Geschäftsergebnis. Passen Sie ihn an Rolle, Zugangsfreigaben, verfügbare Zeit und Ihren Vertrag an.

Vereinbaren Sie wöchentlich ein kurzes Gespräch mit denselben Leitfragen. Halten Sie Beobachtungen von Bewertungen getrennt. „Zugang zur Testumgebung fehlte an drei Tagen“ ist beobachtbar; „die Zusammenarbeit ist schlecht“ ist ein Urteil, das Kontext braucht.

Fiktiver Verlauf: ein Kundenblocker wird sichtbar

Fiktives Beispiel, keine Division5-Kundenreferenz: Eine externe Backend-Entwicklerin soll einen Zahlungsstatus im Kundenportal ergänzen. Sie erhält das Repository am ersten Tag, aber noch keinen Zugriff auf die Testumgebung und keine Beschreibung der fachlichen Statuswerte. Das Arbeitspaket ist deshalb zunächst nicht umsetzbar.

Im Wochenprotokoll steht: „Tag 1: Repository-Zugang vorhanden. Testzugang und Beispielantwort der Zahlungs-API fehlen. Kundenseitige Ansprechpartnerin klärt beides bis Mittwoch. Bis dahin liest die Entwicklerin die bestehende Statusverarbeitung und dokumentiert Rückfragen.“ Am Mittwoch ist die Testumgebung freigegeben, die Statuswerte sind weiterhin unklar. Die Product Ownerin entscheidet am Donnerstag, welche zwei Status zum ersten Umfang gehören. Damit wird die ursprüngliche Blockade aufgeteilt in eine gelöste Zugangsfrage und eine fachliche Entscheidung.

Ende der zweiten Woche prüft das Unternehmen nicht nur, ob Code erstellt wurde. Es fragt, ob die Aufgabe passend eingegrenzt war, wie Review und Fehlerbehandlung liefen und ob die Verantwortlichen erreichbar waren. Wenn Rückmeldungen wiederholt zu spät kommen, muss der Kunde seine Entscheidungswege ändern. Wenn die Person trotz geklärtem Kontext die vereinbarten technischen Anforderungen nicht erfüllt, kann das ein Hinweis auf fehlende Passung sein. Beides wird anhand von konkreten Ereignissen besprochen.

Wöchentliche Fragen für beide Seiten

• Welche Aufgabe war diese Woche klar, welche musste nachträglich erklärt werden?
• Welche Entscheidung oder welcher Zugang hat Arbeit aufgehalten? Wer kümmert sich darum?
• War die vereinbarte Rückmeldung rechtzeitig und verständlich?
• Welche Qualitätsprüfung wurde durchgeführt, und was bleibt noch offen?
• Welche Beobachtung spricht dafür, dass Rolle und Aufgabe zusammenpassen?
• Welche einzelne Änderung würde die nächste Woche erleichtern?
• Gibt es ein Risiko, das nicht durch mehr Arbeitsstunden gelöst wird?

Notieren Sie pro Punkt eine Beobachtung, eine verantwortliche Person und bei Bedarf einen Termin. Ein Entscheidungssatz kann lauten: „Wir setzen die Zusammenarbeit fort und legen für die nächste Woche einen kleineren API-Umfang fest, weil die fachliche Freigabe bisher länger als erwartet dauert.“

Eine Testphase ist kein Liefer- oder Beschäftigungsversprechen

Für alle Fachkräfte gilt bei Division5 eine 30-tägige Testphase. Halten Sie vor dem Start die konkreten Bedingungen schriftlich fest. Für EOR gelten die im jeweiligen Angebot beschriebenen Beschäftigungsbedingungen.

Division5 gleicht Profile mit Ihrer Anfrage ab. Sie können die geprüften Profile und aufgezeichneten Interviews schon vor dem Kennenlernen ansehen. Der deutsche Ansprechpartner und Vertragspartner ist die PIRATE GmbH in Köln. Profile und Interviews vorab ansehen oder Aufgabe und Rolle besprechen.