Wdrożenia w IT – dlaczego to wciąż festiwal fuckupów?

Wdrożenia w IT to niestety w dużej mierze festiwal fuckupów. Już w głośnym badaniu McKinsey & Oxford University z 2012 roku wykazano, że projekty IT dostarczają średnio 56% mniej wartości, niż zakładano, a budżety są przekraczane o 45%. Współczesne badania, jak raport Boston Consulting Group (BCG) z 2024 roku, nie pozostawiają złudzeń – ponad 66% dużych projektów technologicznych rozjeżdża się z planem, albo finansowo, albo pod kątem realizacji zakresu. Brzmi strasznie? To popatrzmy na nasze osobiste doświadczenia. Przecież każdy z nas brał udział w jakimś spektakularnym pożarze, a napięcia, zmiany planów i desperackie gaszenie problemów to po prostu element tej pracy.

W tym tekście nie znajdziecie lekarstwa na ten stan, ale znajdziecie propozycję procesu projektowego, który może znacząco zmniejszyć ryzyko fuckupów. Czytając, zwróćcie uwagę na fakt, że proces jest przedstawiony z punktu widzenia projektanta. Product Ownerzy, managerowie, developerzy, testerzy – każdy ma swoje checkpointy do odhaczenia. Natomiast ten proces to przede wszystkim dobry punkt wyjścia do rozmów z waszymi współpracownikami i budowania mostów między specjalistami z różnych obszarów. O te właśnie mosty tutaj chodzi. Bo jeśli ich zabraknie, to zamiast sensownego działania mamy gaszenie pożaru wiadrem dziurawej dokumentacji i nerwowe szukanie winnych, a to raczej kiepska strategia na dowiezienie dobrego produktu.

A skąd się wziął ten proces? Przez lata jako Head of Product Design byłam zwykle angażowana w dwa momenty projektów: albo na samym początku, żeby zdefiniować produkt, albo wtedy, gdy coś już spektakularnie płonęło i trzeba było gasić pożar. Jako konsultantka czy po prostu koleżanka po fachu, regularnie wspieram w rozwiązywaniu podobnych problemów. Przez ten czas miałam okazję testować różne procesy, a że mam naturalny dar (albo przekleństwo) do wychwytywania schematów i wzorców, zaczęłam sobie te wszystkie pożary układać na kupki i analizować.

Ogromną rolę w tym całym rozkminianiu odegrał nawyk robienia szczerego i uczciwego retro. O retrospektywach pisałam więcej w tym tekście (link).

Jeszcze jedno. Z rozbudowaną wersją tego procesu pracujemy w teamie już ponad rok, dostosowując go do specyfiki naszego projektu. Natomiast traktujcie wersję, którą tu przedstawiam jako coś elastycznego, co można zmodyfikować i wdrożyć zależnie od potrzeb. Na koniec (wstępu oczywiście), ogromne podziękowania dla mojej liderki i całego zespołu – za otwartość, zaufanie i wspólne tworzenie takich rozwiązań.

Zanim zaczniemy – gdzie właściwie jesteśmy?

Żeby jeszcze doprecyzować temat tego tekstu, warto przyjrzeć się procesowi, o którym będziemy mówić. Poniższy obrazek przedstawia powszechny cykl wytwarzania produktu cyfrowego, podzielony na cztery podstawowe etapy: Discovery, Define, Develop, Deliver, wraz z ich kluczowymi składowymi.

W tym tekście skupimy się na jednym, konkretnym elemencie – powtarzającym się procesie w fazie Deliver (zaznaczonym na różowo). To właśnie tutaj tworzymy funkcjonalności, odpowiadamy na potrzeby biznesowe, technologiczne i użytkowe.  Innymi słowy – ten etap to moment, w którym pomysł przechodzi w proces realizacji i zaczyna nabierać kształtu w produkcie.

Co faktycznie wywołuje pożary we wdrożeniach?

