Za kulisami wdrożeń Projekt IT

Co naprawdę dzieje się pomiędzy analizą a wdrożeniem

Analiza podpisana, wdrożenie jeszcze się nie zaczęło — a projekt już się zmienia. To w tej „czarnej dziurze” zapadają decyzje, których nikt nie widzi, i rodzą się problemy, które wyjdą dopiero na produkcji.

Jakub Tuszyński Architekt systemów MES / WMS • 11 lat w branży

12 lipca 2026 · 15 min czytania

Wtorek, 9:40. Sala konferencyjna pachnie jeszcze kawą po spotkaniu odbiorowym. Na stole leży wydrukowany dokument analizy — sto czterdzieści stron, parafowany na każdej stronie, podpisany na ostatniej. Właściciel firmy odkłada długopis i mówi: „No to teraz już z górki. Zbudujcie to.” Wszyscy się uśmiechają. Wszyscy myślą, że najtrudniejsze jest za nimi.

Trzy tygodnie później, w zupełnie innym pomieszczeniu, dwóch programistów stoi przy monitorze. Na ekranie formularz przyjęcia towaru. Jeden pyta: „Słuchaj, a co się dzieje, jak przyjdzie dostawa, ale zamówienie było na inną jednostkę? W analizie jest napisane, że system ma to obsłużyć, ale nie ma napisane jak.” Drugi wzrusza ramionami: „Zróbmy, żeby zaokrąglał w górę, to najbezpieczniej.” I tak, w dziesięć sekund, bez niczyjej wiedzy, zapada decyzja, która za pół roku wywoła awanturę na hali.

Między tym podpisem a tym monitorem jest przestrzeń, o której prawie się nie mówi. Nie ma jej w harmonogramie jako osobnego etapu. Klient jej nie widzi. A to właśnie w niej rozstrzyga się, czy system będzie pasował do firmy, czy firma będzie musiała naginać się do systemu. Nazywam ją czarną dziurą wdrożenia.

Sedno problemu: Klient uważa, że po podpisaniu analizy projekt jest zamrożony i po prostu „się buduje”. W rzeczywistości to właśnie wtedy projekt jest najbardziej plastyczny — i najmniej widoczny. Dziesiątki decyzji zapadają bez jego udziału, a każda z nich cicho przesuwa system w jedną albo drugą stronę.

Czarna dziura: od podpisu do pierwszego działającego ekranu

Analiza kończy się dokumentem. Wdrożenie zaczyna się od momentu, w którym klient pierwszy raz widzi działający system. Pomiędzy tymi punktami mija zwykle kilka tygodni, czasem kilka miesięcy — i przez ten czas dla klienta „nic się nie dzieje”. Nie dostaje ekranów do klikania, nie ma co odbierać, więc uznaje, że projekt jest w bezpiecznej fazie technicznej, w której zespół po prostu przepisuje ustalenia na kod.

To założenie jest fałszywe — i jest bliskim krewnym błędu, który opisywałem w tekście o tym, dlaczego wdrożenia zaczynają się od technologii zamiast od procesu. Dokument analizy nigdy nie jest kompletny w sensie, w jakim wyobraża go sobie klient. Opisuje intencje i procesy z lotu ptaka, ale budowa systemu wymaga rozstrzygnięć co do każdego przycisku, każdego pola, każdego wyjątku. Analiza mówi „system rejestruje zwroty od klienta”. Programista musi wiedzieć: czy zwrot można przyjąć bez oryginalnego dokumentu sprzedaży? Czy magazynier może zwrócić część palety? Co się dzieje ze stanem, gdy towar wraca uszkodzony? Żadne z tych pytań nie było w dokumencie, bo na etapie analizy nikt o nich nie pomyślał — a teraz wszystkie muszą mieć odpowiedź, bo bez niej nie da się napisać ani linijki.

