5 sygnałów, że projekt IT wymaga przejęcia, a nie „jeszcze jednej iteracji”

Projekt się opóźnia. Budżet topnieje. Stakeholderzy pytają, co się dzieje. Dostawca mówi: „dajmy sobie jeszcze jeden sprint”. Albo: „po tej iteracji będzie widać efekty”. Albo: „teraz już naprawdę domykamy stabilizację”.

Brzmi rozsądnie. Bo czasem jedna iteracja faktycznie coś zmienia. Problem zaczyna się wtedy, gdy „jeszcze jedna iteracja” staje się domyślną odpowiedzią na każdy kryzys. Zamiast decyzji pojawia się kolejny cykl obietnic, raportów i przesuniętych terminów.

W tym artykule pokazujemy pięć sygnałów, które mówią: projekt nie potrzebuje kolejnego sprintu w tym samym modelu. Potrzebuje przejęcia kontroli — diagnozy, stabilizacji albo zmiany sposobu pracy.

Kiedy „jeszcze jedna iteracja” ma sens?

Warto zacząć od uczciwego rozróżnienia. Nie każdy problem w projekcie IT wymaga rescue.

Kolejny sprint albo iteracja mają sens, gdy:

• opóźnienie dotyczy konkretnego zakresu, a nie całego systemu delivery;
• zespół potrafi nazwać przyczynę: brak decyzji, zależność po stronie klienta, niedoszacowanie, błąd w wymaganiach;
• po każdej iteracji coś realnie przybliża produkt do celu — funkcja trafia na produkcję, ryzyko spada, backlog jest czytelniejszy;
• raport pokazuje nie tylko godziny, ale też efekt: co zostało dowiezione, co zaakceptowano, co się zmieniło w prognozie;
• problem nie wraca w tej samej formie w kolejnym miesiącu.

Wtedy iteracja służy korekcie kursu, a nie odkładaniu decyzji.

Problem zaczyna się, gdy każda iteracja kończy się tym samym scenariuszem: nowy termin, nowe usprawiedliwienie, ten sam brak efektów. Wtedy płacisz za czas dostawcy, nie za postęp projektu.

Sygnał 1: Opóźnienia powtarzają się mimo „korekt”

Nie chodzi o pojedyncze spóźnienie — chodzi o wzorzec, który się powtarza.

W projekcie, który wymaga przejęcia, zwykle widzisz coś takiego:

• termin przesuwa się trzeci, czwarty, piąty raz;
• po każdym opóźnieniu pojawia się plan naprawczy, ale kolejny miesiąc wygląda tak samo;
• dostawca obiecuje „domknięcie stabilizacji”, ale stabilizacja nigdy się nie kończy;
• status spotkania brzmi: „były trudności, ale teraz jesteśmy na dobrej drodze”;
• nikt nie pokazuje, co konkretnie zmieniło się w systemie pracy po poprzedniej korekcie.

Jedno opóźnienie może wynikać z błędu w estymacji. Powtarzające się opóźnienia mimo deklarowanych korekt oznaczają coś innego: model delivery nie działa.

Kolejna iteracja w tym samym układzie nie naprawi problemu. Przedłuży go — i prawdopodobnie przesunie go o miesiąc dalej, z nowym zestawem usprawiedliwień.

Pytanie diagnostyczne: Czy po ostatniej „korekcie” cokolwiek realnie się zmieniło w tempie dowozu, jakości albo przewidywalności? Jeśli nie — nie potrzebujesz kolejnego sprintu. Potrzebujesz diagnozy, dlaczego korekty nie działają.

Sygnał 2: Roadmapa sprint po sprincie przegrywa z nieplanowanymi pracami

Drugi sygnał to chroniczne wypieranie planu przez bieżący chaos.

Zespół teoretycznie pracuje nad roadmapą. W praktyce co kilka dni pojawia się:

• incydent produkcyjny,
• pilne zgłoszenie od biznesu,
• hotfix,
• problem ze środowiskiem,
• brak danych albo integracji,
• regresja po poprzedniej zmianie,
• decyzja stakeholdera, która zmienia priorytet.