Cyfryzacja to proces, który prędzej czy później dotknie każdego – i to nie tylko w sensie wyzwań, ale też nowych możliwości. W codziennym życiu korzystamy z usług cyfrowych, pracujemy w organizacjach przechodzących transformację, albo żyjemy w społecznościach, które z niej korzystają. W tym kontekście statystyki porażek we wdrożeniach IT, które przytaczałam wcześniej, są dla mnie szczególnie frapujące. Nie mówimy tu o pojedynczych wpadkach – te problemy powtarzają się w wielu projektach i wynikają z konkretnych schematów. I co ważne, to nie tylko moje doświadczenia – te same wzorce wyłaniają się z metaanaliz i badań nad wdrożeniami IT. A jako ktoś, kto widział ich skutki na własne oczy – i czasem próbował ratować sytuację – widzę w nich pewien wspólny mianownik.

1. Zgubione informacje w procesie, czyli ciemna strona handoveru. To te sytuacje, gdy jeden specjalista zbiera wymagania, inny je realizuje, kolejny weryfikuje, a jeszcze inny ustala priorytety. Brak komunikacji – a co za tym idzie, różne rozumienie tych samych pojęć (co jest absolutnie naturalnym i ludzkim zjawiskiem) – prowadzi do efektu głuchego telefonu. Ścieżka między osobą zbierającą wymagania biznesowe a wykonawcą (albo, co najgorsze, użytkownikiem) jest tak długa, że po drodze informacje się gubią lub przeinaczają. W efekcie powstaje produkt, który ostatecznie okazuje się zupełnie inny od tego, jaki sobie wyobrażaliśmy.

   
   

2. Zbyt duże skupienie na zadaniu, a zapomnienie o wizji produktu.
   To problem, który szczególnie widać w dużych produktach rozwijanych latami. W pewnym momencie praca w skali mikro lub meso całkowicie przesłania makro – wizję i cel. Skupiamy się na dopracowywaniu detali, ale tracimy z oczu to, po co w ogóle to robimy. A potem kończy się to klasycznie: mamy funkcjonalność dopracowaną do perfekcji, a inne leżą i kwiczą. Najgorzej, gdy wśród tych „kwiczących” znajdują się akurat te, które są dla użytkownika kluczowe.

   Jeszcze gorzej jest, gdy problem nie wynika tylko ze skupienia na detalu, ale z braku spójnej wizji. Każdy – biznes, design, development, użytkownicy – definiuje wartość produktu inaczej, a ostatecznie projekt staje się zbiorem sprzecznych priorytetów zamiast spójnego rozwiązania.

   
   

3. Czas, budżet, zakres i jakość – jeśli się nie spinają, mamy problem.

   To klasyczna sytuacja: ktoś wpada na świetny pomysł, bada rynek, analizuje użytkowników, projektuje dopracowane rozwiązanie… ale w całym tym procesie discovery nikt nie sprawdza, czy da się to w ogóle zrobić. Czy w tym czasie, przy tym budżecie i z dostępną technologią ten produkt jest realny? Problem w tym, że często zakłada się, że „jakoś to będzie”, a potem rzeczywistość bezlitośnie to weryfikuje – kończy się cięciem funkcji, szukaniem obejść i kompromisami, które rujnują pierwotną wartość produktu

   
   

4. Zmiana rzeczywistości – pierwotne założenia nie wytrzymują próby czasu

   To problem, który uderza najmocniej w duże produkty rozwijane latami. Ktoś może zrobić świetne discovery, zbadać rynek, użytkowników, zaplanować strategię… ale jeśli rzeczywistość się zmienia, wszystkie te wnioski mogą stracić aktualność. Konkurencja, potrzeby użytkowników, a czasem nawet globalne wydarzenia (wojny, pandemie) mogą kompletnie przetasować reguły gry. W efekcie produkt, który miał być innowacyjny, okazuje się przestarzały albo jego największe przewagi konkurencyjne stają się standardem. A w najgorszym scenariuszu – niepotrzebnym bublem.

   
   