Podobny mechanizm opisywałem, pokazując najdroższy błąd podczas analizy procesów — różnica jest taka, że tam luka powstaje przy zbieraniu wymagań, a tutaj wychodzi na jaw dopiero wtedy, gdy ktoś próbuje na jej podstawie coś zbudować.

Etap 1 — Cisza po podpisie: Klient wraca do swojej pracy z poczuciem, że projekt jest „załatwiony”. Zespół wdrożeniowy zaczyna czytać dokument nie jak opis, ale jak instrukcję — i natychmiast trafia na miejsca, w których instrukcja się urywa.

Etap 2 — Setki mikrodecyzji: Architekt projektuje strukturę danych. Programista koduje ekrany. Każdy z nich kilkanaście razy dziennie napotyka pytanie, na które dokument nie odpowiada, i musi coś postanowić, żeby ruszyć dalej.

Etap 3 — Pierwszy ekran: Klient widzi wreszcie działający fragment. I dopiero teraz orientuje się, że dziesiątki tych mikrodecyzji zostały podjęte inaczej, niż by chciał — tylko nikt go o nie nie zapytał, bo wydawały się oczywiste.

Ten sam moment widziany oczami pięciu osób

Najlepiej zrozumieć czarną dziurę, patrząc na nią z pięciu różnych krzeseł. Każda z tych osób widzi ten sam projekt, ale zupełnie inny jego fragment — i to rozjechanie perspektyw jest źródłem większości późniejszych nieporozumień.

Analityk: „Opisałem proces tak, jak mi go przedstawiono. Zamknąłem dokument, klient podpisał, moja rola się skończyła.” Analityk żyje w świecie tego, co powiedziano na spotkaniach. Nie wie, ile rzeczy przemilczano jako „oczywiste”, bo dla ludzi z hali one naprawdę są oczywiste — do momentu, gdy trzeba je zaprogramować.

Architekt: „Mam dokument, ale muszę z niego zbudować spójny model danych. W trzech miejscach opis się wyklucza, w pięciu brakuje wyjątków. Muszę to poskładać, żeby całość się trzymała — więc podejmuję decyzje, które wykraczają poza to, co jest napisane.” Architekt jest pierwszą osobą, która widzi, że dokument nie jest kompletny. I często pierwszą, która milcząco go uzupełnia.

Programista: „Kod nie znosi niedopowiedzeń. Instrukcja `if` musi mieć obie gałęzie. Jeśli analiza nie mówi, co zrobić w wyjątku, ja i tak muszę coś napisać — inaczej program się wywali.” Programista podejmuje najwięcej cichych decyzji, bo pracuje na najniższym poziomie szczegółu. I zwykle nie ma czasu ani kanału, żeby każdą z nich konsultować.

Project manager: „Pilnuję terminu i budżetu. Każde pytanie do klienta to opóźnienie, więc naciskam zespół, żeby decydował sam tam, gdzie się da.” PM ma dobre intencje — chce, żeby projekt szedł. Ale jego presja na tempo jest dokładnie tym, co spycha decyzje w cień, zamiast wyciągać je na światło.

Klient: „Podpisałem analizę, zapłaciłem zaliczkę, czekam na system. Zakładam, że robią dokładnie to, co ustaliliśmy.” Klient żyje w przekonaniu, że projekt jest zamrożony. Nie wie, że w tym samym czasie zapadają dziesiątki rozstrzygnięć, które go dotyczą — bo nikt mu nie powiedział, że one w ogóle istnieją. To pierwszy krok do sytuacji, w której nie wiadomo, kto naprawdę odpowiada za sukces wdrożenia.

Analiza opisuje, co system ma robić. Wdrożenie rozstrzyga, jak dokładnie ma to robić w każdym wyjątku. Między jednym a drugim mieści się cała przestrzeń decyzji, których nikt świadomie nie zaplanował.

Skąd bierze się rozbieżność — trzy mechanizmy

Mechanizm 1: Dokument opisuje intencje, kod wymaga rozstrzygnięć

