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?

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ę.

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.

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.

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.

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