Warsztaty projektowe przed wdrożeniem oprogramowania: Dlaczego faza discovery decyduje o powodzeniu projektu IT

Wiele firm zaczyna projekt IT od miejsca, w którym najłatwiej „pokazać postęp": od pisania kodu. Na slajdach szybko pojawiają się ekrany, w backlogu przybywa zadań, a zespół ma poczucie, że „to już się dzieje". Problem w tym, że tempo wdrożenia nie jest tym samym co trafność wdrożenia. Jeśli na starcie nie ma jasności, jaki problem biznesowy ma zostać rozwiązany, projekt zwykle kończy się jednym z trzech scenariuszy: przekroczeniem budżetu, opóźnieniem albo dostarczeniem systemu, z którego nikt nie chce korzystać.

Nie jest to teoretyczne straszenie. Według często cytowanych analiz rynku (m.in. raportów Standish Group) znaczna część projektów IT nie spełnia pierwotnych założeń — w praktyce mówi się nawet o okolicach 70% inicjatyw, które nie dowożą w pełni zakresu, czasu lub budżetu. W grudniu 2021 r., w realiach post-pandemicznych, presja na cyfryzację tylko to nasila: firmy przyspieszają transformację, a rynek IT jest rozgrzany do czerwoności, więc błędy kosztują więcej niż wcześniej — także dlatego, że trudno „dorzucić" do zespołu brakujących specjalistów.

Właśnie tu pojawiają się warsztaty projektowe i faza discovery — etap, który dla części organizacji wciąż bywa traktowany jak „zbędny formalizm", a w praktyce bywa różnicą między projektem, który dowozi wartość, a projektem, który dowozi frustrację. Dobrze przeprowadzone warsztaty przed rozpoczęciem prac deweloperskich drastycznie zwiększają szanse powodzenia, bo przenoszą energię zespołu z „budujmy cokolwiek" na „zbudujmy to, co ma sens i da się wdrożyć".

Faza discovery (często realizowana jako warsztaty projektowe) to uporządkowany proces zrozumienia potrzeb biznesowych, zbadania obecnych procesów i ograniczeń oraz przełożenia tego na plan wdrożenia oprogramowania. To moment, w którym organizacja odpowiada na pytania „po co?" i „co dokładnie?", zanim zacznie odpowiadać na „jak to zakodować?". W praktyce discovery łączy zbieranie wymagań, analizę biznesową oraz wstępne planowanie projektu w sposób, który daje wspólny obraz sytuacji wszystkim interesariuszom.

Różnica między podejściem „zaczynamy kodować od razu" a profesjonalnym discovery jest podobna do różnicy między budowaniem domu „na oko" a rozpoczęciem od projektu architektonicznego. Nikt rozsądny nie zaczyna murować bez planu, bo ściany mogą stanąć, ale potem okazuje się, że nie ma gdzie poprowadzić instalacji, schody nie mieszczą się w klatce, a okna wychodzą na stronę, której nikt nie chciał. Z oprogramowaniem jest podobnie: można szybko stworzyć pierwszą wersję, tylko że później koszt „przesuwania ścian" w systemie bywa ogromny.

Czas trwania warsztatów bywa różny. Dla prostszych inicjatyw discovery zamyka się w kilku dniach, przy bardziej złożonych projektach — szczególnie tam, gdzie jest wiele procesów i integracji — może potrwać kilka tygodni. To nadal ułamek całego harmonogramu, ale etap o nieproporcjonalnie dużym wpływie na wynik. Ważne też, że discovery nie polega na produkowaniu dokumentów „do szuflady". Dobrze poprowadzone warsztaty kończą się materiałami, które realnie prowadzą projekt dalej: pozwalają ocenić opłacalność, ustalić priorytety i uniknąć sytuacji, w której zespół dowiaduje się o kluczowych wymaganiach dopiero w trakcie wdrożenia.

