6 mitów o pracy analityka biznesowego w IT

31 marca 2023

  • Autor: Kyryło Bieliawskyi

  • Złożoność: łatwo

  • Czas: 9 min

Cześć, nazywam się Kyrylo Bieliavskyi. Obecnie jestem Głównym Analitykiem Biznesowym, a 8 lat temu wszedłem do analizy biznesowej z szeroko otwartymi oczami i własnymi błędnymi przekonaniami na temat roli BA w IT. Wcześniej przez długi czas pracowałem w finansach, zajmowałem się budżetowaniem projektów budowlanych i analizą finansową w dużej firmie metalurgicznej. Później optymalizowałem procesy w tej samej firmie, nadzorowałem małe wewnętrzne projekty IT. Mój angielski był dobry, chciałem zdobyć ciekawą praktykę w różnych projektach, więc zmieniłem branżę na analizę biznesową IT.

W tym artykule opowiem o swoich doświadczeniach, o tym co napotkałem wchodząc do zawodu, jakie błędne przekonania panują wśród początkujących analityków biznesowych i jak to wszystko wygląda w rzeczywistości.

Mit 1: Analiza biznesowa jest łatwa

Analiza biznesowa jest łatwa

Ludzie trafiają do analityki biznesowej najczęściej na dwa sposoby. Pierwszy z nich to sytuacja, gdy specjalista w firmie IT decyduje się na zmianę działalności. Najczęściej robią to testerzy, którzy patrzą na analizę biznesową jako na obiecujący kierunek kariery.

Rozmawiałem z wieloma testerami, którzy tak zrobili. I wszyscy oni mówili mi, że z pozoru praca analityka biznesowego wydawała się dość prosta. Osoba siedzi, myśli, pisze, komunikuje się, pije kawę przez cały dzień – wydaje się, że nic trudnego. Z jakiegoś powodu ludzie rzadko zastanawiają się nad tym, jak zorganizowany jest dzień BA i dlaczego analitycy biznesowi piją aż tyle kawy.

Drugi sposób – kiedy przychodzą ludzie, którzy widzą analizę biznesową jako okazję do zdobycia pierwszej pracy w IT. Jak wyglądają obowiązki BA z perspektywy tych ludzi? Rozmawiasz z klientem, dowiadujesz się, co trzeba zrobić, przekazujesz to samo zespołowi, upewniasz się, że to zrobią – i za to właśnie dostajesz wynagrodzenie. Sam miałem takie myśli. W rzeczywistości nie jest to takie proste.

Jakie trudności pojawiają się w pracy BA

Dla analityka biznesowego ważne jest, aby przekazać niezbędne dane lub status zadania wszystkim zaangażowanym w projekt. A ten moment ” pamiętać wszystko, nie przegapić niczego” prowadzi do dużego stresu. Dlatego odporność na stres jest koniecznym kryterium, jeśli chcesz odnieść sukces w roli analityka biznesowego. Następnie przyjrzyjmy się czynnikom, które najczęściej prowadzą do przepracowania.

Ogromna odpowiedzialność. Analityk biznesowy jest w zasadzie odpowiedzialny za sukces produktu i jego zawartość przed zespołem i klientem. Wszystkie pytania dotyczące zawartości produktu będą, w taki czy inny sposób, skierowane do analityka biznesowego w celu podjęcia decyzji. A ciężar takiej odpowiedzialności za losy produktu to poważne wyzwanie.

Nadmiar komunikacji. Pod względem komunikacji analityk biznesowy jest najbardziej potrzebną osobą w projekcie. Specjalista, który ma trudności w komunikacji z innymi ludźmi, będzie miał naprawdę ciężko. Komunikować trzeba będzie bardzo dużo: z zespołem, klientem i różnymi menedżerami zewnętrznymi.

Komunikacja będzie odbywać się przez kilka kanałów jednocześnie: rozmowy telefoniczne, e-maile, czaty, komunikacja ustna. Musisz być przygotowany na ciągłe zadawanie pytań i odpowiadanie na nie, a to nie jest takie proste, jak może się początkowo wydawać.