Język analizy jest z natury ogólny. „System obsłuży rozliczenie produkcji”, „użytkownik zatwierdzi dokument”, „magazyn wyda towar zgodnie ze zleceniem”. Te zdania brzmią precyzyjnie, dopóki nie próbuje się ich zaprogramować. Wtedy okazuje się, że każde z nich rozpada się na kilkanaście pytań. Kto konkretnie zatwierdza? Co się dzieje, gdy zatwierdzający jest na urlopie? Czy można cofnąć zatwierdzenie? Kto może cofnąć i do kiedy? Dokument milczy, a program milczeć nie może.

Mechanizm 2: Nowa wiedza pojawia się dopiero przy budowie

Część rzeczy da się zobaczyć dopiero wtedy, gdy zaczyna się coś składać. Architekt układający model danych odkrywa, że dwa procesy opisane osobno w rzeczywistości dzielą te same dane i wchodzą sobie w drogę. Programista budujący ekran zauważa, że sekwencja kroków opisana w analizie w praktyce nie działa, bo krok trzeci potrzebuje informacji, którą podaje się dopiero w kroku piątym. To nie jest niczyj błąd — to naturalne, że budowa ujawnia rzeczy niewidoczne na papierze.

Mechanizm 3: Presja terminu zamienia pytania w domysły

Gdyby zespół miał nieskończenie dużo czasu, każde niedopowiedzenie trafiałoby z powrotem do klienta. Ale zespół ma termin. Zadanie każdego pytania oznacza czekanie — czasem dzień, czasem tydzień, jeśli po drugiej stronie nie ma kto odpowiedzieć. Więc programista, stojąc przed wyborem „zapytać i czekać” albo „założyć coś rozsądnego i iść dalej”, wybiera to drugie. Robi to w dobrej wierze. Problem w tym, że jego „rozsądne założenie” opiera się na wyobrażeniu o procesie, a nie na tym, jak proces wygląda naprawdę na hali — a to prosta droga do tego, żeby gotowy system spotkał się z nieufnością, o której pisałem przy okazji tematu, dlaczego operator produkcji nie ufa nowemu systemowi.

Kumulacja małych rozminięć: Pojedyncza cicha decyzja rzadko jest katastrofą. Ale w czarnej dziurze zapadają ich setki. Każda przesuwa system o milimetr od tego, czego firma potrzebuje. Zsumowane, po miesiącach, dają system, który „technicznie robi to, co w analizie”, a mimo to nie pasuje do rzeczywistej pracy.

Najczęstsze błędy w zarządzaniu tym etapem

Czarna dziura nie jest nieunikniona. Staje się groźna dopiero wtedy, gdy zarządza się nią źle — albo w ogóle. Oto błędy, które widuję najczęściej.

Traktowanie podpisu analizy jako końca rozmowy

Obie strony wydychają z ulgą i przestają się kontaktować. Klient wraca do bieżączki, zespół znika w kodzie. Kanał komunikacji, który był otwarty przez całą analizę, nagle się zamyka — dokładnie w momencie, gdy jest najbardziej potrzebny.

Brak jednego decydenta po stronie klienta

Gdy pada pytanie „jak ma się zachować system w tym wyjątku?”, nie ma kto na nie odpowiedzieć w rozsądnym czasie. Właściciel jest zajęty, kierownik odsyła do drugiego kierownika, a operator, który zna odpowiedź, nie wie, że go pytają. Więc zespół decyduje sam.

Niezapisywanie decyzji projektowych

Rozstrzygnięcia zapadają w rozmowach przy biurku, w komentarzach w kodzie, w cudzej głowie. Nie ma jednego miejsca, w którym widać: „ustaliliśmy, że zwrot bez dokumentu jest niedozwolony”. Więc pół roku później nikt nie pamięta, czy to była świadoma decyzja, czy przypadek.

Jeden wielki odbiór na końcu zamiast wielu małych

