Dlaczego projekt IT nie dowozi, mimo że zespół cały czas pracuje?

W projekcie może pracować kilka osób, mogą powstawać kolejne funkcje, mogą odbywać się spotkania, a mimo to produkt może być dokładnie w tym samym miejscu co miesiąc wcześniej.

To jedna z rzeczy, które najbardziej rzucają się w oczy, kiedy przejmuje się projekt po wcześniejszym wykonawcy.

Na pierwszy rzut oka wszystko się zgadza. Są developerzy. Jest backlog. Są zadania. Ktoś raportuje postęp. Kolejne elementy trafiają na środowisko testowe.

Tylko że kiedy patrzysz na cały produkt, pojawia się proste pytanie:

I właśnie tutaj zaczyna się problem.

Problemem nie zawsze jest brak pracy

W projektach IT bardzo łatwo pomylić aktywność z postępem.

Developer może przez dwa tygodnie pracować nad modułem. Projekt może mieć kilkadziesiąt zamkniętych tasków. Na spotkaniu można powiedzieć, że „dużo się dzieje".

Ale jeżeli po tych dwóch tygodniach użytkownik nadal nie może wykonać najważniejszego procesu w systemie, to z perspektywy produktu niewiele się zmieniło.

To szczególnie niebezpieczne w projektach, w których jest kilku wykonawców albo projekt był już wcześniej rozwijany przez inne osoby.

Wtedy zaczynają się pojawiać pytania:

• Kto odpowiada za całość?
• Kto podejmuje decyzję, kiedy dwa moduły są ze sobą niespójne?
• Kto sprawdza, czy nowa funkcja pasuje do istniejącej architektury?
• Kto odpowiada za integrację?
• Kto weryfikuje, czy „gotowe" oznacza rzeczywiście gotowe?
• Kto patrzy na produkt z perspektywy użytkownika, a nie pojedynczego zadania?

Jeżeli odpowiedź na te pytania brzmi „wszyscy", bardzo często w praktyce oznacza to, że nie odpowiada nikt.

Każdy może dowozić swój fragment, a projekt nadal może stać w miejscu

W jednym z projektów, który przejmowałem, problem nie polegał na tym, że wcześniej nikt niczego nie zrobił.

Wręcz przeciwnie.

Były już wykonane prace i istniały kolejne wersje aplikacji. Problem polegał na tym, że rozwój przez kolejnych wykonawców doprowadził do sytuacji, w której poszczególne elementy nie tworzyły już spójnego produktu.

Jeden wykonawca rozbudował istniejącą aplikację. Kolejny zdecydował się przepisać produkt od zera. Problem w tym, że nowa wersja nie doprowadziła projektu do dojrzałego MVP, które można było normalnie wykorzystać do zakończenia projektu i jego rozliczenia.

Z zewnątrz można było więc powiedzieć: „Przecież nad projektem pracowano przez cały ten czas."

Tylko że liczba godzin pracy nie jest miarą gotowości produktu.

Najpierw trzeba sprawdzić, co naprawdę istnieje

Kiedy przejmuję projekt, pierwszym odruchem nie powinno być: „Dobra, przepiszmy to." Ani: „Zatrudnijmy więcej developerów."

Najpierw trzeba ustalić stan faktyczny:

• Co działa? Co nie działa?
• Która wersja jest rzeczywiście używalna?
• Jak wygląda architektura? Co jest tylko prototypem?
• Co zostało zadeklarowane jako wykonane?
• Czy można wdrożyć system od początku do końca?
• Czy dane przechodzą przez cały proces?
• Czy ktoś wcześniej rozwiązał problem, który teraz próbujemy rozwiązać ponownie?

To brzmi banalnie. W praktyce potrafi zaoszczędzić tygodnie pracy.

W jednym z przejętych przeze mnie projektów analiza istniejących wersji doprowadziła do decyzji, żeby nie kontynuować automatycznie najnowszej wersji, tylko wrócić do wcześniejszej, uporządkować ją, udokumentować, uzupełnić brakujące elementy i doprowadzić produkt do stanu, w którym można go faktycznie zaprezentować.

To nie była decyzja „stara wersja jest lepsza, bo tak". Była wynikiem sprawdzenia, co rzeczywiście działa.

Drugi problem: każdy optymalizuje swój kawałek

To częsty efekt pracy kilku zespołów. Frontend jest rozwijany osobno. Backend osobno. AI osobno. Infrastruktura osobno. Integracje osobno.

A na końcu ktoś musi to wszystko połączyć. I wtedy okazuje się, że moduły są gotowe, ale produkt nie jest gotowy.

To jedna z największych różnic między realizacją zadań a odpowiedzialnością za produkt. Możesz mieć:

W projektach MedTech problem jest jeszcze większy, bo dochodzą dane rzeczywiste, bezpieczeństwo, ograniczenia infrastruktury, użytkownik końcowy i często wymagania formalne.

Dlatego patrzenie wyłącznie na pojedyncze zadania może dawać bardzo fałszywy obraz postępu.

„Gotowe" musi coś znaczyć

Jednym z najważniejszych elementów zarządzania projektem jest dla mnie ustalenie, co oznacza słowo „gotowe". Czy gotowe oznacza:

• kod został napisany?
• działa lokalnie?
• działa na środowisku testowym?
• przeszedł test?
• można go wdrożyć?
• działa razem z pozostałymi modułami?
• użytkownik może z niego skorzystać?
• spełnia wymagania biznesowe?

To nie są te same rzeczy.

W projektach, które mają presję czasu, różnica między nimi potrafi być ogromna. Można przez wiele tygodni „zamykać zadania", a jednocześnie nie zbliżać się proporcjonalnie do momentu, w którym klient może powiedzieć: „Tak, tego produktu możemy użyć."

