Projekt IT pod lupą: obserwacje, wyzwania i dobre praktyki 

Większość ludzi myśli, że projekty IT to prosty proces: są wymagania, jest kod i powstaje gotowy produkt. W praktyce realizacja projektów IT zaczyna się od pozornej jasności, a dopiero w trakcie pracy wychodzi na jaw, jak wiele rzeczy nie zostało doprecyzowanych. To właśnie wtedy projekt przestaje być zadaniem technicznym, a zaczyna być ciągłym procesem decyzji, rozmów i kompromisów.

Większość projektów nie zaczyna się od problemów, a od przekonania, że wszystko jest jasne. Jest dokumentacja, pierwsze estymacje, a z pierwszych konsultacji wszyscy wychodzą z przekonaniem „wiemy, o co chodzi”. Wszystko działa do momentu, gdy pojawia się pierwsze pytanie, na które nikt nie zna odpowiedzi. Nie dlatego, że ktoś coś zaniedbał, ale dlatego, że dopiero w trakcie pracy pojawiają się nowe kwestie, których pierwsze, ogólne ustalenia nie zawierały.

Projekty rzadko upadają nagle. Częściej „rozjeżdżają się” stopniowo – przez serię drobnych decyzji, niedopowiedzeń, zmian po stronie klienta, niejasnych wymagań czy zwykłych ludzkich nieporozumień.

Z perspektywy zespołów GOTOMA, które odpowiadają za generalne wykonawstwo projektów IT, widać to bardzo wyraźnie. Każdy projekt jest inny, ale pewne wzorce powtarzają się nieustannie: niepewność na starcie, konieczność doprecyzowywania wymagań, zderzenie oczekiwań biznesu z realiami technicznymi, presja czasu. A pomiędzy tym wszystkim – ludzie, którzy muszą podejmować decyzje, brać za nie odpowiedzialność i utrzymywać ciągłość projektu.

Realizacja projektów IT i niejasne wymagania na starcie – norma, nie wyjątek

W teorii realizacja projektów IT powinna być uporządkowana już od samego początku, ale w praktyce często jest odwrotnie. Na tym etapie zespół sporo operuje uproszczeniami – nawet jeśli istnieją ogólne założenia i dokumentacja. Im bliżej konkretów, tym szybciej pojawiają się pytania, na które nikt nie ma jednoznacznej odpowiedzi.

W jednym z projektów developer otrzymał zadanie przygotowania wykresu dla operatora. Problem polegał na tym, że system zbierał około tysiąca różnych sygnałów z czujników. Na poziomie zadania zapisano jedynie, że na ekranie mają być „potrzebne dane”. Pojawiło się więc pytanie: które dane są istotne? W dokumentacji nic na ten temat nie było. Dopiero zorganizowanie spotkania z konsultantem i przedstawicielem biznesu pozwoliło ustalić, jakie informacje faktycznie są kluczowe dla operatora.

Podobne sytuacje pojawiają się w projektach finansowych, e-commerce czy integracyjnych. W jednym z projektów po spotkaniu z podwykonawcą wydawało się, że wszystko jest jasne i możliwe do realizacji w rozsądnym czasie. Dopiero rozmowa z klientem wykazała, że wymagania po jego stronie nie były do końca ustalone. Co więcej, zespół wchodził wtedy w obszar, który był dla niego zupełnie nową domeną, a w tym sektorze jego członkowie jeszcze nie prowadzili projektów. W efekcie konieczne były intensywna praca, doprecyzowywanie założeń i spora liczba nadgodzin, aby dotrzymać terminu.

Niejasność wymagań nie wynika wyłącznie z braku dokumentacji. Często klient sam jeszcze do końca nie wie, czego potrzebuje. Zdarza się, że dopiero gdy zobaczy pierwszą wersję rozwiązania, okazuje się, że jego założenia nie działają. Dlatego tak ważne jest, aby już na etapie pierwszych rozmów o projekcie IT zakładać od początku, że wymagania, na których realizacja projektów IT się opiera, będą się zmieniać, a fundamentem projektu IT, poza dokładną dokumentacją, jest przede wszystkim dialog i wspólna komunikacja.

Ten sam cel, różne interpretacje

Jednym z bardziej zaskakujących momentów, jakie niesie ze sobą realizacja projektów IT, jest ten, w którym okazuje się, że wszyscy mówią o tym samym, ale rozumieją to zupełnie inaczej. Różne interpretacje pojawiają się zarówno po stronie klienta, jak i wewnątrz zespołu.