Klient widzi system pierwszy raz, gdy jest już „gotowy”. Wtedy każda rozbieżność to nie korekta, tylko przeróbka — kosztowna, spóźniona i wywołująca napięcie po obu stronach.

Mylenie ciszy z akceptacją

Zespół zakłada, że skoro klient nie pyta, to znaczy, że wszystko jest w porządku. A klient milczy nie dlatego, że się zgadza, tylko dlatego, że nie ma pojęcia, co się dzieje.

Co to kosztuje, gdy pęka na produkcji

Rozbieżności z czarnej dziury rzadko wychodzą łagodnie. Zwykle ujawniają się w najgorszym momencie — na testach akceptacyjnych albo, co gorsza, w pierwszych dniach po starcie, gdy system jest już jedynym źródłem prawdy. Skala kosztu zależy od tego, jak późno problem wyszedł na jaw.

1×

koszt korekty, gdy rozbieżność wychodzi na cotygodniowym demo

5×

koszt tej samej poprawki wykrytej dopiero na testach akceptacyjnych

20×+

koszt, gdy błędne założenie wychodzi po starcie, na żywych danych

tygodnie

typowe opóźnienie startu, gdy kumulacja cichych decyzji wymaga przeprojektowania

Ale najdroższy koszt nie jest finansowy. Jest nim erozja zaufania. Klient, który po starcie odkrywa, że system działa inaczej, niż sobie wyobrażał, przestaje wierzyć zespołowi wdrożeniowemu. Zespół, obwiniany o „zrobienie nie tego”, broni się dokumentem: „przecież tak było w analizie”. Obie strony mają rację i obie czują się oszukane — a to jest gleba, na której umierają wdrożenia. Ten sam mechanizm napędza zjawisko, które opisywałem w tekście o tym, dlaczego Excel wraca po zakończonym wdrożeniu: gdy system nie pasuje, ludzie po cichu wracają do narzędzi, którym ufają.

Jak wygląda dobrze prowadzona przestrzeń między analizą a wdrożeniem

Czarnej dziury nie da się usunąć — decyzje i tak muszą zapaść. Da się ją oświetlić. Chodzi o to, żeby rozstrzygnięcia, które i tak są nieuniknione, zapadały widocznie, z udziałem właściwych ludzi i w zapisie, do którego można wrócić.

Czarna dziura pozostawiona sama sobie

Kontakt z klientem urywa się po podpisie analizy
Programista zgaduje w wyjątkach, żeby nie tracić czasu
Decyzje żyją w kodzie i w cudzych głowach
Klient widzi system pierwszy raz jako „gotowy”
Rozbieżności wychodzą po starcie, na żywych danych
Spór o to, „kto miał rację”, zamiast wspólnej korekty

Przestrzeń oświetlona i zarządzana

Kanał komunikacji zostaje otwarty przez cały etap budowy
Wyjątki wracają do klienta jako konkretne pytania z wariantami
Decyzje trafiają do jednego, wspólnego rejestru
Klient widzi działające fragmenty co tydzień lub dwa
Rozbieżności wychodzą na demo, gdy poprawka jest tania
Wspólna odpowiedzialność za kształt systemu

Krok 1: Wyznacz jednego decydenta po stronie klienta

Musi być jedna osoba, która ma mandat, żeby w ciągu dnia lub dwóch odpowiedzieć „robimy tak”. Nie komitet, nie „zapytam i wrócę za dwa tygodnie”. Bez tego zespół zawsze wybierze zgadywanie zamiast czekania.

Krok 2: Prowadź jawny rejestr decyzji projektowych

Jedna lista, dostępna dla obu stron: pytanie, warianty, wybrana odpowiedź, data, kto zdecydował. Nie musi być narzędziem — wystarczy współdzielony arkusz. Ważne, żeby żadna istotna decyzja nie zapadała wyłącznie w kodzie.