Krytyka z różnych stron. Ktoś zawsze jest niezadowolony z analityka biznesowego, ponieważ zbyt wiele stron jest związanych z BA i zbyt wiele decyzji musi podjąć taki specjalista w ciągu dnia pracy. Nie da się wybrać opcji, która zadowoli wszystkich – testerów, programistów, klienta, kierownika projektu. Zawsze znajdzie się ktoś, kto nie będzie zadowolony – i to jest normalne. Analityk biznesowy będzie musiał „wyhodować grubą skórę” i spokojnie przyjmować krytykę od innych.

Nieregularny czas pracy. BA często pracuje z klientami „za oceanem”, dzwoniąc do nich wczesnym rankiem lub późną nocą. Z kolei zespół może znajdować się w tej samej strefie czasowej co analityk biznesowy. Współpracownicy potrzebują uwagi i komunikacji też, a to może być bardzo wyczerpujące.

Kolejny punkt nieregularności: analiza w głowie nie wyłącza się automatycznie po zakończeniu dnia pracy. Mogę siedzieć w domu na kanapie, oglądać film i jednocześnie myśleć o tym, jak zrobić skomplikowaną cechę oprogramowania.

Nagle pojawia się pomysł i mówię do żony: „Przepraszam, muszę popracować”. Otwieram laptopa, wrzucam do niego opis cechy oprogramowania, zamykam go i idę dalej oglądać film. Takie zachowanie może być irytujące dla rodziny.

Trzeba często mówić „nie”. Analityk biznesowy musi umieć powiedzieć „nie”, ponieważ w pracy będzie wiele próśb, propozycji i innych rzeczy z każdej strony komunikacji:

  • developerzy proszą o zmianę czegoś w wymaganiach, aby ułatwić im programowanie;
  • testerzy nalegają na przeprowadzenie dodatkowych testów;
  • klient żąda wzięcia do sprintu nieplanowanych zadań.

Czasami zdarzają się konflikty: w wymaganiach między interesariuszami po stronie klienta lub między członkami zespołu. Analityk biznesowy musi umieć znajdować kompromisy i rozwiązywać konflikty – to część jego pracy.

Głównym punktem napięcia jest to, że koszt błędu analityka biznesowego jest bardzo wysoki. Błąd popełniony na etapie wymagań, nie ujawniony i nie rozwiązany przed powstaniem produktu, będzie kosztował dużo. Naprawa takiego błędu pochłonie wiele czasu, pieniędzy i wysiłku.

test I AM BA

Mit 2: Wszyscy rozumieją, czym zajmuje się analityk biznesowy

W naszej branży też są swoje trendy: małe firmy patrzą na gigantów IT i próbują zrozumieć, z czego wynika sukces i wzrost. Czasem pojawia się hipoteza, że biznes odnosi sukces, a projekty są duże, bo firma ma takiego specjalistę jak BA. Wychodzi taki kult cargo, kiedy otwierają miejsce na stanowisko analityka biznesowego, nie rozumiejąc jego sfery odpowiedzialności i zadań.

Jak wyraża się brak rozumienia:

  • Od analityka biznesowego mogą wymagać wykonywania niecharakternych dla stanowiska obowiązków, np. zajmowania się raportami niezwiązanymi z analizą biznesową lub przydzielania zadań w zespole, pełniąc jednocześnie rolę PM i BA. W efekcie kierownictwo firmy i sam specjalista nie wiedzą, czy analityk biznesowy wnosi wartość, czy nie.
  • W dużej firmie istnieje ryzyko, że obowiązki analityka biznesowego nie są rozumiane przez samych członków zespołu. Na przykład w mojej firmie tylko jedna trzecia projektów ma analityka biznesowego, więc naturalne jest, że nie wszyscy wiedzą, co taka osoba powinna robić.
  • Klient może również nie zdawać sobie sprawy z wartości analityka biznesowego. Zdarza się, że firma sprzedająca narzuciła analityka, ponieważ z nim będzie lepiej, ale klient nigdy nie zrozumiał dlaczego.