5. Idealne scenariusze użytkowania? Cóż, użytkownicy myślą inaczej

   Założenie, że użytkownik będzie korzystał z produktu dokładnie tak, jak zaplanowali jego twórcy, to przepis na porażkę. Ludzie są nieprzewidywalni, działają w różny sposób, a ich kontekst nigdy nie jest taki sam. Kiedy projekt bazuje na „idealnym scenariuszu”, łatwo przeoczyć sytuacje, w których coś pójdzie nie tak. W efekcie powstają funkcjonalności, które może i są dobrze zaprojektowane, ale w praktyce okazują się frustrujące lub niezrozumiałe.

   
   

6. Brak mechanizmów uczenia się i iteracji.

   Niektóre produkty powstają w trybie „ustalamy wymagania, robimy, wypuszczamy” – i na tym koniec. Brakuje mechanizmów, które pozwalają na realne dostosowanie produktu do rzeczywistości po jego wdrożeniu. Jeśli nikt nie analizuje, jak ludzie faktycznie z niego korzystają, nie ma szans na poprawki, optymalizację czy wyłapanie błędów. Efekt? Produkt, który był świetnym pomysłem na starcie, ale nie nadąża za rzeczywistością, a jego twórcy są przekonani, że „przecież wszystko działa”.

Popatrzmy jeszcze na ten najbardziej powszechny proces z obrazka poniżej. Najpierw ktoś definiuje produkt, potem ktoś go projektuje, kolejna osoba wdraża, następna testuje. Na końcu – często po czasie – produkt trafia do użytkownika. Brzmi logicznie, prawda? No właśnie… niekoniecznie.

Pomiędzy tymi wszystkimi specjalistami mamy handovery, czyli całe morze okazji do indywidualnych interpretacji. Każdy z tych kroków jest zamknięty w swoim własnym etapie i rozciągnięty w czasie, więc pomiędzy definicją a weryfikacją zieje przepaść. Czasem ten prosty proces często jest naprawdę super. Gdy robimy nieskomplikowaną stronę internetową albo aplikację, gdzie wszystko da się łatwo zdefiniować, to poniżej opisane finezje byłyby overkillem. Natomiast w przypadku bardziej skomplikowanych i większych rozwiązań taki podstawowy proces to już nie tylko nieskuteczność – to wręcz przepis na porażkę.

I tu pojawia się pytanie, co jest celem naszego procesu i tego tekstu. Już tłumaczę. Naszym celem jest zbudowanie kilku mostów.

Pierwsze będą łączyły dziedziny: biznesową opłacalność, użytkową atrakcyjność i techniczną wykonalność. Tak, by produkt przynosił realną i mierzalną wartość, a miary były spójne między dziedzinami.

Drugie mosty będą łączyły ludzi, czyli przedstawicieli specjalizacji, którzy muszą ze sobą współpracować, a nie tylko przekazywać informacje w trybie „moja, twoja działka”.

Te wszystkie mosty będziemy weryfikować w kontekście zmian w czasie – regularnie sprawdzając, czy nasze założenia są nadal aktualne, czy technologia nie wyprzedziła naszych decyzji i czy użytkownicy nadal tego potrzebują.

Elementy skutecznego procesu projektowego

Etapy procesu projektowego

Wiemy już, co się psuje i dlaczego. Teraz czas na proces, który minimalizuje ryzyko pożarów i pozwala działać w bardziej zwinny sposób.

1. Mini discovery

Lubię ten pierwszy etap nazywać mini discovery, bo dobrze oddaje intencję, z jaką do niego podchodzimy – otwartą głowę, gotowość na naukę i zmianę. Chcemy spojrzeć świeżo na temat, skonfrontować pierwotne założenia z aktualną wiedzą, możliwościami technicznymi i zakresem projektu.

1-a Prace archeologiczne, czyli grzebiemy tu i ówdzie

To etap, w którym zaglądamy do wcześniejszych analiz, dokumentacji i wniosków z etapu discovery, analizujemy istniejące materiały i przyglądamy się makietom lo-fi – generalnie staramy się przypomnieć i zrozumieć, o co nam wtedy chodziło.

Pamiętajmy jednak, że nie chodzi o ślepe odtworzenie tamtych założeń (choć czasem może się okazać, że nadal są aktualne). Chodzi o świadomość przeszłości i konfrontację jej z rzeczywistością – a to zasadnicza różnica.

