Dlaczego problemy z delivery zaczynają się jeszcze przed startem developmentu?

Ostatnio usiadłem z CEO software house’u, który ma 60 osób i cztery zespoły delivery. Powiedział mi: „Michał, mamy problem z ludźmi. Nie dowożą.” Poprosiłem, żeby pokazał mi zakres ostatnich trzech projektów. Przeczytałem. I powiedziałem mu coś, czego nie chciał usłyszeć – te projekty nie miały szans od pierwszego dnia. Nie dlatego, że zespół jest słaby. Dlatego, że ktoś wpisał marzenia do zakresu i nazwał to planem. I to nie jest wyjątek. To schemat, który widzę praktycznie u każdego klienta, do którego trafiam.

Znacie to? Kick-off projektu, wszyscy podekscytowani, klient opowiada wizję. I zamiast zapytać „co jest naprawdę potrzebne na start?”, zespół zapisuje wszystko. Każdy ficzer. Każdy „a fajnie by było, gdyby”. Nikt nie rozdziela tego, co jest konieczne do działania, od tego, co jest „nice to have”. Wszystko trafia do jednego worka z tym samym priorytetem.

Pracuję z firmami IT od lat i widzę ten schemat u zdecydowanej większości klientów. Ktoś po stronie biznesu mówi „na pewno damy radę”, ktoś po stronie technicznej kiwa głową, bo nie chce być tym, który hamuje – i projekt rusza z zakresem, który nie ma nic wspólnego z realnymi możliwościami zespołu.

Problem nie polega na tym, że ludzie są niekompetentni. Problem polega na tym, że nikt nie przeszedł przez bolesną, ale niezbędną rozmowę:

• co wyrzucamy?
• co może poczekać?
• co jest absolutnym minimum, które dostarcza wartość?

Discovery w wielu firmach to nie jest proces decyzyjny. To sesja zbierania życzeń, po której ktoś robi z nich backlog i mówi „to teraz dostarczajcie”.

A co jest najgorsze? Że klient często sam nie wie, czego potrzebuje. I to jest w porządku – od tego jest discovery, żeby to z niego wyciągnąć, ale kiedy firma bierze listę życzeń klienta i bez krytycznej analizy zamienia ją w zakres projektu, bierze na siebie odpowiedzialność za coś, czego nikt nie zweryfikował. I potem, kiedy delivery się sypie, obie strony wskazują na siebie palcem.

Oto scena, którą widzę regularnie. Handlowiec albo CEO jest na spotkaniu z klientem. Klient pyta: „Kiedy to będzie gotowe?” I pada odpowiedź. Konkretna data. Czasem z dokładnością do tygodnia. Brzmi profesjonalnie. Jest tylko jeden problem – nikt z zespołu technicznego nie był w pokoju, kiedy ta data padła.

A potem ta data trafia do kontraktu. I nagle coś, co było „wstępnym szacunkiem”, staje się zobowiązaniem. Zespół dowiaduje się o terminie, kiedy projekt już ruszył. I co robi? Próbuje się zmieścić. Bo nie chce być „tym, który mówi, że się nie da”.

Estymacja w wielu firmach, z którymi pracuję, nie jest narzędziem zarządzania ryzykiem. Jest zgadywaniem w ładnym opakowaniu. Szczególnie, kiedy brakuje danych z poprzednich realizacji. Nikt nie wraca do starych projektów i nie sprawdza: ile naprawdę zajęło to, co estymowaliśmy na trzy miesiące? Ile rzeczy doszło w trakcie? Ile razy klient zmienił zdanie? Jeśli estymacja nie opiera się na schematach wyciągniętych z twardych danych – to nie jest estymacja. To nadzieja.

I tu jest pułapka. Kiedy termin jest nierealny, a zakres za duży, zespół zaczyna ciąć. Ale nie ciąć zakres – bo na to nikt nie pozwolił.

• Ciąć jakość.
• Ciąć testy.
• Ciąć dokumentację.
• Ciąć to, czego nie widać na demo.

I przez chwilę wygląda na to, że „dajemy radę”. Aż nagle przestajemy dawać radę – i wtedy wszyscy zaczynają szukać winnego w zespole.

Zadaję liderom jedno pytanie: kiedy ostatnio ktoś z Twojego zespołu powiedział Ci wprost, że plan jest nierealny? Jeśli odpowiedź brzmi „dawno” albo „nigdy” – to nie znaczy, że masz świetne plany. To znaczy, że masz kulturę, w której ludzie nie czują się bezpiecznie, żeby się odezwać.

Widzę to szczególnie w firmach, które rosną szybko. Kiedy było 15 osób, CEO rozmawiał z każdym i czuł puls organizacji. Przy 60-80 osobach ten kontakt znika. Między CEO a juniorem jest już trzech ludzi. I każdy z nich filtruje informację w górę – bo nikt nie chce przynosić złych wieści szefowi. Efekt? CEO żyje w bańce. Myśli, że jest dobrze, bo nikt mu nie mówi, że jest źle.

A w tym samym czasie zespół nie jest chroniony przed tak zwanymi strzałami z lasu. Klient zmienia zdanie w piątek, w poniedziałek jest nowy priorytet. Inny stakeholder obchodzi lidera i idzie prosto do dewelopera z „pilnym” tematem. Product owner dodaje coś do sprintu w środku sprintu, bo „to tylko mała zmiana”. Nie ma jednego właściciela decyzji, nie ma bufora między chaosem biznesowym a codzienną pracą zespołu.