Kiedy BA przychodzi do nowej pracy, często przyjmuje założenie, że wszyscy wiedzą, za co będzie odpowiedzialny i co będzie robił, i po prostu zaczyna pracować. Ale nie każdy zawsze wie o tym, więc trzeba wyjaśnić swoją rolę na starcie projektu.

Jak pracować z oczekiwaniami

Zadawajcie pytania. Pytaj jak najwięcej na etapie ubiegania się o pracę lub podczas rozmowy kwalifikacyjnej, aby zrozumieć oczekiwania wobec stanowiska analityka biznesowego w firmie. Dlaczego analityk biznesowy jest potrzebny? Czego od niego oczekują? Jak będziecie oceniać sukces BA w projekcie?Z odpowiedzi można wywnioskować, czy firma wie, kogo szuka, czy rzeczywiście potrzebuje analityka biznesowego, czy kogoś innego. Na przykład analityka danych, analityka procesów czy analityka finansowego.

Dowiedz się, jakie oczekiwania ma kierownik projektu. Jeśli już pracujesz w firmie i idziesz na jakiś projekt, to tam też są konkretne oczekiwania, zależne od produktu, klienta, zespołu, metodyki. Najlepszym sposobem na ich sprecyzowanie jest rozmowa z PM. Poproś go o 20 minut swojego czasu i sformułowanie oczekiwań co do roli BA. Najlepiej w formie pisemnego podsumowania: na papierze lub tablicy, gdziekolwiek.Zapis nie ma być przechowywany jako kartka papieru, którą można wymachiwać w kontrowersyjnych sytuacjach. Kiedy człowiek formułuje się ustnie, istnieje ryzyko zanurzenia się w długie przemyślenia o tym, że analiza biznesowa jest ważna, nasza branża idzie do przodu, im więcej projektów, tym więcej sukcesów. Na koniec nie wiadomo, o czym było gadane. Jeśli człowiek zapisuję swoje myśli, jego mózg koncentruje się na sformułowaniach, a to prowadzi do konkretów.

Popracujcie nad oczekiwaniami. Kiedy już zrozumiesz czego się od Ciebie oczekuje i porównasz to z własnym rozumieniem, stwórz odpowiednie oczekiwania dla zespołu i klienta. Normalnie powinien to zrobić PM, ale czasem może zapomnieć lub nie mieć czasu, sytuacje są różne. Dlatego nie krępuj się i przedstaw się. Możesz poprosić o 15 minut na spotkaniu zespołu i powiedzieć: „Cześć wszystkim, chciałbym powiedzieć kilka słów o mojej roli i o tym, co będę tu robił”.

Na wystąpieniu warto przedstawić podstawowe zasady: z jakimi pytaniami, kiedy i jak można się do ciebie zwrócić. Koniecznie wspomnij o value proposition – wartości Twojej roli dla zespołu. Na przykład: „Zadbam o to, aby wasz backlog był priorytetowy, nie było konfliktów w wymaganiach i zawsze wiedzieliśmy, co wziąć w następnym sprincie. Będę szybko rozwiązywał konflikty w wymaganiach”.

Mit 3: Klient wie, czego chce

Klient wie, czego chce

Klient może sformułować decyzję na kształt: „Potrzebuję Ubera, tylko nie do końca, który działa jak Facebook, ale do biznesu agrarnego”.

Jest mało prawdopodobne, że klient rzeczywiście chce dokładnie tego, co powiedział. Bardziej prawdopodobne jest, że jest to tylko język, którego próbuje użyć, aby wyjaśnić swój problem i porozmawiać o rozwiązaniu.

Jeśli klient nie jest zbyt obeznany w IT, poprawne sformułowanie prośby może być trudne, więc klient próbuje przekształcić swoje myśli w jakąś formę znanych mu aplikacji. Może podoba mu się design Ubera, a w Facebooku dźwięk przychodzącej wiadomości.

Nigdy nie traktuj słów klienta, zwłaszcza na pierwszych spotkaniach, jako wskazówek do działania: „OK, weźmiemy to i zrobimy”. Przy takim podejściu łatwo przeoczyć prawdziwy problem lub potrzebę, którą klient chce zrealizować poprzez projekt.