Dobrym przykładem jest projekt związany z formularzem w wewnętrznym systemie. Project Manager, developer i klient mieli zupełnie inne wyobrażenie tego, jak ma on wyglądać. Jedni myśleli o interaktywnym i rozbudowanym interfejsie, inni zaś o prostej tabeli z polami tekstowymi. Dopiero rozmowa, w której przeanalizowano oczekiwania i możliwości, pozwoliła ustalić rozwiązanie, które satysfakcjonowało każdą ze stron.

Podobnie było przy integracji systemów w branży budowlanej. Technicznie wszystko działało zgodnie z założeniami. Problem pojawił się w momencie prezentacji. Okazało się, że system nie do końca spełnia potrzeby użytkowników. Patrzyli oni na system nie jak na „integrację”, tylko jak na element swojej codziennej pracy. W tym kontekście rozwiązanie po prostu nie działało. To pokazuje, że nawet jeśli cel biznesowy jest wspólny, to sposób jego realizacji bywa różnie rozumiany przez poszczególne grupy użytkowników. Tego typu sytuacje nie wynikają z błędów jednej strony, ale z braku zrozumienia kontekstu.

Dlatego zespoły, które skutecznie dowożą projekty, bardzo szybko uczą się jednej rzeczy: kluczowe jest nie tyle samo naprawienie produktu, ile ujednolicenie rozumienia celu. Zespoły GOTOMA często wykorzystują do tego diagramy, drzewka logiczne, makiety czy proste rozrysowania procesu, nawet w najprostszych narzędziach. Cel jest jeden: każdy, niezależnie od roli, powinien widzieć ten sam obraz projektu.

Drobiazgi, które wracają z podwójną siłą

Gdy zaczyna się realizacja projektów IT, odpuścić kwestie, które wydają się nieistotne. W końcu są „ważniejsze rzeczy”, takie jak architektura, funkcjonalność, dalszy rozwój. Ale detale nie znikają. W końcu wracają, czasem ze wzmocnioną siłą.

Najwięcej „małych rzeczy” kryje się często w kwestiach technicznych, które na pierwszy rzut oka wyglądają banalnie. Integracja z zewnętrznym systemem API – wydaje się prostym zadaniem. Dopiero później okazuje się, że działa ono tylko w określonym środowisku, nie obejmuje wszystkich potrzebnych funkcji albo wymaga dodatkowego oprogramowania-pośrednika. To potrafi podnieść czasochłonność nawet o kilkaset godzin.

Zdarzają się również przypadki, w których dopiero na etapie wdrożenia nowego systemu okazuje się, że część wykorzystywanych komponentów nie jest kompatybilna z przyjętym środowiskiem. Tego typu sytuacje wymagają dodatkowych dostosowań i często prowadzą do konieczności wyboru między utrzymaniem aktualności technologicznej a zapewnieniem zgodności całego rozwiązania.

Jeszcze bardziej kosztowne są sytuacje, w których na początku pominięto kontekst biznesowy. Zdarza się, że dopiero w późniejszych etapach projektu pojawia się potrzeba rozszerzenia rozwiązania o dodatkowe kanały, np. mobilne. Gdyby taka informacja była dostępna wcześniej, możliwe byłoby dobranie technologii obsługującej wiele kanałów jednocześnie. W praktyce często oznacza to konieczność wykonania części prac podwójnie.

Do „drobiazgów” należą też kwestie organizacyjne: jasne określenie, kto jest decyzyjny w danym obszarze, do kogo zgłaszać problemy, jak dokumentować ustalenia, jakie flow stosujemy, standardy kodowania. Jeśli nie zostaną ustalone na początku, prowadzą później do niespójności, nieporozumień i dodatkowej pracy.

Środek projektu: zmiany, decyzje i kompromisy

Wraz z postępem prac rośnie liczba zależności, a każda zmiana ma coraz większy wpływ na całość projektu. Realizacja projektów IT naturalnie wiąże się ze zmianami, a ich skala bywa zaskakująca.

W jednym z projektów klient po kilku miesiącach pisania API, co oszacowano na kilka tysięcy roboczogodzin, uznał, że jego koncepcja powinna być zupełnie inna. Dotychczasowe efekty pracy trzeba było wyrzucić do kosza, bo biznes zmienił założenia. W takiej sytuacji zespół nie ma wyjścia – musi upewnić się, że decyzja jest ostateczna, uzyskać formalne potwierdzenie, ustalić nowe cele i termin realizacji, a następnie rozpocząć nowe prace w wyznaczonym kierunku. To trudne, ale czasem konieczne i uczciwe podejście, jeśli projekt ma mieć realny sens w dłuższej perspektywie.

Zwykle jednak zmiany nie wywracają projektu „do góry nogami”, ale znacząco wpływają na harmonogram i zakres prac. W takich przypadkach najważniejsze jest uczciwe podejście do klienta i rzetelne przedstawienie mu konsekwencji: jak zmieni się czas realizacji, koszty, czy da się utrzymać pierwotny deadline. Zespół szuka wtedy alternatyw, ale zawsze w oparciu o realne możliwości.

