Dlaczego ratowanie projektu kończy się jeszcze większym chaosem?

Projekt się opóźnia. Zarząd zwołuje spotkanie kryzysowe. Pada decyzja: dorzucamy ludzi, dorzucamy spotkania, dokręcamy tempo. Wszyscy czują, że wreszcie coś się dzieje. Problem w tym, że to „coś” zwykle pogarsza sytuację, zamiast ją naprawiać.

Widzę to u moich klientów regularnie. Firma wchodzi w tryb ratunkowy i robi dokładnie to, co wydaje się logiczne – tylko że w praktyce każda z tych reakcji dokłada chaosu do systemu, który już wcześniej był przeciążony. I zamiast odzyskać kontrolę, organizacja wpada w spiralę, z której coraz trudniej wyjść.

Scenariusz wygląda prawie zawsze tak samo. Lider albo zarząd zauważa, że delivery nie idzie zgodnie z planem. Terminy się przesuwają, klient zaczyna pytać, w zespole pojawia się napięcie. Wtedy pada pytanie: co robimy?

Odpowiedź w większości firm, z którymi pracuję, brzmi mniej więcej tak: więcej kontroli, więcej spotkań, więcej ludzi. Codzienne statusy zamiast cotygodniowych. Nowy PM dorzucony do projektu. Dodatkowy deweloper „na wsparcie”. Zarząd wchodzi na spotkania operacyjne, żeby „mieć rękę na pulsie”.

Z zewnątrz wygląda to jak działanie. Firma reaguje, nie stoi w miejscu, podejmuje decyzje. Tyle że te decyzje rzadko dotykają prawdziwego problemu. Dotykają objawów.

„Zamiast dostarczać wartość, dodawane są nowe spotkania.”

I to jest moment, w którym chaos zaczyna się karmić sam sobą.

Zauważam pewien wzorzec, który powtarza się niezależnie od branży – software house, product, gamedev. Kiedy delivery się sypie, organizacja wchodzi w tryb nadaktywności operacyjnej. Spotkania mnożą się jak grzyby po deszczu – nie po to, żeby podejmować decyzje, tylko po to, żeby ustalić, dlaczego znowu nikt nie dowiózł kolejnego etapu.

W kalendarzu robi się coraz ciaśniej. Liderzy spędzają połowę dnia na spotkaniach o spotkaniach. Deweloperzy tracą bloki czasu na kodowanie, bo co godzinę ktoś ich wyciąga na kolejny status. Realnego czasu na dostarczanie wartości jest coraz mniej, ale organizacja ma poczucie, że „pracuje nad problemem”.

To jest właśnie to, co nazywam perpetuum mobile chaosu. Każda reakcja generuje nowy problem, który wymaga kolejnej reakcji.

Wygląda to tak:

• delivery się opóźnia, więc dorzucamy spotkania,
• spotkania zjadają czas na pracę, więc delivery opóźnia się bardziej,
• zarząd widzi większe opóźnienie, więc dorzuca ludzi,
• nowi ludzie potrzebują wdrożenia i generują narzut komunikacyjny,
• narzut komunikacyjny wymaga kolejnych spotkań.

I koło się zamyka.

„To jest takie koło, które się samo napędza, takie perpetuum mobile chaosu.”

To jest jedna z najtrudniejszych prawd do zaakceptowania dla CEO i CTO. Kiedy projekt się opóźnia, naturalny odruch każe dorzucić zasoby. Logika wydaje się prosta: więcej rąk do pracy, szybciej pójdzie.

Tyle że w praktyce tak nie działa. Każda nowa osoba w projekcie potrzebuje czasu na wdrożenie – ktoś z zespołu musi jej wszystko wytłumaczyć, pokazać architekturę, kontekst biznesowy, sposób pracy. Ten ktoś w tym czasie nie koduje. Rośnie liczba kanałów komunikacyjnych, rośnie liczba zależności, rośnie ryzyko nieporozumień.

Pracuję z firmami, które mają 20-150 osób. W tej skali jeden dodatkowy deweloper w pięcioosobowym zespole to nie jest „plus 20% mocy”. To jest plus 40% narzutu komunikacyjnego i minus dwa tygodnie produktywności reszty zespołu na wdrożenie.