Pytanie sprawdzające: Czy po tym etapie mamy nowe informacje, które mogą wpłynąć na nasze decyzje? Jeśli nic się nie zmienia, czy na pewno patrzymy na dane z właściwej perspektywy?

Kto: projektant/ka

1-b Pierwsza randka z technologią lub wiedzą branżową + analiza danych

Zdarza się, że problem, nad którym pracujemy, jest mocno osadzony w specyfice danej branży lub silnie uzależniony technologicznie. Warto więc na tym etapie:

• Nadrobić wiedzę branżową – na tyle, by móc swobodnie projektować i rozumieć specyfikę kontekstu.

• Zidentyfikować ograniczenia technologiczne – warto poprosić developerów o research możliwości i ograniczeń, tak by wiedzieć, na czym możemy budować nasze rozwiązanie.

Pytanie sprawdzające: Czy po tym etapie rozumiemy nie tylko możliwości, ale i ograniczenia? Czy jesteśmy w stanie wytłumaczyć je innym członkom zespołu w prosty sposób?

Kto: projektant/ka, developer/ka, ekspert/ka z branży (czasem to będzie PO, czasem użytkownik, a czasem wujek Google).

1-c Kickoff, czyli herbatka u Kapelusznika

To spotkanie, na którym dzieje się magia. Serio – zobaczycie, jak spróbujecie. Na kickoff zapraszamy osoby decyzyjne i odpowiedzialne za priorytetyzację (np. PO), ekspertów z branży (czasem to również PO), developerów (ważne, żeby to były osoby, które faktycznie będą kodować!) i projektantów.

Na tym etapie:

• Wyrównujemy wiedzę.

• Priorytetyzujemy zadania.

• Weryfikujemy zakres i wcześniejsze ustalenia z punktu a i b.

• Przegadujemy ograniczenia i możliwości techniczne.

• Identyfikujemy potencjalne ryzyka.

Pytanie sprawdzające: Czy wszyscy na spotkaniu wiedzą, co jest do zrobienia, kto robi i dlaczego? Czy mamy jednoznaczne ustalenia, czy tylko „rozmawialiśmy o problemie”?

Kto: cały zespół wykonawczy (minimum to reprezentacja każdej specjalizacji).

1-d Śledztwo w toku, czyli patrzymy na problem z różnych perspektyw

Na tym etapie przyglądamy się problemowi szerzej, badając go z kilku różnych stron. Oto cztery główne obszary, które warto wziąć pod lupę:

1. Analiza konkurencji – Sprawdzamy, jak inni rozwiązują podobny problem. Nie chodzi o kopiowanie, ale o zrozumienie, jakie podejścia są już na rynku i co działa (lub nie).

2. Analiza rozwiązań w innych kontekstach – Szukamy podobnych wyzwań, ale w innych branżach lub środowiskach. Jeśli projektujemy aplikację do nauki oddychania, możemy przeanalizować mechanizmy stosowane w zegarkach sportowych, opaskach monitorujących sen czy technikach stosowanych w jodze lub metodach relaksacyjnych terapii behawioralnej.

3. Dobre praktyki i badania – Weryfikujemy aktualną wiedzę branżową i sprawdzamy, jakie są najnowsze standardy? Nie opieramy się na przestarzałych badaniach. Przykładowo: ile czasu użytkownik może czekać na reakcję systemu, zanim zacznie odczuwać frustrację? Odpowiedź na to pytanie będzie inna w zależności od momentu w historii technologii. W czasach modemów kilku sekundowe czekanie było akceptowalne. Dzisiaj, w erze szybkiego internetu, ten sam czas oczekiwania może powodować irytację.

Pytanie sprawdzające: Czy na podstawie tej analizy możemy wskazać konkretne inspiracje i wnioski, które wpłyną na naszą decyzję projektową?

Kto: projektant/ka + specjaliści do konsultacji (w razie potrzeby).

1-e Podobne sytuacje w naszym systemie