Jeśli analityk biznesowy nie „zgadnie”, nie trafi w prawdziwą potrzebę, klient pozostanie niezadowolony. Jeśli aplikacja, system lub rozwiązanie nie spełni potrzeby biznesowej, klient powie, że to twoja wina, nawet jeśli zespół zrobił wszystko ściśle według wymagań.

Czasami sam klient nie wie zbyt dobrze, jak działa jego własny biznes, jakie są niuanse. Widać to w dużych firmach, kiedy organizujesz warsztaty z modelowania procesów i gromadzisz ludzi z różnych działów. Nie wyobrażasz sobie, ile zdziwionych twarzy można zobaczyć na takim spotkaniu, jak często ludzie mówią: „A tak na poważnie, to mamy taką zasadę, czy my to robimy?”. Bo mają wizję biznesu ze strony swojego działu i mgliste pojęcie o tym, co się dzieje dalej. To też jest niuans, który warto wziąć pod uwagę.

Mit 4: Klient rozumie, jak działa programowanie

Często klienci z różnych domen przychodzą do nas, specjalistów IT, ponieważ ich biznes potrzebuje cyfrowej transformacji. Tacy klienci są dalecy od zrozumienia, jak odbywa się proces programowania lub jak wygląda struktura SDLC.

Kiedyś robiliśmy system obiegu dokumentów dla kancelarii prawnej. Kilka razy przegadaliśmy ideę, że celem systemu jest pokrycie potrzeb biznesowych klienta. A potem, na jakimś spotkaniu, klient mówi:

— Produkt jest dobry i chciałbym w przyszłości sprzedawać go innym kancelariom prawnym.

Byliśmy zaskoczeni i wyjaśniliśmy:

— Jak zamierzasz to sprzedawać, przecież to system stworzony konkretnie dla twojej firmy?

I okazuje się, że klient nie rozumie różnicy, że produkt zrobiony dla konkretnej firmy, a platforma, którą można dostosować do potrzeb firm zewnętrznych, uruchamiających inne organizacje – to są zupełnie inne architektury.

Klient rozumował tak: „System działa dla mnie, więc mogę go skopiować na komputer innej organizacji. A oni zapłacą mi za to pieniądze”.

Zadaniem analityka biznesowego jest pomoc klientowi w zrozumieniu procesów IT, terminów i ich znaczenia. Przecież również chcemy, aby klienci opowiedzieli nam o swoim biznesie, co oznacza ten czy inny termin, jak działa dany proces, bo to jest ważne przy implementacji.Podobnie dla prawidłowej komunikacji z klientem ważne jest, aby upewnić się, że jeśli analityk biznesowy mówi na przykład, że na koniec sprintu zrobimy wdrożenie systemu, to klient rozumie, czym jest sprint, kiedy się skończy, co oznacza wdrożenie systemu, jak to się odbędzie i kiedy zobaczy tę zmianę u siebie.

Mit 5: Wymagania są czytane uważnie

Wymagania są czytane uważnie

Niestety, zespół nie traktuje wymagań tak starannie, jak chciałby tego analityk biznesowy. Klientowi też wysyłasz coś do przejrzenia. On to czyta, potem zadaje pytania i okazuje się, że nic nie widział. Tutaj jednak chciałbym porozmawiać o zespole.

Teraz dla pracy z wymaganiami wykorzystamy kryterium definition of ready. Wiele osób zna definition of done – wskaźniki, które pokazują, że zadanie zostało wykonane. Definition of ready pokazuje, że wymagania są gotowe do programowania:

  • Requirements finalized — wymagania są napisane, na wszystkie pytania są odpowiedzi. Jeśli aplikacja wymaga designu, to design również jest na tym etapie zakończony.
  • Zespół, wraz z analitykiem biznesowym, omówił i przydzielił backend i frontend: jaka praca jest potrzebna i kto co zrobi.
  • Jest napisane, czy refaktoryzacja jest potrzebna, czy nie, ponieważ często zapomina się o tym, a następnie okazuje się, że refaktoryzacja jest potrzebna. To zwiększa szacowanie i komplikuje User Story.
  • Ustaliliśmy, jak powinny działać prawa dostępu użytkowników.
  • Zobaczyliśmy jak wymaganie wpłynie na dane historyczne, jest to istotne w przypadku aplikacji z pewną historią pracy, kiedy obiekty informacyjne, encje, połączenia między nimi zostały już stworzone. Jeśli coś zmieniamy, musimy zastanowić się jak to wpłynie na dane historyczne. Czy powinny się one również zmienić, czy powinny pozostać nietknięte?
  • Developerzy ocenili dostępność zmian w infrastrukturze.