Dane z DORA 2024 pokazują coś niepokojącego dla całej branży: udział high performers wśród zespołów delivery spadł z 31% do 22% rok do roku, podczas gdy udział low performers wzrósł z 17% do 25%. Organizacje systemowo tracą zdolność do dowożenia – i dokładanie ludzi do złego systemu tego nie odwraca.

„Więcej ludzi dorzuconych w chaos nie dowozi więcej rzeczy.”

To zdanie powinno wisieć na ścianie w każdym biurze COO.

Jest taki moment w kryzysie delivery, o którym mało kto mówi. Moment, w którym ludzie w zespole przestają wierzyć, że da się to naprawić.

Widzę to wyraźnie, kiedy wchodzę do firmy w trakcie kryzysu. Są osoby, które nadal bardzo chcą dowieźć projekt. Mają kompetencje, mają zaangażowanie, mają pomysły, ale czują, że system im przeszkadza na każdym kroku. Zmiana priorytetów co tydzień. Wrzutki z góry, na które nikt nie mówi „nie”. Lider, który nie podejmuje decyzji, bo sam czeka na odpowiedź zarządu.

Zmęczenie realne po liderach, po zespole. To nie jest zwykłe zmęczenie sprintem. To jest długotrwałe zużywanie ludzi przez chaos, niejasność i brak decyzji.

W firmach usługowych i wieloprojektowych dochodzi do tego jeszcze jedno zjawisko – rozrywanie ludzi między kilka tematów naraz. Jeden deweloper ma dwóch, trzech klientów. Różni właściciele tematów obchodzą liderów i zgłaszają potrzeby bezpośrednio do zespołu. Nikt nie chroni zespołu przed tak zwanymi „strzałami z lasu”. Nikt nie kontroluje pełnego obrazu priorytetów.

I wtedy frustracja zaczyna krążyć po całym systemie. Zespół frustruje się na lidera. Lider na zarząd. Zarząd na zespół. Każdy widzi problem, ale każdy widzi go gdzie indziej.

To jest zdanie, które słyszę częściej niż bym chciał. I kiedy do tego dochodzi, firma traci nie tylko delivery. Traci ludzi.

Wiem, że to brzmi kontrintuicyjnie. Projekt się opóźnia, klient czeka, budżet się kurczy a ja mówię: zatrzymaj się. Pracuję z wystarczającą liczbą firm, żeby wiedzieć, że próba przyspieszenia w chaosie zawsze kończy się większym opóźnieniem.

Pierwsza rzecz, którą staram się unormować, kiedy wchodzę do firmy w kryzysie, to coś bardzo prostego: żeby liderzy zaczęli komunikować się ze sobą, zanim pójdą do zespołu. To pokazuje skalę problemu – zanim zacznie się optymalizować delivery, czasem najpierw trzeba zatrzymać wzajemne podbieranie sobie ludzi i zadań.

Nie chodzi o to, żeby przestać pracować. Chodzi o to, żeby na chwilę przestać reagować i zacząć diagnozować.

Bo pod spodem zwykle nie siedzi problem „za dużej liczby spotkań” ani „za małej wydajności”. Pod spodem siedzi brak ochrony zespołu, brak spójnego przepływu informacji, brak koordynacji między liderami i złudzenie, że więcej ludzi rozwiąże problem słabego systemu.

Kiedy firma to zobaczy – naprawdę zobaczy, nie tylko usłyszy na spotkaniu – wtedy dopiero można zacząć naprawiać. Ograniczyć spotkania do tych, które prowadzą do decyzji. Ustalić, kto może wrzucać zadania do zespołu i jakim kanałem. Przywrócić jedną, wspólną listę priorytetów. Odciążyć przeciążony zarząd z operacyjnego chaosu.

Zespół odzyskuje przestrzeń do realnej pracy nie dlatego, że ludzie pracują więcej. Tylko dlatego, że system przeszkadza im mniej.

Wracam do zdania z początku. Firma widzi opóźnienie i reaguje: spotkania, ludzie, presja. Wygląda jak działanie. Brzmi jak odpowiedzialność, ale kiedy reakcja na kryzys polega na dokładaniu chaosu do chaosu – to nie jest ratowanie projektu. To jest przyspieszanie jego upadku.

Jeśli widzisz ten wzorzec u siebie, zanim dorzucisz kolejne spotkanie, zadaj sobie jedno pytanie: czy mój zespół ma dziś warunki, żeby w ogóle dowozić?