Kiedy wpadasz w wir swoich zadań, czasem nie zastanawiasz się, co robi na co dzień twój kolega przy biurku po prawej. Aby zaradzić tej sytuacji, zajmiemy się zawodami w IT. Z programistami i testerami sprawa jest jasna, to oni tworzą produkt. PM jest postacią kontrowersyjną, ale w prawie każdym zespole jest taki, więc już ustaliliśmy jakie pytania mu zadać.

Jednak z jakiegoś powodu nikt nie rozumie, dlaczego potrzebujemy osoby z modnym zawodem – Business Analyst (BA). Z zewnątrz może się wydawać, że całymi dniami pisze dokumentację i czasem poświęca dużo czasu na omówienie niektórych decyzji z zespołem. Co robi analityk biznesowy, jeśli już jest PM i technical writer?

Kim jest analityk biznesowy — kolejną warstwą zarządu czy najlepszym przyjacielem programisty? Dowiesz się w tym artykule.

Kim jest analityk biznesowy

Analityk biznesowy to osoba, która stoi pomiędzy biznesem a zespołem programistów. To on zbiera i identyfikuje wymagania dotyczące przyszłych cech produktu lub systemu, a następnie przekłada je na język zrozumiały dla inżynierów.

Zakres obowiązków BA w zespole może być różny, ale wszystkie projekty i wszystkie stanowiska analityka biznesowego określają 4 główne funkcje:

1. Zarządzanie wymaganiami: ich identyfikacja, przygotowanie i uszczegółowienie, rozdzielenie żądań na wymagania i „niektóre nie tak ważne zachcianki”.

2. Analiza strategiczna: w wielu firmach BA pracuje razem z top-managementem nad strategią rozwoju firmy i projektu, ponieważ najlepiej zna produkt.

3. Projektowanie rozwiązań: przygotowanie dokumentacji i, czasami, tworzenie prototypów. Wszystko po to, by wymyślić i przekazać zespołowi, jak rozwiązania zostaną zaprojektowane i wdrożone.

4. Zarządzanie produktem: komunikacja z projektantami, inżynierami, interesariuszami, biznesem i Product Ownerami.

Dlaczego analityk biznesowy jest potrzebny

Wyobraźmy sobie sytuację, w której klient wysyła developerowi link do strony konkurencji i mówi: „Potrzebuję strony internetowej! Dokładnie takiej jak ta!” Programista: „Nie rozumiem, co znaczy „kropka w kropkę”, wyślij mi TOR (terms of reference), mniej będę musiał przerobić”.
Klient po tym zwraca się do swojego przyjaciela, który jest analitykiem biznesowym, aby poskarżyć się na developera. Mamy taki dialog między klientem a analitykiem biznesowym.

Klient: No powiedz mi, CO TU JEST NIBY NIEZROZUMIAŁE? Chcę zrobić dokładnie taką samą stronę, czy naprawdę tak trudno ją skopiować?

Analityk biznesowy (smutnym głosem): Cóż, właściwie to jestem po stronie programisty. Wszystko w twoim zgłoszeniu jest niejasne. Wyjaśnię to. Przyjrzyjmy się razem, co dokładnie podoba ci się na tej stronie. Jest przycisk „porównaj”, czy jest potrzebny?

Klient: Nie, nie potrzebuję go.

Analityk Biznesowy: Oni mają osobną stronę w swojej witrynie dla wysyłki i inną dla płatności, czy naprawdę potrzebujesz obu, czy wysyłka i płatność mogą być połączone w jedną stronę?

Klient: Można połączyć, tak naprawdę nie mam dwóch stron do wypełnienia.

Analityk Biznesowy: Widzisz, to nie jest dokładnie to samo, prawda?

Klient: Chodziło mi chyba bardziej o oprawę wizualną.

Analityk Biznesowy: A programista mówił o funkcjonalności.

Ten przypadek pokazuje jak różnie może być postrzegany ten sam produkt (w tym przypadku strona internetowa). Okazuje się, że BA jest osobą, która może uratować projekt przed „zrobione, ale nie to co trzeba”. Dlatego lepiej zaangażować Analityka Biznesowego, zanim zespół napotka problemy komunikacyjne z klientem.

Kiedy klient przedstawia wygórowane nawet jak dla swoich potrzeb wymagania – wtedy BA jest niezbędny (jak w powyższym przykładzie).  Odwrotna sytuacja może mieć miejsce, gdy zespół robi wspaniałe rzeczy, ale klient nie może docenić tego, co zostało opracowane, ponieważ ten sam zespół robiący świetną robotę, używa zbyt technicznych terminów, których klient nie rozumie.