I co wtedy? Widać zmęczenie – realne, namacalne – po liderach i po zespole. Narasta w nich frustracja. Dochodzi do takiego momentu, że już trochę im się nie chce. Nie dlatego, że są leniwi albo nie zależy im na projekcie. Dlatego, że nikt nie szanuje ich czasu, ich uwagi i ich ekspertyzy. Kiedy doświadczony deweloper mówi „to nie zmieści się w sprincie”, a ktoś odpowiada „damy radę, ogarnijcie to” – to jest moment, w którym tracisz zaangażowanie. Nie od razu. Ale po trzecim, piątym, dziesiątym takim razie.

Mógłbym opowiadać o tym na podstawie samych obserwacji, ale dane mówią to samo. Raport DORA 2024 – jeden z najbardziej wiarygodnych w branży – pokazuje coś niepokojącego. Udział firm, które klasyfikują się jako „high performers” w delivery, spadł z 31% do 22% rok do roku. Jednocześnie udział „low performers” wzrósł z 17% do 25%. Branża systemowo dowozi gorzej, nie lepiej.

I nie chodzi o to, że ludzie nagle zapomnieli, jak pisać kod. Chodzi o to, że systemy wokół nich – procesy, decyzje, struktury – nie nadążają za rosnącą złożonością. Więcej klientów, więcej projektów, większa presja – i te same stare nawyki w zarządzaniu zakresem i oczekiwaniami. Firma, która miała 20 osób i trzy projekty, zarządzała intuicyjnie – i działało. Ta sama firma przy 80 osobach i dwunastu projektach próbuje zarządzać tak samo – i się dziwi, że delivery pada.

Problem tego, że delivery się sypie, jest na wielu poziomach. To nie jest jeden punkt awarii. To cały łańcuch:

• źle ustawiony zakres prowadzi do nierealistycznego terminu,
• nierealistyczny termin prowadzi do presji na zespół,
• presja prowadzi do cięcia jakości,
• cięcie jakości prowadzi do bugów i przeróbek,
• przeróbki prowadzą do większych opóźnień.

To jest takie koło, które się samo natęża – takie perpetuum mobile. I im dłużej się kręci, tym trudniej je zatrzymać.

Jest za to przykład jednej z firm z jakimi pracowałem – projekt możę być dostarczony cztery tygodnie przed terminem, 25% poniżej budżetu. Kiedy myślę, co zrobili inaczej, odpowiedź nie brzmi „mieli lepszych programistów”. Postawili na wczesne prototypy i governance na samym starcie. Zanim ktokolwiek ruszył z kodem, ustalili jasne ramy decyzyjne, wyrzucili z zakresu to, co nie było krytyczne, i zbudowali prototypy, żeby zweryfikować założenia, zanim staną się zobowiązaniami. Nudne? Może. Ale to, co nudne na starcie, oszczędza dramatów na końcu. Nikt nie lubi spędzać dwóch tygodni na doprecyzowaniu zakresu i governance, kiedy „moglibyśmy już kodować”. Ale ci, którzy to robią, kończą przed terminem. Ci, którzy tego nie robią – kończą na moim warsztacie, szukając odpowiedzi na pytanie „dlaczego znowu nie dowieźliśmy”.

Schemat jest prosty i powtarzalny. Firmy, które inwestują czas przed startem projektu – w porządne discovery, w realistyczny zakres, w jasne ramy kto i co decyduje – dowożą.

Firmy, które traktują discovery jak formalność, rzucają się do kodu i modlą się, żeby wyszło – nie dowożą. I potem szukają problemu w zespole, podczas gdy problem siedział w sali konferencyjnej od samego początku.

Nie zamierzam mówić, że musisz „zmienić kulturę organizacji”. To brzmi pięknie na konferencji i nie znaczy kompletnie nic w poniedziałek rano. Zamiast tego dam Ci jedno konkretne pytanie, które możesz zadać na najbliższym spotkaniu dotyczącym nowego projektu.

To pytanie brzmi: „Co wyrzucamy z zakresu?”

Nie „co dodajemy”. Nie „jak przyspieszymy”. Nie „kogo jeszcze wciągniemy do projektu”. Tylko: co wyrzucamy. Bo jeśli odpowiedź brzmi „nic, wszystko jest priorytetem” – to właśnie patrzysz na projekt, który się posypie. Wszystko nie może być priorytetem. Kiedy wszystko jest ważne, nic nie jest ważne. I wtedy zespół sam zaczyna podejmować decyzje o tym, co robić, a czego nie robić – bo nikt wyżej tego nie zrobił za nich.

Drugie pytanie, równie ważne: „Czy termin, który podaliśmy, opiera się na danych z naszych poprzednich realizacji – czy na nadziei?” Jeśli nie macie nawyku wracania do estymacji po zakończeniu projektu i porównywania ich z tym, co faktycznie zajęło – zacznijcie. To nie wymaga żadnego nowego narzędzia. Wymaga jednego arkusza i uczciwej rozmowy raz na kwartał.

I trzecia rzecz, najtrudniejsza. Zapytaj swojego tech leada, project managera albo architekta – na osobności, nie na forum – „Czy jest coś w tym projekcie, o czym powinienem wiedzieć, a czego mi nikt nie mówi?” I potem wysłuchaj odpowiedzi, nie tłumacząc się i nie broniąc decyzji. Jeśli ktoś Ci powie prawdę, a Ty zareagujesz obroną, to była ostatnia prawda, którą od niego usłyszałeś.

Pamiętacie tego CEO, od którego zacząłem? Nie miał problemu z ludźmi. Miał problem z tym, że nikt w organizacji nie miał odwagi powiedzieć: ten zakres jest nierealny, a ten termin to fikcja. Kiedy to nazwaliśmy – napięcie zaczęło spadać jeszcze tego samego dnia. Nie dlatego, że coś zmieniliśmy w procesie. Dlatego, że wreszcie ktoś powiedział głośno to, co wszyscy wiedzieli.