Każdy projekt IT zaczyna się od pomysłu, który ma coś zmienić. Poprawić doświadczenie użytkownika, uprościć proces, zwiększyć sprzedaż. Zanim jednak dotrze do realizacji, zamienia się on w backlog pełen zadań, priorytetów i nieporozumień. Po jednej stronie stoi Biznes, a po drugiej IT. Dwa światy, które patrzą na ten sam projekt zupełnie inaczej.
I choć cel teoretycznie jest wspólny, w praktyce często słychać:
- Klient sam nie wie, czego chce.
- Znowu nie będą tego używać.
- To wy jesteście specjalistami, mieliście rozwiązać problem.
Dwie strony, dwa języki, dwa zestawy pretensji.
Świat Biznesu
Dla Biznesu dział IT często brzmi jak osobny gatunek. Mówi w skrótach, liczy w story pointach, a na końcu pokazuje coś, co „działa”, tylko zupełnie inaczej niż się spodziewali. Z ich perspektywy:
- To wy (IT) jesteście ekspertami.
- To tylko formularz, czemu to trwa miesiąc?
- Mówiliśmy, że ma być prosto, a zrobiliście to jak rakietę kosmiczną.
Tyle, że za tymi zdaniami stoi coś więcej niż brak zrozumienia. Za nimi stoi presja czasu, budżetu, oczekiwań.
Biznes żyje w cyklach kwartalnych, celach rocznych, wskaźnikach, które trzeba dowieźć. Dla nich każda niejasność w komunikacji to nie strata w backlogu, tylko w wyniku.
Nie ma tu czasu na debugowanie intencji. Dla nich każdy projekt to inwestycja, która ma zadziałać. I nie, nie chodzi o to, żeby coś „działało”, tylko żeby coś zadziało się w sprzedaży, w doświadczeniu klienta, w procesie, w emocjach ludzi.
Dlatego IT często słyszy:
- Zróbcie to prościej.
- U nas to nie może trwać tygodniami.
- Chcemy, żeby to było gotowe przed kampanią.
Nie dlatego, że Biznes nie rozumie złożoności.Tylko dlatego, że nie może sobie pozwolić na spóźnione efekty. Jeśli projekt nie dowozi, cierpi nie kod tylko wynik finansowy, reputacja, zaufanie klienta.
Biznes myśli w kategoriach wizji, celu, sensu.
IT słyszy funkcjonalności i zakres prac.
A pomiędzy nimi znika to, co najważniejsze, czyli intencja. Przez to tak wiele projektów kończy się zdaniem: „To nie o to nam chodziło.”
Nie z powodu błędów technicznych. Tylko dlatego, że po drodze ktoś przetłumaczył sens na specyfikację, a słowa, które miały znaczyć „zmieńmy doświadczenie klienta”, stały się w backlogu: „dodaj pole w formularzu.”
I właśnie w tych różnicach języka giną pieniądze, terminy i zaufanie. Biznes nie jest wrogiem technologii. On po prostu nie żyje w jej rytmie.
Dla IT „jutro” to sprint, dla Biznesu to deadline. Dla IT „problem z integracją” to wyzwanie techniczne, dla Biznesu to powód, przez który nie działa kampania warta miliony.
I nie chodzi o to, że Biznes czegoś „nie rozumie”. Chodzi o to, że rozumie coś zupełnie innego.
Świat IT
Z drugiej strony, dla IT Biznes bywa jak czarna skrzynka:
- Nie wiedzą, czego chcą.
- Zmienili zdanie po raz trzeci w tym tygodniu.
- Nie mają procesów, a wymagają automatyzacji.
IT widzi złożoność, której Biznes nie dostrzega. To nie złośliwość. To świadomość, że każda decyzja techniczna ma swoją cenę.
Dla zespołu IT backlog to nie wizja, ale plan operacyjny, mapa zależności, ryzyk i zaległości.
IT to zespół, który wymagania ma zamienić w rzeczywistość. Dla nich backlog to mapa. Im bardziej precyzyjna, tym lepiej. Ale nawet najlepsza mapa nie pokaże, gdzie jest błoto, a gdzie ściana.
Każde niedoprecyzowanie, każde „to chyba oczywiste” może skończyć się sprintem w złą stronę. I nie dlatego, że ktoś nie potrafi. Tylko dlatego, że każde słowo ma wagę, a dla różnych ludzi może znaczyć coś zupełnie innego.
Z drugiej strony, IT czasem zapomina, że po drugiej stronie tych funkcjonalności stoi cel. Nie ticket, nie user story, tylko pomysł, który ma przynieść wartość.
Nikt nie wymyśla nowego formularza z nudów. Za każdą zmianą stoi jakaś potrzeba, frustracja lub po prostu chęć, żeby było lepiej.
Świat pośredni
Prawda jest taka, że IT to też nie jeden świat. Są ci, którzy zamawiają rozwiązanie i ci, którzy je budują.
Po stronie klienta są architekci, administratorzy, wewnętrzne IT, które musi później to utrzymać, zintegrować i obronić przed kolejną aktualizacją bezpieczeństwa.
Po stronie dostawcy jest zespół, który ma z tego stworzyć coś, co naprawdę działa stabilnie, wydajnie i tak, żeby dało się to rozwijać dalej.
To nie są te same perspektywy. I to właśnie tutaj często ginie magia.
- Dla Biznesu to proste: „Chcemy, żeby działało.”
- Dla architekta po stronie klienta: „To musi się wpiąć w istniejący ekosystem, nie rozwalić integracji i nie zjeść pamięci serwera.”
- Dla dostawcy: „Zróbmy to w taki sposób, żeby działało dobrze, szybko i nie tylko dziś, ale też za dwa lata.”
I każdy z nich ma rację. Ale jeśli nie spotkają się w jednym punkcie, to najpiękniejsze marzenie biznesowe zostaje w PowerPoincie, a najczystszy kod kończy w repozytorium bez wdrożenia.
Tu pojawia się rola technologii jako pomostu, a nie tylko narzędzia. Bo architektura to nie magia, to sposób na osiąganie realnych rezultatów. Bez niej nawet najlepszy pomysł rozleci się przy pierwszej aktualizacji.
To trochę jak z mostem: możesz mieć piękny projekt i świetny pomysł, ale jeśli nie przeliczy tego ktoś, kto wie, jak rozkłada się obciążenie to pierwszy większy ruch go zawali.
No dobrze, ale jak to wszystko rozplątać?
Im dalej w projekt, tym bardziej okazuje się, że to wcale nie problem komunikacji. To problem interpretacji. Biznes mówi o celach, IT o rozwiązaniach, a technologia po drodze próbuje znaleźć sposób, żeby jedno dało się zamienić w drugie.
Zaczynaj od sensu, nie od rozwiązania
Jeśli pierwsze zdanie brzmi „chcemy aplikację”, to znaczy, że rozmowa zaczęła się za późno. Najpierw „po co”, potem „jak”. Inaczej cały projekt to tylko próba zgadywania intencji.
To decyzja strategiczna, nie tylko analityczna i pozwala liderom uniknąć projektów, które działają, ale nie dowożą wartości.
Zadbaj o wspólny model rzeczywistości
Nie chodzi o diagramy UML, tylko o wspólne rozumienie, jak działa świat klienta. Bez tego nawet najlepsze user stories nie mają sensu.Biznes widzi proces sprzedaży, IT widzi moduł CRM, a architekt widzi integrację trzech systemów i osiem możliwych punktów awarii.
Dopóki te trzy perspektywy nie zostaną ułożone razem to każda decyzja będzie miała inne znaczenie.
Projektuj razem, a nie obok siebie
Największe nieporozumienia powstają, gdy Biznes planuje coś sam, a IT dowiaduje się o tym z prezentacji. I tu nie chodzi o więcej spotkań. Chodzi o to, żeby decyzje zapadały tam, gdzie rodzi się wiedza, czyli tam, gdzie spotykają się cel, proces i technologia.
To tu właśnie rola architekta staje się kluczowa: ktoś musi sprawdzić, czy pomysł da się wdrożyć tak, żeby działał nie tylko dziś, ale też za dwa lata.
Zamień backlog w rozmowę
Backlog nie jest listą zadań. To język, którym opowiadasz historię projektu. Każdy ticket to decyzja o tym, co naprawdę ma znaczenie. Jeśli „dlaczego” znika po drodze, projekt zaczyna się rozłazić po szwach.
Daj technologii głos
Zbyt często architektura pojawia się dopiero wtedy, gdy coś przestaje działać. A przecież to ona scala wizję z rzeczywistością. Bez niej nawet najlepsze pomysły kończą jako „proof of concept”, którego nikt nie chce utrzymywać.
Mój 5-poziomowy framework działania
Poniższy framework pokazuje, jak przejść przez pięć poziomów myślenia, dzięki którym projekt przestaje być listą zadań, a staje się inwestycją z kierunkiem, logiką i intencją, którą ktoś wreszcie pilnuje.
Wizja / Intencja – po co to w ogóle robimy?
To moment, w którym projekt dostaje duszę. Wizja nie mówi co zbudujemy, tylko dlaczego to ma w ogóle istnieć i co ma się zmienić w życiu klienta, pracownika lub firmy. Tu powstaje kierunek. Jeśli tutaj jest mgła to dalej będzie tylko zgadywanie.
Przykład: Chcemy skrócić onboarding klienta z 5 dni do 24 godzin.
Jeśli nie wiesz „po co”, to każdy następny krok będzie przypadkiem.
Cel biznesowy – jak poznamy, że się udało?
Cel biznesowy to liczba, którą można pokazać na spotkaniu zarządczym. To efekt, który musi wydarzyć się nie w aplikacji, tylko w biznesie: szybciej, taniej, czyściej, bezpieczniej, stabilniej. Tu pojawia się obietnica wartości. A wartość to jedyne, za co naprawdę płaci sponsor.
Przykłady:
- „Zmniejszymy ręczne poprawki o 60%.”
- „Obsługa zapytania: 3 min.”
- „Oferta tego samego dnia.”
Bez tego poziomu projekt nie jest inwestycją — jest kosztem.
Model rzeczywistości – co tak naprawdę dzieje się dzisiaj?
To najbrutalniejszy etap, bo zderzamy wizję z życiem.Tu odkrywamy procesy, dane, systemy, wyjątki, absurdy i „tak się zawsze robiło”. Bez tego łatwo budować rozwiązania na rzeczywistości, która istnieje tylko w prezentacjach. To tutaj zaczyna się prawdziwa analiza. I to tutaj znika 80% sensu, gdy pomijamy ten krok.
Przykład: Użytkownik musi: znaleźć klienta po PESEL → wybrać produkt → wypełnić dane → potwierdzić → wysłać
A Ty patrzysz i mówisz: „To jest 12 kroków. Możemy zrobić z tego 5.” Nie można naprawić rzeczywistości, której się nie zna.
Zasady projektowe – jaka logika musi rządzić rozwiązaniem?
To jest serce projektu.Tu powstają definicje, reguły, scenariusze, warianty, ograniczenia, architektura decyzji. To nie jest jeszcze backlog, to język, którym tłumaczymy wizję na system.Ten poziom robi różnicę między „zróbmy coś” a „wiemy, co i dlaczego robimy”.
Przykłady:
- pobrać dane z CRM
- wyświetlić 3 warianty produktu
- walidować offline/online
- generować dokumenty
- zapisać status sprzedaży
Bez zasad projektowych backlog jest chaosem w przebraniu.
Wymagania operacyjne – co dokładnie budujemy?
Dopiero tu zaczyna się świat IT. User stories, tickety, acceptance criteria, estymacje, zależności, czyli mapa zadaniowa, która musi utrzymać sens wypracowany wyżej. Ten poziom nie mówi dlaczego. On mówi jak to wdrożyć, żeby się nie rozpadło po pierwszej aktualizacji.
Przykłady:
- API ma limit 300 requestów/min
- reguły działają tylko na JSON
- dane muszą przejść przez MDM
- front działa offline 15 sekund
Ten poziom nie nada sensu projektowi — on może go tylko utrzymać albo zabić.
⭐ Złota zasada
Jeśli pomylisz kolejność to powstaje projekt, który działa, ale nie dowozi. Jeśli zrobisz to po kolei to backlog staje się logicznym przedłużeniem wizji.
Jedna drużyna
Żeby projekt miał sens, trzeba się spotkać w połowie drogi. Biznes musi zejść z poziomu wizji na poziom konkretu. IT musi podnieść się z poziomu kodu i zobaczyć szerszy kontekst.
Backlog to nie mur między światami. To język rozmowy o tym, co naprawdę ma wartość.
Kiedy obie strony to zauważą, rozmowy stają się krótsze, decyzje prostsze, a projekty sensowniejsze.
Nie o kod chodzi. Nie o tickety. Tylko o sens.
Sens w projekcie to moment, w którym inwestycja zaczyna naprawdę działać dla ludzi, dla firmy, dla klienta.
Cele obu stron są zawsze dobre. Biznes chce, żeby to działało. IT chce, żeby to działało dobrze.
I żadna z tych intencji nie jest bardziej właściwa. Sztuka polega na tym, żeby znaleźć czas na wytłumaczenie drugiej stronie o co tak naprawdę chodzi w jej języku, nie swoim.
W projekcie nikt nie jest ważniejszy. Nie chodzi o pokaz siły ani o udowadnianie, kto miał rację. Chodzi o zbudowanie czegoś, co satysfakcjonuje obie strony. Czegoś, co działa dla użytkownika, trzyma się na produkcji i ma sens dla wszystkich, którzy mieli w tym swój udział.