Warsztaty projektowe działają wtedy, gdy przy stole znajdują się osoby, które razem tworzą pełny obraz: celów, procesów i ograniczeń. Po stronie firmy zamawiającej potrzebny jest ktoś, kto podejmuje decyzje i potrafi je obronić biznesowo — właściciel, dyrektor lub osoba odpowiedzialna za obszar, którego dotyczy wdrożenie oprogramowania. Bez takiej roli discovery często kończy się listą „fajnych funkcji" bez rozstrzygnięć, co jest ważniejsze, a co można odłożyć.

Drugą krytyczną perspektywą jest ekspert domenowy — osoba, która zna procesy „od podszewki", wie, gdzie są wyjątki, obejścia, ręczne kroki w Excelu i dlaczego pewne rzeczy „zawsze robiło się tak". W projektach IT to właśnie niuanse procesu najczęściej zabijają estymacje i harmonogramy, bo wychodzą dopiero wtedy, gdy system jest już budowany. Trzecią grupą są przyszli użytkownicy: ludzie, którzy będą pracować w systemie codziennie. Ich udział nie jest „miłym dodatkiem", tylko sposobem na uniknięcie sytuacji, w której organizacja kupuje narzędzie, a potem dziwi się, że zespół go nie używa, bo jest niepraktyczne.

Po stronie wykonawcy zwykle potrzebni są: analityk biznesowy, który prowadzi zbieranie wymagań i potrafi przełożyć język biznesu na wymagania; architekt rozwiązań, który oceni realność pomysłów w kontekście integracji i ograniczeń; oraz project manager, który zadba o ramy, ryzyka i komunikację. Brak którejkolwiek z tych ról prowadzi do luk, które wychodzą późno — a późne odkrycia w projekcie IT są niemal zawsze drogie.

Dobre discovery ma rytm: od zrozumienia „dlaczego" i „jaki sukces ma wyglądać", przez uporządkowanie procesów, aż po decyzje o priorytetach i ryzykach. Na początku warsztatów ustala się cele biznesowe w sposób mierzalny. Różnica między celem „chcemy system" a celem „chcemy skrócić czas obsługi zamówienia o 50%" jest fundamentalna. Pierwszy nie prowadzi do decyzji, drugi pozwala ocenić, czy projekt dowozi wartość i co naprawdę trzeba zbudować.

Kolejnym krokiem jest mapowanie procesów „as-is" — czyli jak firma działa dziś — oraz „to-be", czyli jak ma działać po wdrożeniu. Ten element bywa zaskakująco odkrywczy, bo często okazuje się, że różne działy mają inne rozumienie tego samego procesu, a część pracy odbywa się „między systemami": w mailach, telefonach i arkuszach. Dopiero gdy proces jest narysowany i nazwany, widać, które etapy są wąskim gardłem, gdzie powstają błędy i które dane są potrzebne, by w ogóle podejmować decyzje.

W trakcie discovery identyfikuje się również integracje z istniejącymi systemami. W praktyce wiele projektów wykłada się nie na „zbudowaniu aplikacji", lecz na połączeniu jej z tym, co już działa: bazą klientów, magazynem, finansami, raportowaniem. Integracje potrafią mieć ograniczenia formalne (np. brak dostępu do danych), organizacyjne (kto jest właścicielem systemu) albo procesowe (kiedy dane są aktualizowane). Jeśli wyjdą dopiero na etapie wdrożenia, zaczynają dyktować harmonogram.

Podczas warsztatów dochodzi też do priorytetyzacji funkcjonalności, tak aby projekt miał sensowny zakres na start i drogę rozwoju. Zwykle porządkuje się to w krótkiej, wspólnej strukturze, na przykład:

• co jest niezbędne, żeby proces działał od pierwszego dnia,
• co daje największy efekt biznesowy przy rozsądnym nakładzie,
• co może poczekać na kolejne iteracje,
• co jest ryzykowne i wymaga dodatkowego sprawdzenia.