Jeśli tego nie rozdzielisz, łatwo dojść do złego wniosku: zespół dowozi za mało.

Czasem prawdziwy wniosek brzmi inaczej: zespół nie ma warunków, żeby dowozić roadmapę, bo większość capacity zespołu pochłania utrzymanie, stabilizacja i prace nieplanowane.

Jedna zła iteracja może być pechowa. Ale jeśli przez trzy, cztery, pięć sprintów z rzędu planowany rozwój regularnie przegrywa z gaszeniem pożarów, winne nie są priorytety jednego sprintu — lecz stabilność systemu, proces delivery albo architektura.

Kolejna iteracja bez zmiany warunków pracy oznacza kolejny sprint, w którym roadmapa znowu przegra. Bo przyczyna leży gdzie indziej — w jakości wdrożeń, braku testów, manualnych deploymentach, długu technicznym albo braku reguł obsługi scope’u dodatkowego.

Dobry dostawca powinien osobno pokazywać:

• co było zaplanowane;
• co weszło ad hoc;
• co wypchnęło roadmapę;
• jaki był koszt incydentów;
• które problemy wracają cyklicznie.

Jeśli tego nie widać, a dostawca proponuje „jeszcze jeden sprint na funkcje”, to sygnał ostrzegawczy. Więcej o tym, jak odróżnić aktywność od zdrowia projektu, piszemy w artykule Projekt IT wymyka się spod kontroli? Dlaczego dokładne timesheety nie wystarczą.

Sygnał 3: Zielony status, ale brak efektów biznesowych

Trzeci sygnał to rozdźwięk między raportem a rzeczywistością.

Na spotkaniu statusowym wszystko wygląda dobrze:

• tickety są zamykane,
• zespół pracuje pełną pojemnością,
• sprint kończy się w większości zrealizowany,
• dashboard świeci na zielono.

A po stronie biznesu:

• w produkcji nie widać nowych efektów;
• funkcje „gotowe” nie przechodzą akceptacji;
• stakeholderzy pytają, za co płacą;
• termin kolejnej ważnej premiery znowu się przesuwa;
• nikt nie potrafi pokazać, co konkretnie zmieniło się dla użytkownika albo procesu biznesowego.

To klasyczny efekt arbuza: zielony na zewnątrz, czerwony w środku.

Kolejna iteracja w takim modelu zwykle produkuje więcej aktywności, nie więcej wartości. Winny zwykle nie jest tempo kodowania, tylko definicja „gotowe”, jakość wdrożeń, brak testów, słaba akceptacja albo złe priorytety.

Słaby raport mówi: zespół przepracował 160 godzin.

Lepszy raport mówi: zespół wykorzystał 160 godzin — tyle poszło na rozwój, tyle na incydenty, tyle na stabilizację. Funkcja A jest gotowa do odbioru, funkcja B się przesunęła, bo incydenty wypchnęły część planowanej pojemności. W kolejnym tygodniu rekomendujemy ograniczyć nowy scope i domknąć stabilizację.

Jeśli po kilku iteracjach nadal widzisz tylko pierwszy typ raportu, problem dotyczy sposobu raportowania i dowozu efektów — nie jednego sprintu.

Sygnał 4: Nikt nie potrafi powiedzieć, gdzie zniknął budżet i dlaczego

Czwarty sygnał dotyczy transparentności kosztów i przyczyn decyzji.

Budżet zużywa się szybciej, niż zakładano. Albo zużywa się zgodnie z planem, ale efektów widać mniej, niż powinno. W obu przypadkach powinieneś dostać proste odpowiedzi:

• ile budżetu zostało wykorzystane;
• na jaki typ pracy poszły pieniądze: rozwój, utrzymanie, incydenty, discovery, dług techniczny;
• co zostało dowiezione i zaakceptowane;
• co zmieniło prognozę;
• jakie decyzje biznesowe podbiły koszt;
• co trzeba zatrzymać, zanim przepalisz kolejny miesiąc.

Jeśli zamiast tego słyszysz:

