Wie erkennt man den Austausch von Senioren durch Junioren in einem IT-Projekt

## Wie Dienstleister Senior-Entwickler durch Juniors ersetzen – und wie man es erkennt

Bei einem Projekt mit einem externen IT-Dienstleister ist die Entwicklungsgeschwindigkeit mehrmals eingebrochen – Aufgaben, die früher zwei Tage dauerten, ziehen sich jetzt über Wochen hin. Der Grund liegt nicht an technischem Schuldenberg oder Architekturkomplikationen, sondern daran, dass ein Drittel der Senior-Entwickler leise durch Juniors ersetzt wurde. Das ist kein Einzelfall: Solche Vertauschungen werden zur systemischen Praxis auf dem GUS-Markt, besonders wenn der Kunde nach dem Start die Teamzusammensetzung nicht überwacht.

Warum die Vertauschung unbemerkt bleibt

Die Vertauschung von Spezialistenstufen geschieht selten auf einmal. Dienstleister gehen schrittweise vor: Ein Senior wird "auf ein anderes Projekt versetzt", ersetzt durch einen "fast Senior" mit tollem Lebenslauf, dann ein weiterer im nächsten Monat. Der Kunde sieht in den Berichten die gleiche Teamstruktur, dieselben Namen in Jira, aber das tatsächliche Skill-Level der Ausführenden sinkt. Formal – alles nach Vertrag, tatsächlich – Täuschung.

Schlüsselfaktoren, die dieses Schema ermöglichen:

• Fehlende Pflicht zur Kundenfreigabe von Wechseln.
• Fokus auf formale Metriken (Stunden, Tasks im Sprint), nicht auf Code-Qualität und Lösungstiefe.
• Unzureichende Einbindung des technischen Leiters oder Architekten des Kunden.

Projekte sind besonders anfällig, wo der Kunde die gesamte technische Verantwortung an den Dienstleister delegiert, ohne regelmäßige Code-Reviews und Audits. Wenn niemand prüft, wer den Code schreibt und wie, bleibt die Vertauschung bis zum kritischen Einbruch der Velocity unbemerkt.

Wie man die Vertauschung vor der Krise erkennt

Man kann das Problem lange vor dem Terminchaos entdecken. Hier die wichtigsten Indikatoren:

• Verlangsamung der Velocity ohne objektive Gründe – wenn die Task-Komplexität nicht gestiegen ist und kein technischer Schuldenberg wächst, aber Tasks langsamer abgeschlossen werden, ist das das erste Signal.
• Anstieg von Nacharbeiten und Bugs – Junior-Entwickler machen mehr Fehler, die behoben werden müssen. Steigt der Bug-Anteil aus QA oder Produktion – prüfen, wer sie schreibt.
• Rückgang der Code-Qualität – Auftreten von Anti-Patterns, Ignorieren von Standards, Fehlen von Tests, wo sie früher waren.
• Erhöhte Belastung der verbleibenden Seniors – wenn Schlüsselentwickler plötzlich "jeder hilft", kompensieren sie vielleicht das niedrige Level der Neulinge.
• Veränderung im Kommunikationston – Juniors stellen weniger Architekturfragen, fordern öfter konkrete Anweisungen, meiden komplexe Tasks.

Regelmäßige Code-Reviews, Pair-Programming mit Beteiligung eines Kundenvertreters und Analyse von Metriken (z. B. zyklomatische Komplexität, Abdeckung, Churn-Rate) helfen, das Problem früh zu erkennen.

Was tun: Präventive Maßnahmen und Reaktion

Wenn Sie eine Vertauschung bemerkt haben – keine Panik, systematisch die Kontrolle zurückgewinnen. Hier ein schrittweiser Aktionsplan:

• Technischen Audit durchführen – nicht nach Lebensläufen, sondern nach echtem Code und Commit-History. Wer hat welche Module angefasst? Wie oft? Welche Qualität?
• Transparenz bei Wechseln wiederherstellen – Vertragsklausel einfügen, die dem Dienstleister vorschreibt, jeden Spezialistenwechsel mit dem technischen Vertreter des Kunden abzustimmen.
• Seniors in Schlüsselrollen zurückholen – wenn Budget da ist, Juniors durch Middles/Seniors ersetzen. Sonst Tasks umverteilen: Juniors nur klar abgegrenzte, gut dokumentierte Code-Abschnitte überlassen.
• Technische Aufsicht einsetzen – schon ein Architekt oder Tech Lead vom Kunden mit wöchentlichen Reviews senkt das Risiko um 80 %.
• Team-KPIs überarbeiten – statt reiner Stunden und geschlossener Tickets Qualitätsmetriken einführen: Bugs pro Commit, Nacharbeitszeit, Änderungsabdeckung.

Warnsignale auf dem Markt

Die Situation verschärfen einige Dienstleister, die dieses Schema bewusst als Geschäftsmodell nutzen: Kunden mit Senior-Team zu Marktraten anlocken, dann schrittweise durch günstigere Spezialisten ersetzen und Marge halten. Besonders häufig in hochkonkurrenzfähigen Regionen mit Preißdruck.

Zwei harte Regeln zum Schutz:

• Stundensatz unter 25 $/h für Senior – Warnsignal. Auf dem GUS-Markt arbeitet ein echter Senior nicht günstiger als diese Marke. Zu gut klingendes Angebot – Level per Testaufgabe oder Live-Coding prüfen.
• Kein Tech Lead oder PM vom Dienstleister – Risiko. Ein Team ohne technische Führung neigt stärker zur Skill-Degradation. Tech Lead ist natürlicher Filter gegen unqualifizierte Wechsel.

Wichtige Erkenntnisse

• Seniors durch Juniors zu ersetzen ist kein Fehler, sondern bewusste Strategie mancher Dienstleister zur Margensteigerung.
• Erste Anzeichen: Velocity-Rückgang, Bug-Anstieg, Code-Qualitätsabfall – treten lange vor der Krise auf.
• Schutz: Pflichtfreigaben für Wechsel, regelmäßige Code-Reviews, Tech Lead auf Kundenseite.
• Marktsatz unter 25 $/h für Senior im GUS – fast immer Betrug.
• Prävention schlägt Heilung: Besser Kontrollen beim Start einbauen als das Projekt nach sechs Monaten zu retten.

Vertrauen Sie nicht blinden Berichten. Prüfen Sie, wer wirklich Ihren Code schreibt – heute, nicht vor sechs Monaten. Ihr Projekt hängt nicht von schicken Lebensläufen ab, sondern von den echten Händen an der Tastatur.

— Editorial Team