Czas na zbadanie naszego własnego podwórka. To szczególnie ważny krok, jeśli pracujemy nad większą aplikacją lub systemem. Chodzi o to, by wyjść z poziomu mikro (funkcjonalności, nad którą pracujemy) na poziom makro (cały system) i spojrzeć na problem z szerszej perspektywy.

Czy w innym miejscu naszego produktu mamy (lub mieliśmy) podobny problem? Jeśli tak, warto rozważyć zaprojektowanie rozwiązania, które będzie pasowało do obu przypadków.

Dlaczego to ważne?

• Spójność dla użytkownika – jeśli system działa konsekwentnie, użytkownik szybciej się go uczy i łatwiej go obsługuje.

• Efektywność wdrożeniowa – reużywalne rozwiązania są często łatwiejsze do zaimplementowania i tańsze z perspektywy biznesowej.

Pytanie sprawdzające: Czy nasze rozwiązanie jest spójne z innymi elementami systemu? Czy zamiast projektować coś od zera, możemy wykorzystać istniejące mechanizmy?

Kto: projektant/ka + specjaliści do konsultacji (w razie potrzeby).

1-f Konfrontacja wstępnych pomysłów z możliwościami technicznymi

Na tym etapie mamy już sporo pomysłów, ale zanim zaczniemy projektować, warto przegadać je z developerami. Lepiej od razu zweryfikować, co jest realne do wdrożenia, niż później przerabiać wszystko od nowa.

Pytanie sprawdzające: Czy nasze rozwiązanie jest możliwe do wdrożenia w realnym czasie i w ramach dostępnych zasobów? Jeśli nie, czy mamy plan B?

Kto: projektant/ka + specjaliści techniczni.

2. Projektowanie

Tak, projektowanie to dopiero piąty krok. Jeśli poprzednie etapy zostały przepracowane rzetelnie, to prawdopodobnie mamy już w głowie pomysł na rozwiązanie – albo nawet jego wstępne szkice w notatkach.

Teraz czas przekształcić to w formę wizualną. Podchodzimy do tego kroku ekonomicznie – to są nasze pierwsze, jeszcze niezweryfikowane szkice. Nie chodzi o pixel perfect, ale o wersję, która stanie się punktem wyjścia do dalszych rozmów. Ważne, by była na tyle klarowna, żeby nie pozostawiała pola do nieprawidłowych interpretacji.

3. Konsultacje

Zanim przejdziemy dalej, sprawdzamy, czy projekt jest realny i zgodny z założeniami. Czy to, co zaprojektowaliśmy, jest faktycznie do wdrożenia, czy tylko „wydaje się, że jest”? Sprawdzamy:

• Wykonalność technologiczną – czy da się to wdrożyć w założonym czasie, budżecie i bez obejść psujących jakość?

• Spójność biznesową – czy rozwiązanie nadal ma sens strategiczny i odpowiada na aktualne potrzeby?

Jeśli wszystko się zgadza – przechodzimy dalej. Jeśli nie – wracamy do projektowania i wprowadzamy poprawki.

4. Testy z użytkownikami

To moment, w którym sprawdzamy, czy nasze rozwiązanie działa tak, jak zakładaliśmy – nie tylko w teorii, ale w rzeczywistości. Czy użytkownicy rozumieją rozwiązanie i korzystają z niego zgodnie z intencją? Wybieramy metodę testowania, która pozwoli nam zweryfikować jego użyteczność i skuteczność.

Jeśli testy wypadają pozytywnie (pamiętajmy o ustaleniu miar przed ich rozpoczęciem) – przechodzimy dalej. Jeśli nie – wracamy do projektowania i wprowadzamy poprawki.

5. Dopieszczanie rozwiązania

Na tym etapie dopracowujemy finalną wersję – dbamy o detale, wizualną precyzję i spójność. To także moment na przygotowanie dokumentacji dla reszty zespołu, tak aby wdrożenie przebiegło bez nieporozumień.

6. Development