Krok 3: Pokazuj działający system co tydzień lub dwa

Krótkie demo tego, co powstało, nawet jeśli to fragment. Klient widzi kierunek i może korygować, zanim korekta stanie się przeróbką. To najtańszy sposób na wyłapanie rozminięcia założeń.

Krok 4: Zamieniaj domysły w pytania z wariantami

Gdy zespół trafia na lukę, zamiast zgadywać, formułuje pytanie z dwoma–trzema gotowymi odpowiedziami. Klientowi łatwiej wybrać z wariantów niż projektować od zera, a decyzja zapada szybko i świadomie.

Rozwiązanie w jednym zdaniu: Nie próbuj wyeliminować decyzji między analizą a wdrożeniem — one muszą zapaść. Zadbaj, żeby zapadały widocznie: z jednym decydentem, w jawnym rejestrze i przy regularnym pokazywaniu działającego systemu. Oświetlona czarna dziura przestaje być groźna.

Które informacje muszą płynąć, a które są zbędne

Częsty odruch obronny brzmi: „to zasypmy klienta wszystkim, niech decyduje o każdym szczególe”. To równie zła skrajność jak cisza. Klient nie musi wiedzieć, jak nazywa się kolumna w bazie danych ani jaki wzorzec zastosował architekt. Musi wiedzieć o rozstrzygnięciach, które zmieniają sposób jego pracy.

Rodzaj decyzji	Kto powinien rozstrzygać	Czy klient musi o niej wiedzieć
Zachowanie systemu w wyjątku procesowym (brak materiału, zwrot bez dokumentu)	Klient / decydent biznesowy	Tak — to zmienia sposób pracy
Kto zatwierdza dokument i czy można cofnąć zatwierdzenie	Klient / decydent biznesowy	Tak — to reguła organizacyjna
Kolejność pól na formularzu, układ ekranu	Zespół + użytkownik końcowy na demo	Warto pokazać, ale nie blokować
Struktura bazy danych, nazwy tabel, wzorce kodu	Architekt / programista	Nie — to wewnętrzna sprawa techniczna
Reguła zaokrąglania ilości przy niezgodności jednostek	Klient / decydent biznesowy	Tak — wpływa na stany i rozliczenia

Zasada jest prosta: jeśli decyzja zmienia to, co system robi z punktu widzenia pracy firmy — należy do klienta. Jeśli zmienia tylko to, jak jest zbudowany w środku — należy do zespołu. Większość konfliktów bierze się z pomylenia tych dwóch kategorii: albo klienta zasypuje się techniką, albo pozbawia się go decyzji, które są jego.

Checklista: czy Twoje wdrożenie ma oświetloną czarną dziurę

Po podpisaniu analizy kanał komunikacji z zespołem pozostał otwarty

Jest jedna osoba po Twojej stronie z mandatem do szybkich decyzji

Istnieje wspólny rejestr decyzji projektowych, do którego masz dostęp

Widzisz działający system co tydzień lub dwa, nie tylko na końcu

Wyjątki procesowe wracają do Ciebie jako pytania, nie jako gotowe fakty

Wiesz, które rozstrzygnięcia zapadły i dlaczego akurat takie

Ostrzeżenie: jeśli od podpisu „nic nie słyszysz” od zespołu — to nie znaczy, że nic się nie dzieje

Ostrzeżenie: pierwszy kontakt z systemem dopiero na odbiorze końcowym to sygnał, że decyzje zapadły bez Ciebie

Praktyczna wskazówka: Zapytaj zespół wdrożeniowy wprost: „ile decyzji podjęliście w ostatnim tygodniu, nie pytając mnie?”. Jeśli odpowiedź brzmi „żadnej” — albo nie budują, albo nie mówią prawdy. Zdrowe wdrożenie generuje pytania. Ich brak to najgorszy znak.

Podsumowanie

