Czemu analityk biznesowy nie rozumie analityka biznesowego?
W projektach IT, zwłaszcza tych realizowanych dla sektora publicznego, coraz częściej spotykamy sytuację, w której po obu stronach stołu siedzi analityk biznesowy. Jeden reprezentuje wykonawcę (dostawcę), drugi instytucję publiczną (klienta). I choć teoretycznie mówią tym samym językiem zawodowym, to bardzo często się nie rozumieją. Dlaczego?
Inna perspektywa odpowiedzialności
Analityk po stronie dostawcy jest skupiony na jak najdokładniejszym zebraniu wymagań, przekładaniu ich na dokumentację analityczną i komunikowaniu się z zespołem deweloperskim (architekci, developerzy, testerzy). Jego celem jest dostarczenie rozwiązania zgodnie z zakresem, budżetem i harmonogramem.
Tymczasem analityk po stronie klienta, szczególnie instytucji publicznej, funkcjonuje w świecie ograniczeń związanych z regulacjami prawa, oczekiwaniami interesariuszy, procedur i kontroli. Dla niego "wymaganie" to nie tylko funkcja systemu, ale też uzasadnienie prawne, potrzeba społeczna, zgodność z polityką państwa i możliwość jego egzekwowania przez kontrolę.
Różne znaczenie słów
Kiedy analityk dostawcy mówi: "potrzebujemy backlogu z historyjkami użytkownika", analityk klienta może rozumieć: "chcecie uproszczonego opisu zamiast dokumentu wymagań zgodnego z rozporządzeniem". Gdy klient prosi o "akceptację interesariuszy", dostawca nie zawsze rozumie, że chodzi o formalne zatwierdzenie przez kierownictwo jednostki państwowej, a nie tylko informacyjne spotkanie.
Priorytety, które się rozmijają
Dostawca myśli o MVP i szybkiej dostawie wartości. Klient publiczny myśli o kompletności, zgodności z dokumentacją przetargową i tym, czy żaden punkt SIWZ nie został pominięty. Dla jednego szybki postęp to sukces, dla drugiego brak parafki dyrektora może oznacza wstrzymanie odbioru.
Różne otoczenie kulturowe
Dostawcy działają zwinnie, iteracyjnie, z wykorzystaniem narzędzi wspierających współpracę. Klienci publiczni często mają ograniczony dostęp do takich narzędzi, a spotkania online są formalne i protokołowane. Dla jednej strony komunikacja to codzienny stand-up, dla drugiej- pisemny wniosek i podpis kierownika projektu.
Jak się zrozumieć?
Klucz leży w empatii i świadomości, że ta sama rola może wyglądać zupełnie inaczej w zależności od miejsca w strukturze projektu. Warto na początku współpracy ustalić definicje pojęć, oczekiwania i styl komunikacji. Dobrym pomysłem jest też warsztat "poznajmy swoje ograniczenia i cele", produktem którego może być np. ustalenie DoR (Definition of Ready) i DoD (Definition of Done). Zrozumienie zaczyna się od rozmowy. A rozmowa - od założenia, że druga strona nie chce utrudnić projektu, tylko patrzy na niego przez inny pryzmat. I właśnie dlatego analityk biznesowy nie zawsze rozumie analityka.
IT Business&System Analyst
Publikacja: 16.02.2026