Dlaczego projekty IT kończą się porażką: 8 sygnałów, których nie możesz zignorować
Sprinty przebiegają zgodnie z planem, velocity jest na przyzwoitym poziomie. Po pół roku ktoś z zarządu pyta: „Czy nasz projekt to sukces?” Zapada cisza – nikt nie umie jednoznacznie odpowiedzieć. Ta niepewność kosztuje czasem więcej niż wszelkie długi techniczne i pojawia się dużo wcześniej, zanim projekt realnie zacznie się sypać. Projekty IT rzadko kończą się porażką przez technologię czy umiejętności zespołu. Zazwyczaj problem wynika z pozornie neutralnych zachowań, które wydają się rozsądne w codziennej pracy – niezależnie od tego, po której stronie projektu jesteśmy.
Kluczowe wnioski
- Około dwóch trzecich projektów IT nie dowozi zakładanych celów, a powodem praktycznie nigdy nie jest stack technologiczny.
- Najgroźniejsze sygnały ostrzegawcze dotyczą organizacji, a nie technologii: brak jasnej definicji sukcesu, stale rosnący backlog, pomijanie ryzyk, podejmowanie decyzji bez danych.
- Pozytywne statusy w raportach potrafią przez wiele miesięcy maskować prawdziwe problemy projektu, bo liczba zamkniętych ticketów prezentuje się równie dobrze jak rzeczywista wartość dostarczona klientowi.
- Najczęściej to po stronie klienta pojawiają się zachowania utrudniające realizację projektu. Nie wynika to ze złej woli, a raczej z chęci unikania trudnych rozmów.
Dlaczego projekty IT naprawdę ponoszą porażkę
Większość analiz po zakończeniu projektu wskazuje niewłaściwych winnych. Na ogół obarcza się odpowiedzialnością błędne estymacje, niejasne wymagania albo konkretnego wykonawcę. Tymczasem prawdziwa przyczyna niemal zawsze leży w zachowaniach ludzi. Co więcej, ten problem pojawia się już na bardzo wczesnym etapie projektu, zanim jeszcze ktoś zdąży napisać choćby pierwszą linijkę kodu.
Raport CHAOS od Standish Group pokazuje, że około 66% z blisko 50 tysięcy przebadanych projektów nie osiąga w pełni założonych celów. Co prawda często pojawiają się zarzuty wobec tej metodologii, bo ich definicja „porażki” obejmuje także przesunięcia terminu czy zmianę zakresu – a to w Agile jest czymś normalnym. Mimo tej krytyki wnioski są jasne: dwa na trzy projekty IT nie dowożą tego, na co przeznaczono budżet.
Liczby nie pokazują jednak, dlaczego tak się dzieje. Gdy zapytaliśmy naszych product managerów, CTO i service delivery managera, co najczęściej prowadzi do upadku projektów, wszyscy – niezależnie od siebie – wskazali ten sam powód. Projekty upadają, bo ludzie po obu stronach starają się unikać niewygodnych sytuacji. Unikają szczerej rozmowy o tym, czym właściwie jest sukces. Nie chcą powiedzieć „nie” wpływowemu interesariuszowi. Odkładają zmierzenie się z opóźnieniem, dopóki wydaje się jeszcze możliwe, by je ukryć. Każdy taki unik osobno nie wydaje się groźny. Ale gdy zbierze się ich kilka przez pół roku, mogą pogrzebać cały projekt.
Poniżej opisane sygnały ostrzegawcze to właśnie wczesne oznaki unikania trudnych tematów. Nie ma wśród nich „słabych programistów” czy „złej bazy danych”, bo wielokrotnie widzieliśmy świetne zespoły z nowoczesnymi technologiami, które upadały, i mniej doświadczone zespoły ze starszymi rozwiązaniami, którym udawało się stworzyć produkty uwielbiane przez użytkowników. To nie kod decyduje o sukcesie – decydują warunki, w jakich ten kod powstaje.
8 sygnałów, że Twój projekt jest ma kłopoty
Każdy z tych sygnałów wydaje się na pierwszy rzut oka dość niegroźny. Jednak razem tworzą zestaw wskazówek, które najczęściej analizujemy, gdy klient pyta, czy jego projekt wciąż zmierza w dobrym kierunku. Przeczytaj je uważnie. Im więcej z nich rozpoznasz u siebie, tym szybciej powinieneś podjąć działania.
1. Nikt nie potrafi odpowiedzieć na pytanie „czy to sukces?”
Gdy nie wiadomo, czym jest sukces, zespół skupia się na tym, na co ma bezpośredni wpływ – czyli na realizacji zadań. Tickety się zamykają, tablice projektowe są uprzątnięte, dashboardy świecą się na zielono i wszyscy mają poczucie, że dobrze pracują. Jednak taka „produktywność” bez jasno wyznaczonego celu to tylko pozorna praca. Ten problem najczęściej wychodzi na jaw dopiero po czasie.
Strategiczne cele zazwyczaj gdzieś są – w prezentacji dla zarządu, w głowie założyciela albo w arkuszu OKR, do którego nikt poza C-level nie zagląda. Najwięcej problemów powstaje w tej luce między „mamy strategię” a „zespół faktycznie podejmuje codzienne decyzje zgodnie z tą strategią”.
Pytanie diagnostyczne: poproś trzech różnych członków zespołu, aby dokończyli zdanie „ten projekt zakończy się sukcesem, jeśli…”. Jeśli usłyszysz trzy różne odpowiedzi, to nie problem w strategii, ale w komunikacji – i to ona po cichu, sprint po sprincie, drenuje budżet.
2. Backlog rośnie w każdym sprincie i nigdy nie maleje
Po trzech miesiącach roadmapa, która początkowo miała osiem pozycji, rozrasta się do czterdziestu. Każdy nowy punkt pojawił się z jakiegoś powodu: bo klient o to poprosił, bo konkurencja coś wdrożyła, bo pojawiła się nowa technologia, albo założyciel nagle wpadł na pomysł w środku nocy. Nic nie zostało wykreślone. W międzyczasie gdzieś po drodze zgubił się pierwotny sens produktu.
Feature creep rzadko wygląda jak poważny problem. Na pierwszy rzut oka przypomina raczej ambicję niż zagrożenie, dlatego jest tak podstępny. Każda nowa funkcjonalność rozmywa kluczową wartość produktu, konkuruje o uwagę użytkownika w interfejsie, podnosi koszty testowania i utrzymania. Zamiast jednej rzeczy zrobionej naprawdę dobrze, powstaje kilkanaście wykonanych przeciętnie. A przeciętnych rozwiązań nikt nie pokocha.
„Wszyscy myślą, co dodać. Nikt nie myśli, co odjąć.”
– Michał Kania, Product Manager w Pragmatic Coders
Pytanie diagnostyczne: ile propozycji nowych funkcjonalności z ostatniego kwartału zostało świadomie odrzuconych wraz z pisemnym uzasadnieniem? Jeśli żadna, to znaczy, że Twój backlog nie jest rzeczywistym planem działania, lecz tylko listą życzeń.
3. Funkcje wchodzą na produkcję, ale nikt nie mierzy, co się dzieje potem
Coraz częściej „wdrożone” oznacza po prostu „zrobione”. Zespół publikuje release notes, przechodzi do następnych zadań, a nikt nie sprawdza, czy ktokolwiek rzeczywiście korzysta z nowej funkcji. Po kilku miesiącach okazuje się, że coś, co miało być hitem, trafia do kosza, bo pierwsze wyniki są słabe. Ale nikt nie próbował ustalić, z czego to wynikało.
Mieliśmy okazję doświadczyć tego na własnej skórze. Nowa funkcja wyglądała na kompletnie nietrafioną – korzystało z niej niemal zero osób. Naszą pierwszą reakcją była myśl, żeby ją usunąć. Zamiast tego zorganizowaliśmy krótkie szkolenie dla użytkowników. Po nim użycie funkcji wzrosło wielokrotnie. Problemem wcale nie był sam produkt, tylko brak informacji zwrotnej od użytkowników.
Brak danych nie sprawia, że zespół przestaje podejmować decyzje — nadal je podejmuje, ale kierując się intuicją, własnymi upodobaniami lub opinią osoby o największej sile przebicia. Takie decyzje mogą sprawiać wrażenie równie pewnych, jak te podejmowane na podstawie twardych danych, dlatego tak łatwo się na nie nabrać.
Pytanie diagnostyczne: Jak zmieniła się konkretna metryka po wdrożeniu ostatniej funkcji? Jeśli nie potrafisz odpowiedzieć na to prosto lub jednym zdaniem, coś jest nie tak z obiegiem informacji zwrotnej.
4. Proste decyzje zajmują tygodnie
Zespół proponuje prostszą integrację, która pozwoliłaby zaoszczędzić dwa sprinty i ograniczyć ryzyko. Tech lead się zgadza, product manager również. Jednak, aby decyzja mogła zostać podjęta, potrzeba zgody pięciu osób z trzech różnych działów. Po sześciu tygodniach zapada dokładnie taka sama decyzja, jaką zespół proponował na samym początku.
Paraliż decyzyjny wynika z dwóch wzajemnie napędzających się przyczyn. Po pierwsze, strukturalnych: odpowiedzialność rozmywa się pomiędzy wielu interesariuszy i poziomy zatwierdzenia, przez co nikt nie podejmuje ostatecznej decyzji. Po drugie, kulturowych: ludzie unikają trudnych wyborów, bo wiążą się one z ryzykiem konfliktu. W efekcie organizacja najczęściej wybiera ścieżkę najmniejszego oporu – czyli nie wybiera wcale.
„Niepodjęcie decyzji o uproszczeniu zakresu, refaktoryzacji albo zmianie podejścia to też decyzja. Zwykle najdroższa.”
– Krzysztof Pykosz, Product Manager w Pragmatic Coders
Pytanie diagnostyczne: Podaj konkretnie, kto (z imienia i nazwiska) może samodzielnie zdecydować o usunięciu funkcji z tego sprintu. Jeśli trudno wskazać taką osobę albo trzeba to najpierw uzgadniać, właśnie znalazłeś wąskie gardło.
5. Twoi seniorzy przestali się stawiać
Doświadczony programista czyta ticket. Sposób implementacji jest opisany krok po kroku: jaka biblioteka, jak ma wyglądać struktura kodu, co ma zwrócić API. On widzi prostsze, bardziej niezawodne rozwiązanie. Milczy. Ostatnim razem, kiedy zaproponował alternatywę, usłyszał „po prostu zrób zgodnie ze specyfikacją”.
Gdy ekspertów sprowadza się do roli zwykłych wykonawców, firma traci ich największą wartość – umiejętność samodzielnej oceny i doświadczenie. Mikrozarządzanie zwykle wynika ze strachu, często spowodowanego utratą zaufania po wcześniejszych błędach. Nadmierna kontrola prowadzi do tego, że najlepsi pracownicy stopniowo się wycofują.
Jeszcze gorsza jest bardziej subtelna wersja tego problemu: gdy zamiast otwartej informacji zwrotnej pomiędzy członkami zespołu, każda niezgodność automatycznie trafia do przełożonych. Wtedy managerowie i dyrektorzy zaczynają być blokadą dla decyzji operacyjnych, których wcale nie powinni podejmować.
Pytanie diagnostyczne: ile propozycji rozwiązań technicznych, innych niż przewidywała pierwotna specyfikacja, pojawiło się w Twoim zespole w ostatnim miesiącu? Jeśli żadna – to sygnał, że Twoi seniorzy przestali zabierać głos.
6. Estymaty rosną, a nikt nie potrafi powiedzieć dlaczego
Klient prosi o nową funkcję. Szacujemy czas pracy na dwa tygodnie. Zespół zaczyna realizację i szybko natrafia na obejście zastosowane rok temu, które nigdy nie zostało poprawione, na dane w niespójnym formacie oraz moduł pozbawiony testów. Dwa tygodnie zamieniają się w osiem. Klient jest sfrustrowany i pyta, skąd taki koszt. Rzetelna odpowiedź kryje się w dwunastu miesiącach zaniedbań, do których nikt wcześniej nie wrócił.
Dług techniczny nie wystawia rachunków. Po prostu sprawia, że wszystko zaczyna się wydłużać, aż w końcu projekt całkowicie staje w miejscu. Schemat jest niemal zawsze taki sam: pieniądze przeznaczane są na to, co widać — dopracowany interfejs, płynne animacje, atrakcyjna strona główna. Tymczasem cała niewidoczna praca, która utrzymuje produkt przy życiu — bezpieczeństwo, monitoring, testy, jakość danych — ląduje na końcu listy priorytetów, bo interesariusze po prostu tego nie dostrzegają.
„»Na razie zróbmy to ręcznie« albo »naprawimy to potem« zwykle kończy się tak, że obejście staje się procesem. A koszt po prostu rośnie.”
– Krzysztof Pykosz, Product Manager w Pragmatic Coders
Pytanie diagnostyczne: Ile czasu w każdym sprincie faktycznie poświęcacie na spłacanie długu technicznego i poprawę pokrycia testów? Jeśli szczera odpowiedź brzmi: „tyle, ile akurat zostanie”, to już znasz powód, dlaczego estymaty stale rosną.
7. Ryzyka są zgłaszane, po czym lądują w archiwum
Trzy dni po anulowaniu projektu ktoś przypomina sobie o wiadomości sprzed pół roku. Jeden z seniorów wyraźnie sygnalizował, że obecne podejście się nie sprawdzi, a terminu nie da się dotrzymać. Informacja została zauważona, uprzejmie przyjęta do wiadomości, ale nic z niej nie wynikło. Gdy projekt upadł, nikt nie był tym zaskoczony — wszyscy o problemie wiedzieli.
Projekty rzadko upadają z zaskoczenia. Zwykle przez wiele miesięcy pojawiają się sygnały ostrzegawcze, które są ignorowane. Powody milczenia bywają trzy i często się ze sobą przeplatają. Są osoby, które widzą problem, ale nie zabierają głosu, bo nauczyły się, że zgłaszanie ryzyka szybko bywa uznane za „negatywne nastawienie”. Są też ci, którzy próbują zwrócić uwagę na zagrożenia, ale ich sygnały giną w natłoku spraw u przełożonego albo zostają zignorowane z powodów politycznych — bo przyznanie się do problemu byłoby równoznaczne z przyznaniem się do wcześniejszego błędu. Są wreszcie osoby, które nawet nie mają szansy dostrzec problemów, bo są rozproszone między zbyt wiele projektów i po prostu brak im czasu oraz energii, aby zauważyć „żółte flagi”.
„Osoby odpowiedzialne u klienta mogą pomijać niepokojące sygnały/ostrzeżenia/żółte lampki, bo mają np. za dużo na głowie i nie chcą sobie dokładać. Drugi aspekt przy “nic” to kwestia polityki wewnętrznej – i tak się nic z tym nie zrobi, dlatego lecimy na zderzenie z górą lodową.«.”
– Jakub Dobosz, Service Delivery Manager w Pragmatic Coders
Pytanie diagnostyczne: Kiedy ostatni raz ktoś zgłosił w zespole poważne ryzyko i co konkretnego zostało w związku z tym zrobione w ciągu dwóch tygodni? Jeśli nie podjęto żadnych działań, rejestr ryzyk jest tylko formalnością.
8. Zarządzasz kontraktem, nie zespołem
Kontrakt został podpisany – zakres, cena i termin są jasno określone. Po czterech miesiącach okazuje się, że biznes potrzebuje czegoś innego. Dostawca reaguje przewidywalnie: „tego nie było w umowie”. Rozpoczynają się tygodnie renegocjacji. Od tego momentu obie strony skupiają się już nie na produkcie, lecz na kontrakcie.
Gdy firma decyduje się powierzyć development firmie zewnętrznej, często pojawia się podział na „naszych” i „ich”. Zespół dostawcy zostaje odsunięty od rozmów strategicznych, pomijany w firmowej komunikacji i traktowany jak osobna, obca jednostka. Nic dziwnego, że osoby traktowane jak ktoś z zewnątrz nie angażują się w pełni, nie zgłaszają ryzyk z własnej inicjatywy i nie zdobywają wystarczającego kontekstu, by podejmować trafne decyzje produktowe.
“Uważać, że za samopoczucie ludzi pracujących po stronie dostawcy odpowiada wyłącznie dostawca, to bardzo groźne złudzenie. Jeśli ci ludzie odejdą, Twój projekt stanie w miejscu – bez względu na to, kto formalnie ich zatrudnia.”
– Marcin Byrdziak, CTO w Pragmatic Coders
Pytanie diagnostyczne: Gdy pojawia się problem, co robisz najpierw: zaglądasz do kontraktu czy dzwonisz do zespołu? Jeśli najpierw sprawdzasz kontrakt, to znaczy, że Wasza relacja przeszła z partnerstwa na tory formalno-prawne – i za tę zmianę zapłaci produkt.
Co łączy wszystkie te sygnały
Osiem różnych schematów, te same przyczyny — unikanie dyskomfortu. Brak jasnej definicji sukcesu oznacza ucieczkę przed trudną rozmową o tym, co naprawdę się liczy. Ciągłe dokładanie nowych funkcji to sposób, żeby nie powiedzieć wprost „nie”. Pomijanie danych to odsuwanie od siebie niewygodnych prawd, które mogłyby zakwestionować dotychczasowe założenia. Odkładanie decyzji to uchylanie się od odpowiedzialności. Mikrozarządzanie wynika z chęci uniknięcia ryzyka, które wiąże się z zaufaniem zespołowi. Lekceważenie ostrzeżeń jest próbą odsunięcia konfrontacji. Traktowanie zespołu dostawcy jak obcych to niechęć do wzięcia na siebie zobowiązań, jakie oznacza prawdziwe partnerstwo.
Żaden z tych wyborów nie wydaje się w chwili podejmowania dramatyczny. Każdy daje chwilowe poczucie spokoju. Jednak gdy przez pół roku czy rok się je nawarstwi, przestają być incydentami, a zaczynają tworzyć codzienność projektu. Dlatego projekty, które ostatecznie upadają, od środka wyglądają do siebie bliźniaczo podobnie: te same sposoby unikania trudnych decyzji, nakładające się na siebie i przykryte pozytywnym raportem statusowym.
Dobra wiadomość: każdy z tych schematów można odwrócić. Nie potrzeba do tego nowej metodologii, kolejnego narzędzia ani większego budżetu. Potrzeba za to uczciwości, jasnych zasad i gotowości, żeby czasem wybrać chwilowy dyskomfort, zamiast długo ciągnących się problemów.
Co zrobić, zanim dorzucisz więcej ludzi albo funkcji
Gdy projekt zaczyna się blokować, typowa reakcja to „dodajmy więcej” — więcej programistów, więcej funkcji, więcej spotkań. Tymczasem w rzeczywistości największy wpływ mają działania polegające na odejmowaniu, a nie dokładaniu kolejnych elementów.
Ustalcie wspólnie jedno zdanie, które jasno określa, czym dla Was jest sukces. To nie powinna być roadmapa ani lista funkcji, ale jedno konkretne, mierzalne zdanie, które każdy w zespole potrafi bez problemu powtórzyć. Jeśli najważniejsze zadanie sprintu nie nawiązuje do tego zdania, to znak, że trzeba o tym porozmawiać. Wróćcie do tego zdania raz w miesiącu podczas spotkania zespołu.
Przejrzyjcie backlog pod kątem rzeczy do usunięcia. Przy każdej funkcji zadajcie sobie pytanie: „z czego możemy zrezygnować, aby zrealizować to zadanie?”. Przenieście minimum trzy pozycje z kategorii „planujemy” do „rezygnujemy świadomie” i odnotujcie powód tej decyzji. Umiejętność rezygnowania z rzeczy jest trudniejsza niż dokładanie nowych, ale właśnie ona najlepiej chroni główną wartość Waszego produktu.
Wprowadź regularne przeglądy ryzyk. Co dwa tygodnie zorganizujcie krótkie spotkanie poświęcone wyłącznie omówieniu możliwych zagrożeń. Bez statusów, bez prezentacji – tylko potencjalne ryzyka. Każde zgłoszone zagadnienie potraktujcie poważnie: zanotujcie je i wróćcie do niego przy kolejnym spotkaniu. Lepiej usłyszeć o problemie wcześniej, niż dowiedzieć się o nim za późno.
Podsumowanie
Projekty IT najczęściej upadają z przyczyn leżących po stronie ludzi, a nie technologii. Osiem opisanych wyżej sygnałów to wczesne oznaki problemów, które można dostrzec na kilka tygodni lub miesięcy przed tym, zanim projekt zejdzie z właściwej ścieżki. Jeśli w swoim projekcie rozpoznajesz choć dwa z nich, nie traktuj tego jako powodu do niepokoju, lecz jako sygnał, że czas na szczerą rozmowę, którą do tej pory odkładałeś.
Szczegółowy przewodnik z rozszerzonymi rozdziałami, dodatkowymi przykładami oraz wypowiedziami naszego CTO, product managerów i service delivery managera znajdziesz w naszym ebooku. Jeśli chcesz zobaczyć, jak te wzorce wyglądają w praktyce i jak sobie z nimi radzić, pobierz ebook „8 ways companies sabotage their own projects” i podziel się nim z osobami z zespołu, które są najbliżej codziennej pracy nad projektem. To, co sami w nim rozpoznają, powie Ci więcej niż jakikolwiek raport statusowy.