Wydaje się, że gdyby klient miał zaplecze techniczne, to rozwiązałoby to wszystkie problemy. Cóż, nie do końca. Klienci obeznani z techniką, zamiast skupić się na przygotowaniu wymagań, mogą zacząć mówić zespołowi, co i jak ma robić, nie mając wystarczającej wiedzy w tym zakresie. Albo co gorsza, zacząć pisać kod i opowiadać się za jego wdrożeniem w projekcie. W tej sytuacji BA pełni rolę psychologa – przypomina klientowi, że pracuje dla niego zespół profesjonalistów, a jego działania po prostu spowalniają proces rozwoju. Analityk musi też pamiętać, żeby poprosić zespół o większą wyrozumiałość wobec klienta. 

Jest jeszcze trzeci rodzaj problemów komunikacyjnych – gdy sposób, w jaki klient widzi produkt, bardzo różni się od sposobu, w jaki zespół myśli o najlepszym rozwiązaniu potrzeby biznesowej. Analityk biznesowy w takich sytuacjach pełni rolę swoistego arbitra i łączy najlepsze propozycje z dwóch stron, argumentując zmiany dla obu stron.

Czekaj, ale to raczej zadanie dla Project Manager-а, prawda?

W pewnym sensie tak właśnie jest. Nie wszystkie firmy mają dedykowane osoby do obu ról, a wymaganiami trzeba się zająć tak czy siak. Jednak w średnich i dużych projektach zarówno analityk biznesowy, jak i PM mają pełne ręce roboty (z nadgodzinami również).

Jeden dzień analityka biznesowego w IT

Opiszmy standardowy dzień, w którym analitykowi biznesowemu udaje się wykonać wszystkie swoje podstawowe zadania. Oczywiście nie wszystkie dni tygodnia przebiegają w ten sposób dla BA. W zależności od bieżących zadań i etapu rozwoju projektu, ilość czasu poświęcanego danemu zadaniu zmienia się. BA na bieżąco dostosowuje swój terminarz, ale w idealnym świecie bez goniących terminów, harmonogram BA może wyglądać następująco.

10:00 – 12:00 Wsparcie zespołu

W niektórych przypadkach komunikacja z zespołem może zająć prawie cały dzień. W idealnym harmonogramie BA w ciągu tych dwóch godzin będzie odpowiadał na pytania, gdy coś nie jest jasne i uczestniczył w omawianiu sytuacji problemowych.

Zdarzają się przypadki, że podejmuje się pozornie łatwego zadania, ale w trakcie realizacji okazuje się, że istnieją ograniczenia techniczne i zatwierdzone wcześniej rozwiązanie zajmie dużo więcej czasu.

BA organizuje wtedy spotkanie, na którym wyjaśnia zespołowi pierwotną potrzebę biznesową i pyta, czy zespół może wymyślić rozwiązanie, które zajmie mniej czasu i zasobów. Jeśli zostanie znalezione optymalne rozwiązanie, analityk biznesowy zmienia wymagania. Jeśli nie — czas „uszczęśliwić” klienta wiadomością o opóźnieniu.

BA powinien zawsze jasno określać, jak ważne jest dane wymaganie dla klienta i czy zmiany wymagają dalszego omówienia z klientem. Najlepiej na początku pytać o wszystko. Wiedza, w jakiej sytuacji można podjąć samodzielną decyzję, przychodzi z doświadczeniem.

Co jest ważne podczas pracy z zespołami:

• Bądź w kontakcie niemal 24/7.
• Skup się na rozwiązaniu problemu: dowiedz się, na czym polega problem, poprowadź rozmowę w pozytywnym i konstruktywnym kierunku i zaproponuj alternatywne rozwiązanie.
• Rozwiązuj problemy wykorzystując do tego odpowiednią ilość czasu i ludzi. Nie próbuj wszystkiego robić sam. 
• Bądź świadomy wyzwań, które czekają zespół, kiedy dochodzi do zmian w projekcie. Pamiętaj, żeby w odpowiednim czasie informować wszystkich zaangażowanych o problemach.
• Ważne jest, aby nie zawiesić się na komunikowaniu z zespołem i nauczyć się wiedzieć, kiedy wszystkie bieżące sprawy zostały rozwiązane i można skupić się na innym zadaniu.

12:00 — 14:00 Pisanie dokumentacji

Jeśli dokumentacja jest zbyt duża, nikt jej nie czyta. Co robi analityk biznesowy na tym etapie:

• Tworzy specyfikacje.
• Opisuje user stories / acceptance criteria / use cases.
• Formułuje wymagania niefunkcjonalne – opisuje warunki, w których system jest efektywny. Na przykład: „System musi być odporny na błędy i kompatybilny z Google Chrome (…)”.
• Modeluje procesy biznesowe.
• Tworzy prototypy rozwiązań.
• Opracowuje zasady użyteczności.
• Co jest ważne przy pisaniu specyfikacji:
  • Zdefiniuj z wyprzedzeniem wymagane artefakty już w początkowej strategii.
  • Opisz wymagania WYSTARCZAJĄCO szczegółowo: nie za dużo, nie za mało.
  • Określ jasno i klarownie nieakceptowalne wady na produkciePrzestrzegaj zapisów zawartych w diagramach.