Między podpisem analizy a pierwszym działającym ekranem rozciąga się przestrzeń, w której naprawdę powstaje system. Nie w dokumencie — dokument to tylko mapa. System rodzi się w setkach mikrodecyzji podejmowanych przy monitorach, pod presją terminu, w miejscach, których dokument nie opisał. To jest czarna dziura wdrożenia.

Nie da się jej zlikwidować, bo te decyzje muszą zapaść. Da się ją oświetlić — jednym decydentem po stronie klienta, jawnym rejestrem rozstrzygnięć i regularnym pokazywaniem działającego systemu. Wtedy zmiany, które i tak by się wydarzyły, stają się widoczne i tanie, zamiast wychodzić po starcie jako kosztowne niespodzianki.

Jeśli zapamiętasz z tego tekstu jedno zdanie, niech to będzie: cisza po podpisie analizy nie oznacza, że projekt stoi w miejscu. Oznacza, że porusza się bez Ciebie. Warto zajrzeć w tę ciszę, zanim zajrzy w nią za Ciebie produkcja.

Najczęstsze pytania

Dlaczego projekt zmienia się między analizą a wdrożeniem?

Bo analiza opisuje intencje, a wdrożenie wymaga rozstrzygnięć. Dokument analizy zawsze zawiera niedopowiedzenia — miejsca, w których napisano „system obsłuży zwroty”, ale nie napisano jak dokładnie. Ktoś musi te luki wypełnić, zwykle programista lub architekt, i każde takie rozstrzygnięcie jest cichą zmianą projektu. Do tego dochodzą nowe informacje, które wychodzą dopiero gdy ktoś zaczyna budować.

Czym jest „czarna dziura” między analizą a startem wdrożenia?

To okres od podpisania dokumentu analizy do pierwszego działającego ekranu, w którym zapadają dziesiątki decyzji projektowych bez udziału klienta. Klient uważa, że projekt jest zamrożony, a w rzeczywistości jest wtedy najbardziej plastyczny. Brak widoczności tego etapu sprawia, że rozbieżności między oczekiwaniem a systemem wychodzą dopiero na testach lub na produkcji.

Kto podejmuje decyzje projektowe, których nikt nie widzi?

Najczęściej programista i architekt, w codziennej pracy, natrafiając na luki w dokumencie. Gdy analiza nie mówi, co zrobić z brakiem materiału w trakcie zlecenia, ktoś musi zdecydować — i decyduje pod presją terminu, na podstawie własnego wyobrażenia o procesie, a nie faktycznej praktyki na hali. Te decyzje rzadko trafiają z powrotem do klienta do zatwierdzenia.

Jak zmniejszyć rozbieżność między analizą a gotowym systemem?

Trzy rzeczy: częste demonstracje działającego systemu zamiast jednego wielkiego odbioru na końcu, rejestr decyzji projektowych dostępny dla klienta oraz jeden decydent po stronie klienta, który realnie odpowiada na pytania w ciągu dnia lub dwóch. Krótka pętla informacji zwrotnej zamienia kosztowne przeróbki na tanie korekty.

Czy zmiana zakresu w trakcie wdrożenia to zawsze błąd?

Nie. Część zmian to naturalne dojrzewanie zrozumienia procesu — dobrze, że wychodzą przed startem, a nie po. Problemem nie jest sama zmiana, ale zmiana niezauważona i niezarządzana: gdy zakres pełznie po cichu, bez decyzji, kto za nią odpowiada i co w zamian wypada z planu. Kluczem jest świadomość i zapis, nie sztywne blokowanie.

Zaczynasz wdrożenie i nie chcesz wpaść w czarną dziurę?

Pomagam prowadzić projekty tak, żeby decyzje między analizą a startem zapadały widocznie — z jednym decydentem, jawnym rejestrem i regularnymi demonstracjami. Umów bezpłatną rozmowę wstępną i sprawdźmy, gdzie w Twoim projekcie chowają się ciche rozstrzygnięcia.

Umów rozmowę o projekcie