W tle tych decyzji, zmian i prac nad projektem cały czas obecny jest dylemat: szybkość kontra jakość. Teoretycznie nikt nie chce schodzić z jakości. W praktyce, gdy zbliża się twardy termin, presja biznesowa, lub zewnętrzne zobowiązania – uczciwie trzeba przyznać, że często należy podejmować trudne decyzje. Czasem oznacza to rezygnację z części funkcjonalności, czasem wybór prostszego rozwiązania, a czasem świadome zaciągnięcie długu technologicznego z założeniem, że zostanie spłacony później.

W żadnej branży nigdy nie da się pogodzić jakości z szybkością. Doświadczenie pokazuje, że pójście na takie decyzje zawsze wraca. Im więcej kompromisów na jakości, tym trudniejsza i droższa staje się dalsza praca nad projektem. Rolą zespołu jest świadome zarządzanie tym kompromisem, a nie jego ignorowanie.

Spójność w projekcie przy wielu decydentach

Z zewnątrz realizacja projektów IT wygląda jak zbiór zadań i spotkań. W praktyce to przede wszystkim ciąg decyzji, które ktoś musi podejmować – często na bieżąco i przy niepełnych informacjach.

W większych projektach rzadko zapadają one w jednym miejscu. Po stronie klienta mogą być zaangażowane różne działy – biznes, sprzedaż, księgowość, marketing, IT. Po stronie wykonawcy dochodzą Project Manager, analityk, architekt, zespół developerów, testerzy, a czasem zewnętrzni podwykonawcy. Każdy z nich patrzy na projekt z innej perspektywy i ma własne priorytety.

Utrzymanie spójności w takim środowisku to jedno z najtrudniejszych zadań w projekcie. W praktyce odpowiadają za to Project Managera i Team Leadera. To oni zbierają decyzje z różnych źródeł, filtrują je, porządkują i przekładają na konkretne zadania dla zespołu. Developerzy powinni dostawać jasne, spójne informacje – nawet jeśli po stronie „góry” toczy się intensywna dyskusja. Rolą PM-ów jest nie tylko zarządzanie harmonogramem, ale też ochrona zespołu przed chaosem decyzyjnym.

Developer nie zawsze jest osobą decyzyjną, ale pełni rolę technicznego eksperta – odgrywa więc ważną rolę w kształtowaniu opinii. Jego zadaniem jest przedstawienie możliwych rozwiązań, wraz z ich konsekwencjami. Ostateczna decyzja jednak zawsze jest rozproszona i należy do kogoś zupełnie innego – w zależności od ustaleń między wykonawcą, a klientem.

Co istotne, z perspektywy projektu brak decyzji jest znacznie większym problemem niż błędna decyzja. Złą decyzję można naprawić, natomiast brak jakichkolwiek działań może doprowadzić do zastoju i zatrzymania projektu w miejscu i straty czasu zespołu.

Realizacja projektów IT a terminy opóźnienia i realia pracy

W idealnym świecie projekt kończy się dokładnie w terminie, a wszystkie założenia działają zgodnie z planem. W rzeczywistości jednak, w pracy projektowej częściej lub rzadziej zdarzają się przesunięcia terminów.

Powody przesunięć są różne. Wynikają z niedoszacowań, nieprzewidzianych problemów technicznych, zmian w założeniach i wymaganiach, niedostępności klienta czy czasem też opóźnień po stronie firm trzecich. Jednak najczęstszym powodem opóźnień jest zbyt optymistyczne podejście do projektu na etapie szacowania. Zdarza się, że zadania szacowane na kilka godzin mogą rozciągnąć się nawet do kilku dni, szczególnie gdy zespół pracuje z nową technologią, nie zna domeny biznesowej albo musi odnaleźć się w istniejącym, często nieidealnym kodzie.

Mimo to przesunięcie daty oddania projektu traktowane jest jako ostateczność. Zespoły starają się utrzymać harmonogram, a menedżerowie planują zapas godzin na nieprzewidziane sytuacje. Chociaż przesunięcie daje dodatkowy czas na optymalizację produktu, rzadko bywa luksusem, a częściej koniecznością.

Są też momenty, w których nie ma miejsca na planowanie. Pojawiają się poprawki „na wczoraj”. W takich sytuacjach zespół reorganizuje pracę, przesuwa mniej pilne zadania, a gdy zachodzi potrzeba – sięga po nadgodziny. Kluczowe staje się wtedy przekazywanie informacji i właściwe ustalanie priorytetów.