Równolegle omawia się ryzyka i ograniczenia: dostępność ludzi po stronie biznesu, dane (ich jakość i kompletność), zależności od dostawców zewnętrznych czy terminy wynikające z sezonowości. Na końcu warsztatów powstaje wspólna wizja produktu: nie tylko „jakie ekrany", ale „jak będzie wyglądała praca i jakie decyzje będzie dało się podejmować szybciej".

Najbardziej odczuwalną korzyścią discovery jest redukcja kosztownych zmian w trakcie projektu. Zmiana wymagania na etapie warsztatów często kosztuje godziny: doprecyzowanie, decyzję, aktualizację założeń. Ta sama zmiana na etapie wdrożenia może oznaczać tygodnie: przerobienie części systemu, zmiany w testach, poprawki integracji i przesunięcie terminu. W realiach 2021 r., przy wysokich stawkach rynkowych i ograniczonej dostępności specjalistów, cena „późnych poprawek" rośnie jeszcze bardziej.

Discovery daje też lepsze dopasowanie rozwiązania do rzeczywistych potrzeb. W projektach IT łatwo pomylić objaw z przyczyną. Biznes mówi „potrzebujemy systemu do X", bo tak to brzmi w branży, ale po rozłożeniu procesu na czynniki pierwsze okazuje się, że problem leży w danych, odpowiedzialnościach albo braku prostego kroku w procesie. Warsztaty pozwalają zadać niewygodne, ale potrzebne pytania: „Po co ta informacja?", „Kto z niej korzysta?", „Co się stanie, jeśli jej zabraknie?", „Jak dziś podejmowana jest decyzja?".

Kolejna korzyść to realistyczna estymacja czasu i budżetu. Bez discovery wycena bywa zgadywanką — opartą o ogólniki i domysły. Po warsztatach możliwe jest oszacowanie na podstawie znanych procesów, priorytetów i ograniczeń. To nie jest obietnica „że na pewno się nie zmieni", tylko zmiana jakości rozmowy: zamiast „wydaje się, że", pojawia się „wiemy, że w zakresie jest to i to".

Ważny efekt, którego nie widać w Excelu, to większe zaangażowanie zespołu klienta. Jeśli użytkownicy i decydenci uczestniczą w definiowaniu rozwiązania, rośnie poczucie współwłasności. To później ułatwia wdrożenie: ludzie rozumieją, dlaczego system ma tak działać, i chętniej go używają.

Dobrym przykładem z praktyki jest firma produkcyjna, która planowała projekt systemu do planowania produkcji. W wyjściowym opisie problem brzmiał jednoznacznie: „nie umiemy planować, potrzebujemy narzędzia". Podczas warsztatów discovery, po przejściu przez procesy i dane, wyszło jednak, że największym problemem nie jest samo planowanie, tylko brak aktualnej informacji o stanach magazynowych i rozbieżności między tym, co „jest na papierze", a tym, co fizycznie leży na półce. W takim układzie nawet najlepszy system planistyczny generowałby złe plany, bo bazowałby na złych danych. Zmiana zakresu na uporządkowanie danych i przepływu informacji uchroniła firmę przed inwestycją w rozwiązanie, które wyglądałoby dobrze w ofercie, a nie zadziałałoby w realnym procesie.

Faza discovery jest absolutnie nie do pominięcia, gdy organizacja ma złożone procesy biznesowe, które różnią się w zależności od działu, produktu czy typu klienta. W takich przypadkach „standardowy" opis procesu zwykle jest uproszczeniem, a projekt IT żyje od wyjątków. Warsztaty pozwalają te wyjątki zidentyfikować i zdecydować, jak je obsłużyć, zanim staną się źródłem konfliktów w trakcie wdrożenia.

Discovery jest też szczególnie ważne tam, gdzie występuje wiele integracji z istniejącymi systemami. Każda integracja to nie tylko kwestia danych, ale również odpowiedzialności, dostępów, cykli aktualizacji i ryzyk operacyjnych. Jeśli projekt ma obsługiwać wiele grup użytkowników o różnych potrzebach — np. sprzedaż, operacje, finanse i zarząd — warsztaty są sposobem na zbudowanie wspólnego języka i uniknięcie sytuacji, w której system jest „dobry dla jednych" i „nieużywalny dla drugich".