Czasami największym problemem jest brak jednej osoby patrzącej na całość

Nie chodzi o to, że każdy projekt potrzebuje klasycznego CTO zatrudnionego na pełen etat. Nie każdy potrzebuje.

Problem pojawia się wtedy, gdy projekt jest już na tyle skomplikowany, że decyzje technologiczne zaczynają wpływać na biznes, ale nikt formalnie nie bierze za nie odpowiedzialności.

Wtedy developer może powiedzieć: „Technicznie da się to zrobić." Project manager: „To jest w zakresie projektu." Biznes: „Potrzebujemy tego przed końcem miesiąca."

A ktoś musi jeszcze odpowiedzieć: „Czy powinniśmy to w ogóle robić w tej formie?"

To jest właśnie moment, w którym potrzebna jest perspektywa technologiczna obejmująca cały produkt. Nie chodzi o pisanie większej ilości kodu. Chodzi o podejmowanie właściwych decyzji.

Więcej ludzi nie zawsze oznacza szybszy projekt

To chyba jedna z najbardziej kuszących pułapek. Projekt się opóźnia? Dodajmy developerów.

Brzmi logicznie. Tylko jeżeli problemem jest architektura, komunikacja, brak decyzji albo niejasna odpowiedzialność, dokładanie kolejnych osób może zwiększyć liczbę zależności zamiast przyspieszyć pracę.

Jeżeli pięć osób nie wie dokładnie, co ma zostać dowiezione, sześć osób nie rozwiąże tego automatycznie.

Czasami trzeba najpierw zatrzymać rozwój i odpowiedzieć na kilka prostych pytań: Co właściwie budujemy? Co już mamy? Czego brakuje? Co jest krytyczne? Czego nie robimy? Dopiero potem warto zwiększać tempo.

Najgorszy moment na zmianę technologii

Jest jeszcze jeden problem, który często pojawia się wtedy, gdy projekt zaczyna mieć kłopoty. Ktoś dochodzi do wniosku: „Technologia jest problemem. Zmieńmy stack."

I nagle zamiast dowozić produkt, zespół zaczyna budować nową wersję. Nowy framework. Nowa architektura. Nowy backend. Nowy sposób deploymentu. Nowe problemy.

Oczywiście czasami zmiana technologii jest konieczna. Ale jeżeli do końca projektu zostało niewiele czasu, decyzja o przepisaniu systemu powinna być traktowana jak decyzja biznesowa o bardzo wysokim ryzyku, a nie jak zwykła decyzja developerska.

W jednym z projektów, przy którym pracowałem, decyzja o zmianie silnika OCR została ostatecznie odrzucona na krótko przed finałem. Nie dlatego, że istniejący wybór technologiczny był idealny. Dlatego, że w tamtym momencie ważniejsze było dowiezienie działającego produktu niż rozpoczęcie kolejnego cyklu technologicznego.

Jak sprawdzam, czy projekt naprawdę posuwa się do przodu?

Nie patrzę wyłącznie na liczbę zamkniętych tasków. Patrzę na przepływ:

• Czy użytkownik może wykonać kluczowy proces?
• Czy system działa od początku do końca?
• Czy kolejne elementy integrują się ze sobą?
• Czy problemy są zamykane, czy tylko przesuwane?
• Czy każda decyzja ma właściciela?
• Czy wiadomo, co jest blokadą?
• Czy zespół pracuje nad rzeczami, które rzeczywiście przybliżają produkt do celu?

W projekcie OCR, nad którym pracowałem, bardzo szybko okazało się, że samo „działa OCR" nie jest wystarczającą odpowiedzią. Trzeba było zbudować cały przepływ: od dokumentu, przez OCR i dalsze przetwarzanie, aż po wynik dostępny dla użytkownika. Dopiero wtedy można było mówić o produkcie, a nie tylko o działającym komponencie.

Projekt może wyglądać na zajęty, ale nadal nie być na dobrej drodze

Projekt IT nie posuwa się do przodu dlatego, że ludzie są zajęci. Posuwa się do przodu wtedy, kiedy kolejne działania zmniejszają dystans pomiędzy aktualnym stanem a działającym produktem.

Czasami oznacza to napisanie kodu. Czasami integrację. Czasami test. Czasami usunięcie funkcji. A czasami decyzję, że nie będziemy teraz niczego przepisywać, mimo że technicznie znaleźliśmy rozwiązanie, które wygląda ciekawiej.

Dobry zespół developerski jest bardzo ważny. Ale nawet dobry zespół potrzebuje jasnego celu, odpowiedzialności za całość i osoby, która potrafi powiedzieć: „To nie jest jeszcze dowiezione."

I właśnie ta różnica między pracowaniem nad projektem a odpowiedzialnością za jego dowiezienie jest często miejscem, w którym projekt zaczyna odzyskiwać kontrolę.

7 pytań, które zadaję, kiedy projekt zaczyna się opóźniać

1. Co dokładnie działa dzisiaj, a nie według dokumentacji?
2. Czy użytkownik może przejść cały kluczowy proces od początku do końca?
3. Kto odpowiada za produkt jako całość?
4. Które zadania naprawdę blokują dowiezienie produktu?
5. Czy problem jest technologiczny, czy organizacyjny?
6. Czy proponowana zmiana faktycznie skróci drogę do działającego produktu?
7. Co możemy przestać robić, żeby dowieźć to, co naprawdę jest potrzebne?

Bo czasami największym problemem projektu nie jest to, że zespół robi za mało. Problem polega na tym, że wszyscy robią dużo, ale niekoniecznie to, co trzeba.