• „Zespół był zajęty, trudno to teraz rozbić.”
• „Faktura pokaże wszystko.”
• „Nie ma sensu tego teraz dzielić.”
• „To techniczne, nie trzeba tego tłumaczyć biznesowi.”
• „Zobaczymy na koniec miesiąca.”

to masz problem z modelem współpracy, nie z brakiem jeszcze jednego sprintu.

Dokładniejsze timesheety w takiej sytuacji nie rozwiążą sedna. Pokażą więcej szczegółów tego samego chaosu. Potrzebujesz modelu, w którym koszt wiąże się z zakresem, priorytetami, ryzykiem i realnym postępem — nie tylko z listą godzin.

Pełną listę pytań, które warto zadać dostawcy, zebraliśmy w artykule o transparentności kosztów w projekcie software. Jeśli większość z nich budzi opór albo wymijające odpowiedzi, to silny sygnał, że projekt wymaga przejęcia kontroli — zanim wydasz kolejny budżet na „jeszcze jedną iterację”.

Sygnał 5: Każda kolejna zmiana kosztuje więcej i wiąże się z większym ryzykiem

Piąty sygnał jest techniczny, ale ma bezpośredni wpływ na biznes.

W zdrowym projekcie kolejne iteracje z czasem powinny być przewidywalniejsze albo przynajmniej nie stawać się systematycznie droższe i bardziej ryzykowne. W projekcie wymagającym przejęcia dzieje się odwrotnie:

• każda zmiana wymaga więcej analizy niż poprzednia;
• regresje pojawiają się regularnie;
• deploymenty są ręczne, stresujące i nieprzewidywalne;
• testy nie dają realnego poczucia bezpieczeństwa;
• dokumentacja jest nieaktualna albo jej brak;
• wiedza siedzi w głowach kilku osób, a nie w systemie;
• drobna poprawka trwa tygodniami, bo „trzeba uważać, żeby niczego nie zepsuć”.

Zespół może pracować w pełnym tempie — ale system stawia coraz wyższą opłatę za ryzyko przy każdej kolejnej zmianie.

Kolejna iteracja feature’ów na takim fundamencie zwykle pogarsza sytuację, bo warunki techniczne wymuszają obejścia, ręczne testy, hotfixy i strach przed wdrożeniem.

Wtedy sens ma nie „jeszcze jeden sprint na roadmapę”, tylko:

• diagnoza stanu technicznego;
• plan stabilizacji;
• uporządkowanie deploymentów i środowisk;
• świadoma decyzja, co naprawić, zanim znowu zaczniesz dowozić nowy scope.

Bez tego każda kolejna iteracja będzie droższa od poprzedniej.

Co oznacza „przejęcie projektu” — i czego nie oznacza

Słowo „przejęcie” brzmi jak zmiana dostawcy. Czasem tak właśnie wygląda. Ale nie zawsze.

Przejęcie kontroli nad projektem może oznaczać:

• audyt techniczno-produktowy;
• project rescue z planem stabilizacji i wsparcia istniejącego zespołu;
• przejęcie projektu po poprzednim dostawcy;
• uporządkowanie backlogu i modelu decyzyjnego;
• wprowadzenie Definition of Done i przewidywalnego delivery;
• przejęcie zarządzania produktem albo architekturą przez interim CTO;
• zatrzymanie nowego scope’u do czasu domknięcia krytycznych problemów.

Przejęcie nie musi oznaczać wyrzucenia zespołu i zaczynania od zera. Chodzi o to, żeby przestać finansować ten sam wzorzec i zacząć od diagnozy tego, co blokuje dowóz.

Dobry dostawca w takiej sytuacji nie powinien zaczynać od obietnicy, że „dowiezie szybciej”. Powinien powiedzieć:

Zanim zaproponujemy kolejną iterację, sprawdźmy, czy problem leży w zakresie, czy w systemie pracy. Jeśli to drugie, najpierw potrzebujecie diagnozy: backlog, incydenty, delivery, dług techniczny, ryzyka i decyzje, które trzeba podjąć teraz.

Tu właśnie rozchodzi się sprzedawanie kolejnego sprintu od realnego project rescue.

Jak wygląda pierwszy krok, gdy rozpoznasz te sygnały?