Warto też mocno podkreślić rolę discovery w projektach o większym budżecie. Im większa inwestycja, tym droższy jest błąd w założeniach. Dla firm bez wcześniejszych doświadczeń w projektach IT warsztaty pełnią dodatkową funkcję: ustawiają oczekiwania co do współpracy, decyzyjności i tego, ile czasu po stronie biznesu naprawdę trzeba przeznaczyć na sensowne wdrożenie oprogramowania.

Jednocześnie nawet w mniejszych inicjatywach skrócone warsztaty — czasem nawet jednodniowe — potrafią znacząco podnieść jakość efektu. Nie chodzi o rozbudowane artefakty, tylko o to, by nie ruszać w drogę bez mapy.

Po dobrze przeprowadzonej fazie discovery firma nie zostaje z „wrażeniem, że było miło", tylko z konkretnymi materiałami, które da się wykorzystać w kolejnych etapach. Najczęściej powstaje specyfikacja wymagań, czyli uporządkowany opis tego, co system ma robić oraz jakie są ograniczenia i założenia. Nie musi to być dokument liczący setki stron, ale powinien być wystarczająco precyzyjny, by różne osoby rozumiały zakres tak samo.

Równolegle powstaje mapa procesów biznesowych w wariancie obecnym i docelowym, co pomaga nie tylko w implementacji, ale też w zarządzaniu zmianą w organizacji. Zwykle warsztaty kończą się listą funkcjonalności z priorytetami, dzięki czemu wiadomo, co powinno trafić do pierwszej wersji, a co może być rozwijane w kolejnych iteracjach. W wielu projektach pojawia się także wstępna architektura rozwiązania w sensie „jak to się ze sobą łączy" — na tyle, by świadomie zaplanować integracje i dane, bez wchodzenia w technologiczne detale.

Do tego dochodzi harmonogram z kamieniami milowymi i bardziej realistyczna estymacja budżetu. Te elementy są ważne nie dlatego, że „ładnie wyglądają", tylko dlatego, że stają się punktem odniesienia w rozmowach: gdy pojawiają się nowe pomysły albo zmieniają się priorytety, można wrócić do ustaleń i świadomie zdecydować, co to zmienia w zakresie, czasie i kosztach.

W praktyce taki zestaw rezultatów działa jak kontrakt porozumienia między klientem a wykonawcą: wspólne rozumienie tego, co ma zostać zbudowane, dlaczego i w jakiej kolejności. To najlepszy sposób na ograniczenie rozczarowań po obu stronach.

Warsztaty projektowe i faza discovery to nie „dodatkowy etap", który spowalnia projekt IT, tylko inwestycja, która przyspiesza dowożenie wartości i obniża ryzyko. Czas poświęcony na zrozumienie celów, uporządkowanie procesów, doprecyzowanie wymagań i ustalenie priorytetów zwraca się wielokrotnie: mniejszą liczbą kosztownych zmian, lepszym dopasowaniem rozwiązania do realnych potrzeb oraz płynniejszym przebiegiem wdrożenia.

Warto spojrzeć na własne podejście do projektów IT i zadać sobie proste pytanie: czy organizacja ma dziś większy problem z brakiem systemu, czy z brakiem jasności, co ten system ma zmienić w biznesie? Jeśli to drugie, discovery nie jest formalnością — jest warunkiem sensownej decyzji inwestycyjnej.

W 2021 roku, gdy firmy po doświadczeniach pandemicznych mocno przyspieszają cyfryzację, profesjonalne podejście do inicjatyw IT przestaje być luksusem. Staje się koniecznością, zwłaszcza gdy stawka to nie „kolejna aplikacja", ale sprawność działania firmy w kolejnych latach.

— Maciej