Kapazität des Entwicklungsteams: Was vor der Einstellung eines Entwicklers zu prüfen ist

Der Termin für die Aktion steht bereits fest, doch die Änderungen am Warenkorb schaffen es wieder nicht ins Release. In der Aufgabenliste ist alles als dringend markiert, der technische Leiter ist ständig ausgelastet, und die einfachste Lösung scheint ein weiterer Entwickler zu sein. Doch die Kapazität des Entwicklungsteams hängt nicht allein von der Zahl der Mitarbeiter ab. Wartet fertiger Code auf eine Prüfung, den Zugang zur Testumgebung oder eine Entscheidung über Rabatte, kann ein neuer Entwickler lediglich die Warteschlange verlängern.

Klären Sie vor der Stellenausschreibung, was genau für das nächste nützliche Release fehlt: Zeit für die Umsetzung, eine bestimmte Kompetenz oder die Möglichkeit, bereits begonnene Arbeit abzuschließen. Das sind unterschiedliche Probleme mit unterschiedlichen Budgets. Im Folgenden erfahren Sie, wie Sie diese anhand Ihres eigenen Onlineshops unterscheiden und eine begründete Entscheidung über eine Verstärkung vorbereiten können.

Benennen Sie zuerst das Ergebnis, das nicht beim Kunden ankommt

„Wir haben zu viele Aufgaben“ ist eine schwache Begründung für eine Einstellung. „Wir schaffen es nicht, die Bezahlfunktion für Geschäftskunden bis zum vereinbarten Start bereitzustellen“ ist dagegen eine analysierbare Situation. Wählen Sie eine geschäftliche Änderung und betrachten Sie ihren Weg: Wer präzisiert die Regeln, wer schreibt den Code, wer prüft ihn, wer nimmt das Ergebnis ab und wer gibt die Veröffentlichung frei? So wird sichtbar, wo eine zusätzliche Fachkraft tatsächlich selbstständig handeln kann.

Stellen Sie den tatsächlichen Weg der Änderung in einem einfachen Diagramm dar, einschließlich der Rückläufe zur Nacharbeit. Die DORA-Methode zur Abbildung des Arbeitsflusses hilft, Wartezeiten und Übergaben zwischen den Beteiligten zu erkennen. Für ein erstes Gespräch genügen ein Board und die Aufgabenhistorie; ein separates Analysesystem muss dafür nicht gekauft werden.

Trennen Sie Arbeit von Wartezeit

Wählen Sie eine kleine Gruppe kürzlich bearbeiteter, vergleichbarer Änderungen an einem Shop. Vermischen Sie nicht den Austausch eines Banners, eine Zahlungsintegration und die Wiederherstellung nach einem Ausfall: Diese Arbeiten haben unterschiedliche Abhängigkeiten. Betrachten Sie neben abgeschlossenen auch unvollendete Änderungen, sonst verschwinden die längsten Verzögerungen aus der Beobachtung. Rekonstruieren Sie für jede Änderung die Daten der Statusübergänge und die Gründe für Unterbrechungen.

Hilfreich ist die Unterscheidung zwischen aktiver Arbeitszeit und Wartezeit. Der Status „im Test“ bedeutet nicht, dass ein Tester ununterbrochen daran arbeitet. Darin können eine Warteschlange, fehlende Testdaten und die Klärung des erwarteten Verhaltens stecken. Gibt es keine genauen Aufzeichnungen, bitten Sie die Beteiligten, den Ablauf zu rekonstruieren, und kennzeichnen Sie Schätzungen als ungefähr. Machen Sie aus ungenauen Erinnerungen keine Rangliste der Mitarbeiter.