Z perspektywy zespołu ważne jest natomiast, aby takie sytuacje były wyjątkiem, a nie standardem. W takich właśnie momentach widać, jak działa zespół. Kluczowe stają się nie tylko tempo pracy, ale przede wszystkim komunikacja i umiejętność ustalania priorytetów.

Projekt tworzą ludzie

Choć w centrum uwagi znajduje się technologia, to jednak za nią stoją ludzie. Odpowiednia atmosfera, podejście do problemów i komunikacja wyraźnie przekładają się na efektywność zespołu. Dlatego poza umiejętnościami technicznymi w grę wchodzą także zdolności interpersonalne.

Choć developerzy podkreślają, że nieporozumienia zdarzają się rzadko, drobne różnice w interpretacji zadań, stylach pracy czy doświadczeniach są naturalną częścią codzienności. Same w sobie nie są problemem – jest nim brak reakcji. Dlatego w GOTOMA duży nacisk kładzie się na dialog i jasną komunikację.

Podstawą pracy są codzienne spotkania (tzw. daily), na których bez zbędnego przeciągania omawia się postęp, blokery i problemy nad projektem. To moment, w którym problemy wychodzą na powierzchnię, zanim zdążą urosnąć. Równie ważne jest podejście samych developerów – zamiast próbować robić wszystko samemu za wszelką cenę, funkcjonuje zasada: jeśli mam z czymś problem – zgłaszam od razu.

Istotną rolę odgrywa także asertywność – po każdej stronie projektu. Nie wszystkie wymagania da się zrealizować w ramach założonego budżetu i terminu. Czasem trzeba wprost odmówić lub jasno zakomunikować, że pewne decyzje oznaczają dodatkowy koszt, przesunięcie deadline’u lub rezygnację z innych elementów.

Oszacowania i standardy pracy zespołu

Coś, czego nie da się w projektach IT przeskoczyć, to oszacowania. To one są zmorą developerów i PM-ów. Często w oszacowaniach podejmuje się próbę obliczenia godzinowo czegoś, co zdaje się być niemierzalne. Jest to jednak podstawa do rozliczeń z klientem. Dlatego konieczne jest, aby osoba odpowiedzialna za oszacowanie była świadoma. To samo zadanie może trwać zupełnie inny czas w zależności od danego języka, aplikacji czy środowiska. Oszacowanie powinno brać pod uwagę także doświadczenie osoby, która będzie za zadanie odpowiedzialna.

Spójność zespołu zapewniają jasno wyznaczone standardy pracy: wspólne podejście do architektury, logowania, obsługi błędów i struktury kodu. Do tego dochodzą uporządkowana komunikacja w postaci jednego kanału i jasny podział odpowiedzialności, które eliminują chaos informacyjny.

Ostatecznie jednak fundamentem każdego projektu jest zespół. Jeśli działają komunikacja, wzajemny szacunek i poczucie odpowiedzialności, nawet trudne sytuacje da się opanować. W przeciwnym razie nawet najlepsza technologia nie wystarczy. 

Realizacja projektów IT pod kontrolą – co naprawdę pomaga?

Z doświadczeń zespołów GOTOMA wynika, że nie ma ani jednego magicznego narzędzia ani procesu, który gwarantuje sukces. Jest natomiast zestaw praktyk, które znacząco zwiększają szanse na to, że projekt będzie prowadzony, nawet jeśli pojawią się trudności.

Kluczowe jest doprecyzowanie wymagań, realistyczne podejście do oszacowań i jasny podział odpowiedzialności. Równie ważna jest konsekwencja w działaniu, gotowość do podejmowania trudnych decyzji i umiejętność powiedzenia „nie”, gdy sytuacja tego wymaga.

Jedna rzecz powraca jednak nieustannie jako najważniejszy aspekt: komunikacja. To ona pozwala szybko reagować, wyłapywać problemy i zrozumieć cel oraz zamysł projektu.

Nie istnieją idealne projekty. Istnieją natomiast zespoły, które idealnie potrafią radzić sobie z ich niedoskonałościami. I to one stanowią o realnej wartości w świecie IT. W GOTOMA fundamentem jest przekonanie, że technologia to tylko część procesu. Reszta to ludzie, komunikacja i odpowiedzialność za decyzje – od pierwszego spotkania, aż po ostatnie wdrożenie.

Planujesz projekt IT i chcesz, żeby przebiegł bez niespodzianek opisanych w tym artykule?

Porozmawiajmy, zanim niejasne wymagania i zbyt optymistyczne szacunki zaczną kosztować Twój budżet. Opowiedz nam o swoim pomyśle – wspólnie doprecyzujemy założenia, realnie oszacujemy zakres i zaplanujemy realizację od pierwszego spotkania po wdrożenie.

Skontaktuj się z nami →

Chcesz najpierw zobaczyć, jak pracujemy? Sprawdź nasze realizacje.