Faza development nie jest tylko dla developerów – to moment, w którym nasz projekt przestaje być szkicem, a zaczyna żyć w kodzie. Jako projektanci nie odpuszczamy – dbamy o to, by rozwiązanie było wdrażane zgodnie z założeniami, ale jednocześnie nie trzymamy się ich kurczowo, jeśli rzeczywistość mówi co innego.

To czas, kiedy rzeczy, które wyglądały świetnie na makiecie, mogą w praktyce zachowywać się zupełnie inaczej. Może coś działa wolniej niż się spodziewaliśmy? Może interakcja, która wydawała się intuicyjna, w rzeczywistości okazuje się dziwnie toporna? Nie czekamy na pożar – jeśli widzimy problem, adaptujemy rozwiązanie. Zamiast patrzeć, jak projekt schodzi z linii produkcyjnej, aktywnie wspieramy zespół, pomagając rozwiązywać problemy i trzymając kurs na najlepszy możliwy efekt.

7. Testy na działającym systemie

Testy, które robiliśmy wcześniej, były ważne, ale teraz wchodzimy na wyższy poziom – sprawdzamy, jak nasze rozwiązanie działa w rzeczywistych warunkach, na działającym systemie i prawdziwych danych. To moment, w którym teoria spotyka się z praktyką, a my możemy zobaczyć, co faktycznie działa, a co tylko wydawało się, że zadziała.

Nie wszystko da się przewidzieć na makietach i w prototypach – niektóre rzeczy wychodzą dopiero w interakcji z realnym systemem. Może animacja, która miała być płynna, szarpie? Może coś, co na statycznym ekranie wyglądało super, w praktyce wprowadza zamieszanie? Patrzymy, testujemy, analizujemy. I co najważniejsze – wyciągamy wnioski.

Super, jeśli uda się przeprowadzić testy na innej grupie użytkowników niż poprzednio – to pozwala uniknąć efektu przyzwyczajenia i daje nam świeże spojrzenie.

8. Retro + Ciasto

To moment, w którym możemy przestać gonić i po prostu spojrzeć na siebie nawzajem. Proces projektowy to nie tylko dowiezienie rozwiązania – to godziny rozmów, sporów, odkryć i decyzji, które kształtowały nie tylko produkt, ale i nas jako zespół.

A skoro wszystko gra – czas na ciasto. Można metaforycznie, można dosłownie. Chodzi o ten moment, w którym przestajemy patrzeć na roadmapę i patrzymy na ludzi obok. Bo w ostatecznym rozrachunku to nie kolejne iteracje, nie spełnione KPI, a właśnie wspołpraca – wzajemne zaufanie, szacunek i wspólna satysfakcja – decydują o tym, czy ten projekt był naprawdę dobry.

Współpraca nie dzieje się sama, trzeba ją wypracować

Współpraca nie dzieje się sama – trzeba ją zaprojektować. Samo zebranie ludzi z odpowiednimi kompetencjami nie wystarczy, jeśli proces nie wspiera interakcji i adaptacji.

W dobrze działających zespołach ludzie reagują na siebie nawzajem, dostosowują się i wspólnie rozwiązują problemy, zamiast czekać, aż „przyjdzie ich kolej”. To nie kwestia sztywnej struktury, ale mechanizmów, które pozwalają działać płynnie i skutecznie.

Nie jesteśmy komórkami w Excelu. Jesteśmy ludźmi – a to oznacza, że prawdziwa współpraca wymaga procesów, które nie tylko sprawnie działają, ale pozwalają ludziom widzieć się nawzajem i reagować, kiedy naprawdę jest to potrzebne.

Na koniec spójrzmy jeszcze raz na ten sam obrazek: Discover, Define, Develop, Deliver. Wprowadzenie nowego elementu do procesu ujawnia kluczową, choć ukrytą, prawdę – żadna z tych faz nie jest czymś stałym i niezmiennym.

Wręcz przeciwnie – każda z nich to elastyczne i przydatne narzędzie, nie tylko w czasie jej trwania, ale również na późniejszych etapach pracy nad produktem cyfrowym. W dobrze zaprojektowanym procesie etapy nie są świętością, lecz narzędziami, które stale adaptujemy i udoskonalamy.