Jak wykryć podmianę seniorów na juniorów w projekcie IT

Jak vendorzy podstawiają juniorów zamiast seniorów i jak to wykryć

Na projekcie z zewnętrznym podwykonawcą IT tempo rozwoju spadło kilkukrotnie — zadania, które wcześniej zajmowały dwa dni, teraz ciągną się tygodniami. Przyczyna nie tkwi w technicznym długu czy skomplikowaniu architektury, lecz w tym, że jedną trzecią senior developerów dyskretnie zastąpiono juniormi. To nie pojedynczy przypadek: takie podstawienia stają się systemową praktyką na rynku WNP, zwłaszcza gdy klient nie kontroluje składu zespołu po starcie.

Dlaczego podstawienie odbywa się niezauważalnie

Podstawienie poziomu specjalistów rzadko jest nagłe. Vendorzy działają stopniowo: jednego seniora "przenoszą na inny projekt", na jego miejsce przychodzi "prawie senior" z dobrym CV, po miesiącu — kolejny. Klient widzi tę samą strukturę zespołu w raportach, te same imiona w Jira, ale rzeczywisty poziom wykonawców spada. Formalnie — wszystko zgodnie z umową, faktycznie — oszustwo.

Kluczowe czynniki, które pozwalają tej schemacie działać:

• Brak obowiązkowego uzgadniania zastępstw ze strony klienta.
• Orientacja na formalne wskaźniki (godziny, zadania w sprincie), a nie na jakość kodu i głębię rozwiązań.
• Niewystarczające zaangażowanie technical leada lub architekta po stronie klienta.

Szczególnie narażone są projekty, w których klient deleguje całą odpowiedzialność techniczną vendorowi bez regularnych code review i audytów. Jeśli nikt nie sprawdza, kto konkretnie pisze kod i jak go pisze, podstawienie pozostaje niezauważone aż do krytycznego spadku velocity.

Jak rozpoznać podstawienie przed kryzysem

Problem można wykryć na długo przed tym, jak uderzy w terminy. Oto kluczowe wskaźniki:

• Spowolnienie velocity bez obiektywnych przyczyn — jeśli złożoność zadań nie wzrosła, a techniczny dług się nie akumulował, ale zadania zamykają się wolniej, to pierwszy sygnał.
• Wzrost liczby poprawek i błędów — junior developerzy częściej popełniają błędy wymagające korekt. Jeśli odsetek błędów z QA lub produkcji rośnie — warto sprawdzić, kto je pisze.
• Spadek jakości kodu — pojawienie się antypatternów, ignorowanie standardów, brak testów tam, gdzie wcześniej były.
• Zwiększenie obciążenia pozostałych seniorów — jeśli kluczowi developerzy nagle zaczynają "pomagać" wszystkim po trochu, być może muszą kompensować niski poziom nowicjuszy.
• Zmiana tonu komunikacji — juniorzy rzadziej zadają pytania o architekturę, częściej proszą o konkretne instrukcje, unikają skomplikowanych zadań.

Regularne code review, pair programming z udziałem przedstawiciela klienta oraz analiza metryk (np. cyclomatic complexity, coverage, churn rate) pomagają wykryć problem na wczesnym etapie.

Co robić: środki prewencyjne i reakcja

Jeśli zetknąłeś się z podstawieniem — najważniejsze, by nie wpadać w panikę, lecz systematycznie odzyskać kontrolę. Poniżej — plan działań krok po kroku:

• Przeprowadź techniczny audyt — nie na podstawie CV, lecz rzeczywistego kodu i historii commitów. Kto poprawiał jakie moduły? Jak często? Jakiej jakości są wyniki?
• Przywróć przejrzystość zastępstw — dodaj do umowy klauzulę zobowiązującą vendora do uzgadniania każdej zmiany specjalisty z technical representative klienta.
• Przywróć seniorów na kluczowe role — jeśli budżet pozwala, zastąp juniorów middlami/seniorami. Jeśli nie — przeprzydziel zadania: niech juniorzy zajmują się ściśle ograniczonymi, dobrze udokumentowanymi fragmentami kodu.
• Wyznacz nadzór techniczny — nawet jeden architekt lub tech lead po stronie klienta, prowadzący cotygodniowe rewizje, obniża ryzyko podstawienia o 80%.
• Przejrzyj KPI zespołu — zamiast czystych godzin i zamkniętych ticketów wprowadź metryki jakości: liczba błędów na commit, czas na poprawki, coverage zmian.

Ryzykowne sygnały rynkowe

Sytuację pogarsza fakt, że niektórzy vendorzy świadomie traktują tę schematę jako model biznesowy: przyciągają klienta zespołem seniorów po rynkowej stawce, a następnie stopniowo zastępują go tańszymi specjalistami, zachowując marżę. Szczególnie powszechne to w regionach o wysokiej konkurencji i presji cenowej.

Dwie twarde reguły ochrony:

• Stawka poniżej 25$/h za seniora — czerwona flaga. Na rynku WNP prawdziwy senior nie pracuje taniej niż ta granica. Jeśli oferta wydaje się korzystna — sprawdzaj poziom przez zadanie testowe lub live-coding.
• Brak tech leada lub PM po stronie vendora — ryzyko. Zespół bez technicznego kierownictwa łatwiej ulega degradacji poziomu. Tech lead to naturalny filtr przeciw niekwalifikowanym zastępstwom.

Co ważne

• Podstawianie seniorów juniormi to nie błąd, lecz świadoma strategia niektórych vendorów na zwiększenie marży.
• Pierwsze objawy: spowolnienie velocity, wzrost błędów, spadek jakości kodu — pojawiają się na długo przed kryzysem.
• Ochrona: obowiązkowe uzgadnianie zastępstw, regularne code review, wyznaczenie tech leada po stronie klienta.
• Rynkowa stawka poniżej 25$/h za seniora na WNP — prawie zawsze oszustwo.
• Profilaktyka skuteczniejsza niż leczenie: lepiej wbudować kontrolę na etapie startu, niż ratować projekt po pół roku.

Nie ufaj formalnym raportom. Sprawdzaj, kto naprawdę pisze twój kod — dzisiaj, a nie pół roku temu. Twój projekt zależy nie od ładnych CV, lecz od realnych rąk przy klawiaturze.

— Editorial Team