• Halten Sie fest, wann die Aufgabe klar genug für den Beginn war, wann die Umsetzung begann und wann sie zur Prüfung übergeben wurde.
• Erfassen Sie separat die Wartezeiten auf Code-Review, Testumgebung, die Antwort eines angebundenen Systems und die fachliche Abnahme.
• Markieren Sie Rückläufe: Ein Implementierungsfehler, eine geänderte Regel und ein übersehener Anwendungsfall erfordern unterschiedliche Lösungen.
• Ergänzen Sie ungeplante Arbeiten: Störungsbehebung, Beratung und Unterstützung anderer Teams, auch wenn dafür keine Tickets angelegt wurden.

Suchen Sie nach einer wiederkehrenden Stelle, an der sich Arbeit staut, nicht nach dem auffälligsten Einzelfall. Wird ein Entwickler regelmäßig für Supportaufgaben unterbrochen, kann dahinter ein tatsächlicher Kapazitätsmangel stecken, der im Plan für neue Funktionen nicht sichtbar ist.

Vier Warteschlangen, die wie Entwicklermangel aussehen

Prüfen Sie vor der Einstellung, was eigentlich wächst: der Vorrat an klar definierten Aufgaben oder die Zahl offener Fragen. Die folgende Tabelle ist eine Diagnosehilfe und kein automatischer Befund aufgrund eines einzelnen Symptoms.

Review: Geschriebener Code hat den Durchsatz noch nicht erhöht

Prüft ein einziger technischer Leiter alle Änderungen, erzeugt ein zusätzlicher Codeautor auch zusätzlichen Bedarf an dessen Aufmerksamkeit. Sehen Sie nach, ob der Prüfer eine kompakte Änderung mit Erläuterung oder ein großes Paket mit mehreren voneinander unabhängigen Funktionen erhält. Vereinbaren Sie Zeit für Reviews, eine Dringlichkeitsreihenfolge und eine fachkundige Vertretung für den jeweiligen Systembereich.

Eine Warteschlange beim Code-Review bedeutet nicht immer langsame Kommunikation. In GitHub können Regeln für geschützte Branches die Freigabe durch bestimmte Codeverantwortliche und erfolgreich durchlaufene automatische Prüfungen verlangen. Ermitteln Sie die tatsächliche Ursache der Blockierung. Schutzregeln abzuschalten, damit ein neuer Mitarbeiter Tickets schneller schließen kann, ist kein Weg, den Nutzen der Einstellung nachzuweisen.

Anforderungen und Zugänge: Neue Mitarbeiter übernehmen dieselben Blockaden

Die Formulierung „Händlerrabatt hinzufügen“ lässt Fragen zur Kombination mit einem Gutscheincode, zur Rundung und zur Preisquelle offen. Hier braucht es Abnahmekriterien für Änderungen, nicht ein zweites Paar Hände zum Rätselraten. Der Product Owner muss das erwartete Verhalten abstimmen, der Entwickler die technischen Abhängigkeiten erkennen. Übertragen Sie kaufmännische Entscheidungen nicht allein deshalb auf einen Bewerber, weil er erfahren ist.

Prüfen Sie die Zugänge zu Repository, Protokollen und Testumgebung: Ein neues Teammitglied muss das Projekt starten und den vereinbarten Ablauf mit zulässigen Daten nachstellen können. Dafür muss weder die produktive Bestelldatenbank geöffnet noch ein gemeinsam genutztes Administratorkonto vergeben werden.

Wie Sie die Hypothese ohne neue Stellenausschreibung prüfen

Wählen Sie ein wiederkehrendes Hindernis und ändern Sie die Bedingungen für die nächste vergleichbare Arbeit. Das ist ein kleines Managementexperiment: Es soll zeigen, ob das Beseitigen der Blockade hilft, Funktionen bis zum Nutzer zu bringen. Legen Sie die Dauer anhand Ihres Releasezyklus fest, nicht nach einem pauschalen Versprechen, „den Prozess in einer Woche zu reparieren“.