Jeśli widzisz u siebie dwa lub więcej z pięciu sygnałów, nie zaczynaj od pytania o dokładniejsze timesheety. Zacznij od diagnozy.

Pierwszy krok powinien obejmować:

• przegląd backlogu i roadmapy;
• identyfikację incydentów i prac nieplanowanych, które wypychają plan;
• ocenę procesu delivery i deploymentów;
• przegląd długu technicznego i dokumentacji;
• sprawdzenie, co faktycznie trafiło na produkcję i zostało zaakceptowane;
• identyfikację kluczowych ryzyk;
• rekomendację: korekta kursu czy pełne przejęcie.

Dopiero po tym można uczciwie powiedzieć:

• co da się uratować szybko;
• co wymaga inwestycji;
• co trzeba zatrzymać;
• co trzeba przepisać albo ustabilizować;
• gdzie budżet przecieka;
• jakie decyzje musisz podjąć jako klient.

Taki punkt wyjścia daje realną transparentność zamiast kolejnej iteracji w nadziei, że tym razem będzie inaczej.

O co zapytać, zanim zgodzisz się na „jeszcze jeden sprint”

Zanim podpiszesz się pod kolejną iteracją, zapytaj:

• Co konkretnie zmieniło się od ostatniej obietnicy, że tym razem efekt będzie inny?
• Ile czasu w ostatnich tygodniach poszło na planowany rozwój, a ile na incydenty i utrzymanie?
• Co trafiło na produkcję i zostało zaakceptowane od ostatniego sprintu?
• Gdzie zniknął budżet i jakie decyzje zmieniły prognozę?
• Które problemy wracają cyklicznie?
• Dlaczego ostatnia „stabilizacja” się nie domknęła?
• Co dostawca rekomenduje zatrzymać, zanim wydamy kolejny miesiąc budżetu?
• Czy problem leży w zakresie, czy w fundamentach delivery?

Jeśli odpowiedzi są konkretne i spójne z danymi — być może kolejna iteracja ma sens. Jeśli słyszysz ogólniki, obietnice bez liczb albo „damy radę w następnym sprincie” — to sygnał, że potrzebujesz czegoś więcej niż kolejnego cyklu.

Chcesz uporządkowanego punktu startu?

Pobierz Czy twój projekt plonie? Autodiagniza — sześć pytań diagnostycznych, które pomagają odróżnić objawy od przyczyn, checklistę sygnałów ostrzegawczych i kroki naprawcze, które możesz zacząć wdrażać w ciągu jednego–dwóch tygodni.

Podsumowanie: kiedy kolejna iteracja już nie wystarczy

Jeśli te same problemy wracają sprint po sprincie, kolejna iteracja kupuje głównie czas — i coraz droższy powrót do kontroli nad projektem.

Pięć sygnałów, że potrzebujesz przejęcia, a nie kolejnego cyklu:

1. Opóźnienia powtarzają się mimo deklarowanych korekt.
2. Roadmapa regularnie przegrywa z incydentami i pracami nieplanowanymi.
3. Raporty pokazują aktywność, ale nie efekty biznesowe.
4. Nikt nie potrafi jasno powiedzieć, gdzie zniknął budżet i dlaczego.
5. Każda kolejna zmiana kosztuje więcej i wiąże się z większym ryzykiem.

Dobry dostawca nie sprzedaje kolejnego sprintu jako domyślnej odpowiedzi na kryzys. Pomaga rozpoznać, czy projekt potrzebuje korekty zakresu, czy przejęcia kontroli nad całym modelem delivery.

Rozpoznajesz u siebie te sygnały?

Pomagamy w projektach, w których budżet topnieje, roadmapa przegrywa z incydentami, a kolejna iteracja nie przynosi efektów. W kilka dni mówimy, gdzie naprawdę leży problem, co trzeba zatrzymać i czy wystarczy korekta kursu, czy potrzebne jest pełne przejęcie.

Umów 30 minut rozmowy – bez slajdów, bez prezentacji. Opisz, gdzie projekt utknął w pętli „jeszcze jednej iteracji”, a my powiemy, od czego zacząć.