14:00 — 15:00 Obiad

Przerwa to idealna okazja do nieformalnego poznania ludzi i nawiązania kontaktów towarzyskich z zespołem, dlatego zaleca się, aby nie jeść obiadu w samotności.

15:00 — 18:00 Komunikacja z Klientem

Spotkania robocze to spotkania, na których można poznać wymagania, ale także dotrzeć do sedna prawdziwej potrzeby klienta. Innymi słowy, odpowiedzieć na pytanie „dlaczego tego potrzebujemy?” i zastanowić się, czy dane rozwiązanie jest rzeczywiście najlepsze, czy też istnieją inne możliwości. Aby rozmawiać z klientem tym samym językiem, trzeba zrozumieć obszar tematyczny danej działalności.

Podczas takich wywiadów zbiera się, identyfikuje i precyzuje wymagania, pokazuje dokumenty, prototypy, modele, diagramy, demo produktu lub nawet gotowe rozwiązanie.

Ważne! Zatwierdzaj wyniki z klientem i pamiętaj o zachowaniu „zatwierdzeń”. Nawet zrzut ekranu wiadomości w prywatnej korespondencji liczy się jako „zatwierdzenie”. Dostęp do Slacka klienta może być w każdej chwili odcięty, dlatego ważne jest, aby „zatwierdzenia” trzymać przy sobie, blisko wymagań.

18:00 — 19:00 Konsultacje z tech leadami

Kiedy BA sporządza wymagania, musi zrozumieć wszystkie związane z nimi szczegóły techniczne. Nawet jeśli wie, jak pisać kod, projekt ma inne zadania, więc konieczne jest skonsultowanie się z tymi, którzy są zaangażowani w rozwój: architektami, zespołem / tech leadami i ekspertami tematycznymi. Takie konsultacje służą do omówienia wymagań wysokopoziomowych: jak najlepiej zaprojektować, zaimplementować, zdekomponować i tak dalej. Jeśli w zespole nie ma architektów, trzeba iść do programistów i konsultować się z nimi. Bezpośrednim obowiązkiem BA jest zrozumienie obszaru tematycznego ze wszystkich punktów widzenia: nie tylko od strony biznesowej, ale również technicznej.

Kto może zostać dobrym BA

Na to stanowisko można przejść zarówno z ścieżki biznesowej, jak i programistycznej. Na BA świetnie nadają się technical writerzy, ponieważ dokładnie rozumieją, jak powstaje dobra dokumentacja. Od strony biznesowej dobrymi kandydatami są menedżerowie, ekonomiści, a nawet członkowie zespołu wsparcia, ponieważ rozumieją bolączki i potrzeby klientów.

Rolę BA w firmie mogą pełnić różni specjaliści: 

Jak zostać BA

Jeśli po przeczytaniu tego artykułu czujesz, że analiza biznesowa może być kolejnym krokiem w twojej karierze – to dobrze trafiłeś. Nawet jeśli po szkoleniu zmienisz zdanie na temat zmiany pracy, to znajomość analizy biznesowej znacznie zwiększy twoją atrakcyjność na rynku.

Aby rozwijać się w kierunku analityka biznesowego musisz:

1. Zrozumieć rolę analityka biznesowego w swojej firmie, ponieważ zadania mogą się znacznie różnić w zależności od projektu.
2. Zidentyfikować swoje obecne kompetencje i porównać z matrycą kompetencji BA. Czasami jedna kompetencja (np. dobry angielski) może być kluczowa.
3. Zidentyfikuj brakujące kompetencje i przeszkól się w nich.
4. Poznać podstawowe techniki i metody BA. Wprowadź te techniki do pracy i monitoruj wyniki.
5. Aplikować na stanowisko juniora z listem motywacyjnym. Ważne jest, aby napisać dlaczego chcesz pracować w tej firmie i dlaczego powinni cię zatrudnić: co dotychczas zrobiłeś, jakie kursy przeszedłeś i co potrafisz. Nie bój się przesyłać projektów testowych wraz z CV – będą one świetnym przykładem twojej pierwszej pracy.

Dla jednych codzienna praca analityka biznesowego będzie nudna, dla innych będzie to praca marzeń (jest spokojniejsza niż ta na stanowisku kierownika projektu, ale wciąż z dużą ilością komunikacji i wpływem na rezultat). W każdym razie wiedza z zakresu analizy biznesowej z każdym dniem staje się coraz bardziej pożądana na rynku, więc jeśli chcesz rozwijać się w IT, warto podciągnąć się w pracy z wymaganiami.