1. Beschreiben Sie die Ausgangslage: Welche Änderungen verzögern sich, an welchem Übergang und wodurch ist das belegt?
2. Vereinbaren Sie eine Maßnahme, etwa ein reserviertes Zeitfenster des Prüfers oder einen fertigen Testdatensatz. Benennen Sie eine verantwortliche Person.
3. Begrenzen Sie parallele Arbeit im problematischen Schritt. Beginnen Sie nichts Neues, nur damit alle beschäftigt aussehen.
4. Verfolgen Sie die nächsten vergleichbaren Änderungen bis zur Abnahme und Veröffentlichung. Erfassen Sie Wartezeiten, Rückläufe und die Einbindung des technischen Leiters.
5. Vergleichen Sie das Ergebnis mit der Ausgangsbeobachtung und prüfen Sie, ob sich die Warteschlange lediglich zum Testen oder zur fachlichen Freigabe verlagert hat.

DORA empfiehlt, Support, Besprechungen und technische Schulden bei der verfügbaren Kapazität zu berücksichtigen und Begrenzungen der gleichzeitig laufenden Arbeit anzuwenden. Es geht nicht darum, Menschen ohne Aufgaben zu lassen: Freie Aufmerksamkeit hilft, blockierte Arbeit abzuschließen. Ein Entwickler kann beispielsweise Testdaten vorbereiten oder eine zu große Änderung aufteilen, statt noch eine Funktion zu beginnen.

Wann ein zusätzlicher Entwickler tatsächlich sinnvoll ist

Eine Verstärkung ist gerechtfertigt, wenn ausreichend abgestimmte Arbeit, ein klar abgegrenzter Verantwortungsbereich und Personen vorhanden sind, die das Ergebnis abnehmen können. Ein eigener Grund ist eine fehlende Fähigkeit: Das Team betreut beispielsweise das Shop-Frontend, hat aber keine Erfahrung mit einer benötigten Integration. Ein Generalist ersetzt hier nicht zwangsläufig einen Spezialisten für das konkrete System und dessen Betrieb.

Definieren Sie die Rolle über das Ergebnis: „Den abgestimmten Austausch von Bestellstatus umsetzen und an die Betriebsbetreuung übergeben“ statt „bei allem helfen“. Bei Magento oder Adobe Commerce sollten in der Anfrage Edition, Version, Bereitstellungsmodell und die von der Arbeit betroffenen Komponenten genannt werden. Das Wort Magento allein reicht nicht, um die Projektumgebung und die Erwartungen an den Entwickler zu beschreiben.

Bewerten Sie den Einarbeitungsaufwand für den Entwickler: Einrichtung der Umgebung, Erläuterung der Architektur, gemeinsame Besprechung der ersten Änderung und Zeit für Reviews. Die kalendarische Verfügbarkeit einer neuen Person bedeutet nicht sofortige Selbstständigkeit. Steht das Release bereits morgen an, kann eine Verringerung des Umfangs oder die Verschiebung einer unkritischen Funktion realistischer sein als die Erwartung eines unmittelbaren Nutzens durch eine Einstellung.

Eine dauerhafte Stelle eignet sich für einen langfristigen Bedarf, ein begrenzter Einsatz für eine bestimmte Kompetenz oder eine vorübergehende Belastung. Fehlen jedoch gleichzeitig Analyse, Tests und Releasemanagement, sollten diese Aufgaben nicht in einer einzigen Programmiererstelle gebündelt werden. Die Beschaffung von Leistungen wird separat im Beitrag zur Auswahl eines Dienstleisters mit RFI, RFP oder RFQ behandelt; hier beginnt die Entscheidung früher, nämlich mit der Bestimmung der fehlenden Rolle.

Beispiel: Eine neue Versandart steckt vor einer Aktion fest

Ein hypothetisches Beispiel: Ein Shop führt die Lieferung an eine Abholstelle ein, doch die Aufgabe geht mehrmals zurück in die Bearbeitung. Zunächst scheint der Entwickler nicht hinterherzukommen. Die Analyse zeigt etwas anderes: Für den Test fehlt eine geeignete Adresse, die Geschäftsseite hat noch nicht entschieden, was nach einer Ablehnung durch den Lieferdienst angezeigt werden soll, und der Prüfer ist erst nach Abschluss anderer Arbeiten verfügbar.