Po wykonaniu pracy, zespół powinien podać szacowanie. Jeśli ludzie dają normalne oszacowanie, jest to główny wskaźnik, że specjaliści mają jasne zrozumienie tego, co należy zrobić.

I AM BA

Mit 6: Pisanie User Story jest łatwe

Wydawałoby się, że nie ma nic trudnego do zrobienia: napisać „Ja jako użytkownik chcę czegoś tam, aby uzyskać z tego wartość i jakiś zestaw kryteriów”.

Moje pierwsze User Story brzmiało: „Jako użytkownik chcę widzieć dane pacjentów z jednego systemu w innym systemie, dzięki czemu mogę używać tych danych w dwóch systemach”.

Autentycznie nie rozumiałem, czego jeszcze ode mnie chcą: praca została wykonana, User Story napisane, poszedłem na kawę. Okazuje się, że to nie jest takie proste. Oczywiście teraz piszę wymagania trochę lepiej, ale nadal nie potrafię stworzyć idealnego User Story, zrozumiałego dla absolutnie wszystkich i nie budzącego pytań.

I tu chyba tylko praktyka pomoże: im więcej będziesz pisał, im lepiej będziesz rozumiał pytania zespołu, tym bardziej Twoje historie będą wypełnione. I znajdziesz równowagę kryteriów, które muszą koniecznie towarzyszyć User Story, aby można było uznać je za dobre lub możliwe do wdrożenia.

Podzielę się podejściem, które stosuję podczas pracy z User Story:

  1. Najważniejsze jest zrozumienie potrzeby biznesowej, co ta funkcjonalność powinna obejmować dla biznesu, poprzez jakie funkcje aplikacji i jakie działania użytkownika z tą aplikacją.
  2. Piszę podstawowe Kryteria Akceptacji, w bardzo podstawowy sposób, nie myśląc zbytnio o żadnych niuansach, nie poświęcając czasu na szczegółowe przemyślenia.
  3. Idę do zespołu, przedstawiam User Story w formie roboczej, dostaję zestaw pytań, sugestii, uzupełnień. Ważnym elementem pracy nad historią jest również rozmowa.
  4. Po rozmowie z zespołem mogę już dodawać szczegóły. Nie poświęcam czasu na starcie, żeby napisać coś bliskiego ideału i dopiero potem iść do zespołu. Piszę podstawowe rzeczy, idę prosto do kolegów i słucham wielu sugestii, pytań i krytyki. Po rozmowie mam podstawowe kryteria, które są jasne dla developerów, bo po części te kryteria pochodzą od nich samych.

Następnym krokiem jest wyjaśnienie wszelkich niejasnych punktów z klientem lub zrobienie przeglądu, ale główną radą jest, aby nie spędzać zbyt wiele czasu próbując napisać idealne User Story od początku.

Zamiast wniosków

Często słyszę, że analityk biznesowy musi być ekspertem w domenie. Ale myślę, że główną domeną, w której BA powinien być ekspertem, jest analiza biznesowa. Jeśli jesteś biegły w tym, specyfika domeny nie będzie dużym wyzwaniem.

Zadaniem firmy jest wyjaśnienie celów, zapłacenie pieniędzy i uzyskanie wyniku. Najlepszym ekspertem w swojej domenie jest sam klient, a firma oczekuje od analityka biznesowego maksymalnego zaangażowania i odpowiedzialności za wynik.

Kyryło Bieliawskyi

Główny analityk biznesowy w firmie SoftServe. Ponad 8 lat doświadczenia w analizie biznesowej. Regularny wykładowca na kursach, meetupach i konferencjach, prowadzi podcast o życiu i analizie biznesowej.