Für eine solche Aufgabe wird zunächst das Verhalten abgestimmt: Der Kunde wählt eine Abholstelle, die Adresse wird in die Bestellung übernommen, und bei Nichterreichbarkeit des Dienstes gibt es eine verständliche Meldung und einen zulässigen Alternativweg. Ein Vertreter des Lieferdienstes bestätigt den Testfall, der Shopinhaber nimmt die Regel ab, und der technische Leiter plant das Review. Das ersetzt keine Programmierung, beseitigt aber das Arbeiten auf bloßen Verdacht.

Wie Sie die Verstärkung nach der ersten abgeschlossenen Änderung bewerten

Vereinbaren Sie einen Nutzennachweis für den Einsatz: Die Änderung ist abgenommen, veröffentlicht und an die Betriebsbetreuung übergeben. Vergleichen Sie ähnliche Arbeiten am selben Produkt: Auch ein geringerer Aufgabenumfang oder das Ausbleiben von Störungen können eine Beschleunigung erklären.

Verwechseln Sie den gesamten Weg von ausgereiften Anforderungen bis zum Start nicht mit der DORA-Kennzahl change lead time: Letztere misst die Zeit vom Festschreiben einer Änderung im Versionskontrollsystem bis zur Bereitstellung in der Produktionsumgebung. Beide Messungen sind nützlich, beantworten aber unterschiedliche Fragen. Für eine Personalentscheidung müssen auch die Wartezeiten vor der ersten Codeänderung sichtbar sein.

Beobachten Sie neben der Dauer die Qualität der veröffentlichten Änderungen und die Belastung des Mentors. Mehr Releases mit häufigen Notfallkorrekturen bedeuten keine nachhaltige Verstärkung. Prüfverfahren und die Wiederherstellung eines funktionsfähigen Systems werden im Beitrag über sichere Releases im Onlineshop erläutert. Streichen Sie diese nicht aus dem Plan, um die Geschwindigkeitsstatistik zu verbessern.

Die Entscheidung des Inhabers: Für die Beseitigung der Ursache bezahlen

Zum Budget einer Verstärkung gehört nicht nur die Vergütung des Entwicklers. Berücksichtigen Sie Aufgabenanalyse, internes Mentoring, Tests, Umgebungen und Betreuung nach dem Release. Zum Budget von Prozessänderungen gehören die Zeit der Verantwortlichen und die Arbeiten zur Beseitigung von Blockaden. Vergleichen Sie Varianten für dasselbe Ergebnis: Was kostet es, die benötigte Funktion bis zur Abnahme zu bringen, und nicht, was eine Arbeitsstunde verschiedener Personen kostet?

GL.ua (Глянець) ist auf Drupal spezialisiert: Die Betreuung umfasst funktionale Erweiterungen, Tests und Integrationen. Für einen Drupal-Shop lassen sich ein konkreter Entwicklungsplan und technische Abhängigkeiten besprechen statt einer abstrakten Teamvergrößerung. Für einen Magento-Shop sollten Sie einen entsprechend spezialisierten Fachmann suchen: Die Analyse des Arbeitsflusses hilft unabhängig von der Plattform, dessen Aufgabe zu formulieren.

Beginnen Sie mit einem Release, seinen Warteschlangen und Zuständigkeiten. Wenn Ihr Drupal-Shop Verstärkung benötigt, besprechen Sie mit GL.ua die technische Betreuung und Weiterentwicklung der Website: Ergänzen Sie Ihre Anfrage um eine Beschreibung der benötigten Änderung, bekannte Blockaden und Abnahmebedingungen. Das ist eine konkrete Grundlage für die Einschätzung von Arbeiten, Zeitrahmen und erforderlichen Rollen.