Roadmapa kariery BA

Start całej ścieżki. Zanim wpiszesz „Business Analyst” do CV, musisz umieć odpowiedzieć na pytanie, które pada na każdej rozmowie z przebranżowcem: czym BA różni się od Project Managera, Product Ownera i analityka systemowego? Tu dostajesz mapę zawodu: co analityk robi od poniedziałku do piątku, jak wygląda cykl analizy od problemu biznesowego do działającego rozwiązania, jakie są typy projektów (wdrożenie, migracja, rozwój produktu) i gdzie w każdym z nich siedzi BA. Do etapu podpięty jest kurs wprowadzający, test wiedzy i pierwszy certyfikat - od razu masz dowód, nie tylko „przeczytałem o tym”. Jeśli przychodzisz z innej branży, to jest dokładnie ten moment, żeby sprawdzić, czy ta praca w ogóle Ci leży. Lepiej dowiedzieć się teraz niż po roku kursów.

Najlepsza analiza świata przegrywa z kiepsko poprowadzonym spotkaniem. Serio. Możesz mieć rację w każdym punkcie, ale jeśli sponsor wyszedł z warsztatu zirytowany, Twoje wymagania trafią do szuflady. Dlatego komunikacja stoi na początku tej roadmapy, a nie w sekcji „miłe dodatki”. Uczysz się tu rzeczy, z których BA korzysta codziennie: aktywnego słuchania (parafraza zamiast zgadywania), zadawania pytań otwartych, pisania maili, na które ludzie faktycznie odpowiadają, i prezentowania wniosków decydentom w 10 minut zamiast 40 slajdów. Na koniec etapu czeka quiz z kompetencji miękkich i certyfikat z etykiety biznesowej z publicznym rejestrem weryfikacji. Na rozmowach rekrutacyjnych na juniora pytania o komunikację padają częściej niż pytania o narzędzia - i to na nich kandydaci wykładają się najboleśniej.

Najszybsza droga do pierwszej roli BA nie wiedzie przez kolejny certyfikat, tylko przez pokazanie, że umiesz rozebrać proces na części. Wejdź na /praca i zobacz, ile ogłoszeń na juniora w ogóle istnieje (mniej niż na mida, taka jest prawda rynku PL). Tu rozpracujesz dwie realne ścieżki: przebranżowienie z IT lub biznesu, gdzie domenę już masz i sprzedajesz ją jako atut, oraz wejście od zera, gdzie portfolio musi zastąpić doświadczenie. Nikt nie zatrudni cię za listę kursów. Zatrudni za to, że pokażesz diagram procesu rejestracji wizyt w MediFlow i wymagania, które sam spisałeś. Nauczysz się układać CV pod konkretne ogłoszenie (nie jeden uniwersalny plik na wszystko) i rozmawiać o etacie kontra B2B bez naiwności co do podatków i braku płatnego urlopu na fakturze. Na rozmowie rekruter sprawdzi, czy potrafisz dopytać o niejasne wymaganie, a nie wyrecytować definicję BABOK. Żadnych obietnic, że po tym węźle dostaniesz pracę - rynek juniorski jest ciasny i bywa, że odpowiedź przychodzi po pięćdziesiątej aplikacji. Dostaniesz za to mapę, gdzie naprawdę przykładać siły, zamiast rozsyłać CV na oślep.

Cert na CV nie zastąpi tego, że nie umiesz napisać user story, ale na rynku, gdzie na jedno juniorskie ogłoszenie BA leci sto aplikacji, trzyliterowy skrót po nazwisku potrafi przepchnąć Cię przez sito rekrutera. IIBA ma trzy główne stopnie: ECBA na wejście (zero wymaganego doświadczenia, egzamin z teorii BABOK), CCBA dla osób z paroma tysiącami godzin praktyki i CBAP dla seniorów z 7500+ godzin. Pod spodem leży BABOK v3 i model BACCM (sześć pojęć: potrzeba, zmiana, rozwiązanie, interesariusz, wartość, kontekst) - to słownik, którym IIBA mówi o zawodzie. Moje zdanie: ECBA ma sens, gdy wchodzisz do branży bez tytułu z analizy i chcesz pokazać, że ogarniasz terminologię, bo wtedy porządkuje wiedzę i daje strukturę. CBAP bierz, gdy realnie celujesz w role lead/konsultanta i pracodawca to docenia (część przetargów IT wprost go wymaga), a CCBA traktuj jako etap pośredni, który łatwo przeskoczyć. Czego cert nie zrobi: nie nauczy Cię prowadzić warsztatu z pyskatym interesariuszem ani rozrysować procesu rejestracji wizyt w MediFlow tak, żeby dział obsługi go zrozumiał. Na platformie sprawdzisz się mockami ECBA, CCBA, CBAP, CBDA i PMI-PBA, zanim zapłacisz kilkaset dolarów za prawdziwy egzamin.

BPMN stoi w wymaganiach większości ogłoszeń dla BA w Polsce - sprawdź sam na /praca. Tu uczysz się czytać i rysować procesy tak, żeby księgowa i programista zrozumieli ten sam diagram. Zaczynasz od zdarzeń, zadań i bramek, potem baseny i przepływy komunikatów, a na końcu modelujesz pełny proces rejestracji wizyty w MediFlow: od telefonu pacjenta, przez weryfikację terminu, po SMS z przypomnieniem. Najczęstszy błąd początkujących? Diagram-tasiemiec na 60 elementów, którego po tygodniu nie rozumie nawet autor. Nauczysz się ciąć procesy na czytelne poziomy, zanim ktoś utonie w szczegółach. Etap kończy egzamin i certyfikat z podstaw BPMN do publicznego rejestru - jeden z tych dowodów, o które rekruterzy pytają wprost na rozmowach.

Nikt Ci nie powie wprost, czego potrzebuje. Klient mówi „chcemy nowy system”, a ma na myśli „obecny proces boli w trzech miejscach i nie wiem, w których”. Wydobywanie to wyciąganie tych trzech miejsc na światło dzienne. Uczysz się tu prowadzić wywiady (z pytaniami przygotowanymi wcześniej, nie z głowy), facylitować warsztaty, na których osiem osób z trzech działów dochodzi do wspólnych wniosków, układać ankiety, które ludzie kończą, i czytać istniejącą dokumentację oraz dane systemowe, zanim zaczniesz męczyć ludzi pytaniami. Na case MediFlow przećwiczysz wywiad z rejestratorką, która „nie ma czasu na te rozmowy” - bo takich rozmówców spotkasz najczęściej. To etap, na którym kompetencje komunikacyjne z fundamentu zaczynają zarabiać na siebie. Bez dobrej wydobywania cała dalsza analiza to budowanie na piasku.

Zebranie wymagań to połowa roboty. Druga połowa: zapisać je tak, żeby programista, tester i sponsor przeczytali to samo. Poznajesz tu formy dokumentacji, które realnie krążą w polskich projektach: specyfikację wymagań (SRS), przypadki użycia, historyjki użytkownika i macierz śledzenia, dzięki której widzisz, które wymaganie nie ma ani testu, ani właściciela. Przećwiczysz to na case MediFlow - spisujesz wymagania dla rejestracji wizyt online w sieci 12 przychodni, od celu biznesowego po kryteria odbioru. Dobra dokumentacja to nie ta najdłuższa. Widziałem 80-stronicowe SRS-y, których nikt nie otworzył po podpisaniu, i 6-stronicowe, z których zespół korzystał codziennie. Nauczysz się pisać te drugie. Gotowe szablony dokumentów masz na platformie w /szablony, test z wymagań czeka na końcu etapu.

W wielu polskich firmach pierwszym etatem przyszłego BA jest właśnie testowanie - i to nie przypadek, bo tester czyta wymagania uważniej niż ktokolwiek inny. Musi, skoro ma je sprawdzić. Na tym etapie poznajesz testowanie od strony analityka: rodzaje testów i kto je wykonuje, pisanie scenariuszy testowych z własnych wymagań, raportowanie błędów tak, żeby programista odtworzył problem za pierwszym razem, oraz UAT, czyli testy akceptacyjne z biznesem, które w praktyce często organizuje właśnie BA. Przećwiczysz to na MediFlow: scenariusze dla umawiania wizyty, łącznie z przypadkami brzegowymi (lekarz na urlopie, dwa terminy naraz, pacjent bez numeru PESEL). Prosta zasada: jeśli Twoje wymagania da się przetestować, są dobrze napisane. Jeśli nie da się - wiesz, co poprawić, zanim powie Ci to cały zespół.

SQL to umiejętność, która najszybciej przesuwa CV juniora na górę stosu - wejdź na /praca i policz, w ilu ogłoszeniach stoi w wymaganiach. Logika rynku jest prosta: analityk, który sam sprawdzi dane w bazie, nie czeka dwóch dni na odpowiedź zespołu BI. Uczysz się tu SELECT-ów z filtrowaniem, łączenia tabel JOIN-ami (i tego, czym LEFT różni się od INNER, bo to pytanie pada na co drugiej rozmowie rekrutacyjnej), grupowania i agregacji. Wszystko ćwiczysz w sandboksie SQL na platformie, prosto w przeglądarce, na bazie sklepu internetowego z celowo podstawionymi pułapkami w danych. Bez instalowania czegokolwiek. Do tego ćwiczenia z automatycznym sprawdzaniem wyniku i test SQL dla analityka na zamknięcie etapu. Pierwsze własnoręcznie napisane zapytanie na produkcyjnych danych pamięta się długo.

„Jako użytkownik chcę się zalogować, żeby się zalogować.” Takie historyjki naprawdę trafiają do backlogów, a potem zespół zgaduje, co budować. Na tym etapie uczysz się pisać user stories, które niosą wartość: z konkretnym aktorem (rejestratorka w MediFlow, nie „użytkownik”), z celem biznesowym i z kryteriami akceptacji w formacie Given-When-Then, które tester odpala bez dopytywania. Poznasz INVEST jako narzędzie do cięcia zbyt dużych historyjek - z mojego doświadczenia to umiejętność, której w zespołach scrumowych brakuje najbardziej. W polskich ogłoszeniach na Junior BA „user stories i kryteria akceptacji” to standardowy wymóg, zaraz obok Jiry. Test z user stories masz na platformie, a w drzewku rozwoju czeka zadanie praktyczne, które oceni społeczność w peer review.

Godzina rysowania ekranów oszczędza tydzień programowania. Wireframe to najtańszy sposób, żeby sprawdzić, czy Ty i klient widzicie to samo rozwiązanie, zanim ktokolwiek napisze linijkę kodu. Uczysz się tu szkicować ekrany (papier i Figma), budować klikalne prototypy i zbierać na nich feedback tak, żeby ludzie mówili o zadaniach („umów mnie do okulisty na przyszły wtorek”), a nie o kolorach przycisków. Przećwiczysz to na ekranie umawiania wizyty w MediFlow: kalendarz, wybór lekarza, potwierdzenie. Jedna granica jest ważna: BA nie projektuje finalnego interfejsu, od tego są projektanci. BA szkicuje, żeby zweryfikować wymagania. Ale w mniejszych firmach, gdzie dedykowanego UX-a nie ma, ta umiejętność bywa tym, co wyciąga Twoje CV ze stosu. Test z UX dla BA zamyka etap.

Otwierasz dowolne ogłoszenie na /praca dla juniora BA i w wymaganiach prawie zawsze stoi Jira albo cały „pakiet Atlassiana" - bo tam toczy się codzienna praca zespołu, nie w mailach. Jira to miejsce, gdzie Twoje wymagania zamieniają się w historyjki, dostają priorytet i przechodzą przez workflow od „To Do" do „Done"; Confluence to miejsce, gdzie te wymagania mają opis dłuższy niż jedno pole tekstowe. Nauczysz się tu pisać historyjkę, którą deweloper zrozumie bez dopytywania, układać i porządkować backlog (refinement to nie spotkanie dla zabawy, tylko moment, w którym łapiesz braki w wymaganiach, zanim trafią na sprint) oraz wyciągać dane z Jiry filtrem JQL, zamiast klikać po dwadzieścia razy. Po stronie Confluence chodzi o jedno: jedno źródło prawdy. Jak udokumentujesz proces rejestracji wizyty w MediFlow tak, żeby pół roku później nowa osoba w zespole nie odtwarzała go z pamięci trzech ludzi. Większość juniorów zna Jirę z poziomu „przeciągnij kartę", a gubi się przy workflow i polach niestandardowych, i to widać na pierwszym tygodniu pracy. Tego kawałka nie poćwiczysz w sandboksie, więc zrób sobie darmowe konto Atlassiana i przeklikaj wszystko na żywo.

Projekty rzadko wywracają się na technologii. Wywracają się na ludziach: dyrektor, którego nikt nie zapytał o zdanie, blokuje wdrożenie w ostatnim tygodniu. Zarządzanie interesariuszami to systematyczne zapobieganie takim scenariuszom. Uczysz się tu mapować ludzi wokół projektu według wpływu i nastawienia, planować komunikację per grupa (sponsor dostaje jednostronicowe podsumowanie, zespół szczegóły, dział prawny tylko to, co go dotyczy) oraz rozbrajać konflikty, zanim eskalują. Najtrudniejsza część? Interesariusz ukryty: nie przychodzi na spotkania, ale ma weto. Nauczysz się go znajdować, zanim on znajdzie Ciebie. W ogłoszeniach na mid BA „zarządzanie interesariuszami” pojawia się wprost, obok wymagań i dokumentacji - sprawdź na /praca. Test ze stakeholder managementu na platformie zamyka etap.

Wymagania nie kończą życia po spisaniu. Zmieniają się, mnożą, przeczą sobie nawzajem i giną w mailach - a po pół roku nikt nie wie, czemu system robi to, co robi. Zarządzanie wymaganiami to dyscyplina, która nad tym panuje: wersjonowanie i śledzenie zmian (kto, kiedy, dlaczego), priorytetyzacja, gdy wszystko jest „na wczoraj” (MoSCoW, WSJF i ich granice), estymacja z zespołem oraz pilnowanie spójności, gdy wymaganie 47 zaprzecza wymaganiu 12. Na projektach z podwykonawcami to także podstawa rozliczeń: zakres bez kontroli zmian to zaproszenie do sporu o każdą fakturę, co niejedna firma w Polsce przerobiła na własnej skórze. Test z estymacji i priorytetyzacji na platformie sprawdzi, czy umiesz powiedzieć „nie” z uzasadnieniem. Bo na tym etapie głównie o to chodzi.

Mid BA, który nie umie pracować z danymi, oddaje pole. W ogłoszeniach coraz częściej zamiast „mile widziany SQL” stoi „analiza danych i raportowanie” jako obowiązek - zerknij na /praca, kategoria analityka danych mówi sama za siebie. Ten etap uczy odpowiadać danymi na pytania biznesowe: nie „pokaż wszystko, co mamy”, tylko „czy klienci z promocji zostają na dłużej?”. Poznasz podstawy statystyki opisowej (średnia kłamie, mediana rzadziej), dobieranie wykresu do typu danych, budowanie raportu z jedną tezą zamiast dwudziestu tabel oraz najczęstszą pułapkę tej pracy: mylenie korelacji z przyczyną. Na koniec sprawdzisz się na mocku egzaminu IIBA-CBDA, certyfikacji z business data analytics. To dobre lustro - pokazuje, czy myślisz danymi, czy tylko je oglądasz.

Scrum znajdziesz w niemal każdym ogłoszeniu dla BA, a na rozmowach pada pytanie-pułapka: czym różni się rola analityka od Product Ownera w Scrumie? Po tym etapie odpowiesz bez zająknięcia. Uczysz się tu pracy analityka w zespole zwinnym: refinementu backlogu (to tam BA spędza najwięcej czasu), pisania i cięcia historyjek pod sprint, swojej roli na planningu, daily i retro, oraz Kanbana tam, gdzie sprinty nie mają sensu, na przykład w utrzymaniu. I rzecz, której nie mówią na kursach Scruma: w polskich firmach „Scrum” często znaczy „Scrum, ale...” - analityk musi umieć pracować w obu wersjach bez ewangelizowania zespołu. Etap zamyka test z Agile i Scruma, a jeśli celujesz w certyfikację PSM I, na platformie czeka mock tego egzaminu.

Twój projekt nie żyje w próżni. System rejestracji wizyt dotyka kartoteki pacjentów, rozliczeń z NFZ i hurtowni danych - a Ty musisz wiedzieć, co ruszysz, zanim to ruszysz. Ten etap uczy czytać architekturę organizacji: jakie systemy istnieją, kto jest ich właścicielem, które integracje są krytyczne i gdzie Twoje niewinne „dodajmy jedno pole” oznacza zmiany w czterech systemach. Poznajesz pojęcia TOGAF na tyle, żeby rozumieć architektów (pełne ramy zostają na poziom senior), i uczysz się analizy wpływu, czyli odpowiadania na pytanie „co się zepsuje, jeśli to zmienimy”. Mid BA z tą umiejętnością przestaje być zaskakiwany na komitetach zmian. A bywa tam naprawdę nieprzyjemnie, zwłaszcza gdy ktoś pierwszy raz widzi listę systemów, które właśnie dotknął swoim wymaganiem.

Podstawowy SQL odpowiada na pytanie „ile sprzedaliśmy w maju”. Zaawansowany na „pokaż, jak zmieniała się sprzedaż każdego klienta miesiąc do miesiąca i kto wypadł z top 10”. Różnica to funkcje okienkowe (ROW_NUMBER, LAG, suma krocząca), CTE zamieniające zapytanie-potwora w czytelne, nazwane kroki, oraz rozumienie, czemu zapytanie mieli dane 40 sekund i jak zejść do dwóch. Na rozmowach na mid BA i stanowiska analityczne zadania z funkcji okienkowych to klasyk - kandydaci sypią się na nich częściej niż na czymkolwiek innym, co sprawdzam za każdym razem, gdy prowadzę rekrutację. Ćwiczysz w sandboksie na platformie, poziom hard, z automatyczną weryfikacją wyniku. Po tym etapie przestajesz zanosić zespołowi BI prośby o „wyciągnięcie danych”. Sam jesteś tym zespołem.

Zespoły potrafią przez pół roku sprawnie budować funkcję, której nikt nie chce. Discovery to praktyki, które mają temu zapobiec: zanim coś trafi do backlogu, sprawdzasz, czy problem istnieje, czy jest wart rozwiązania i czy Twoje rozwiązanie w ogóle go adresuje. Uczysz się tu pracy w modelu Dual Track, gdzie odkrywanie i dostarczanie biegną równolegle, formułowania hipotez produktowych, frameworku Jobs-to-be-Done (pytanie „do jakiej roboty klient zatrudnia produkt”) oraz tanich testów pomysłów: wywiadów, prototypów, fake door. Na tym etapie granica między BA a Product Ownerem robi się cienka i to dobrze - discovery to naturalna ścieżka rozwoju analityka w stronę ról produktowych, z których rynek płaci wyraźnie lepiej. Mock egzaminu PSPO I na platformie pokaże Ci, ile produktowego myślenia już masz.

„Wydaje mi się, że nowy formularz będzie lepszy” kontra „wersja B podniosła konwersję, sprawdziliśmy na połowie ruchu przez dwa tygodnie”. Zgadnij, która wypowiedź wygrywa na komitecie. Testy A/B pozwalają opierać decyzje produktowe na eksperymencie, nie na opinii najgłośniejszej osoby na sali. Uczysz się tu stawiać hipotezy, które da się obalić, dobierać metryki sukcesu przed startem, a nie po, rozumieć, czemu test na 50 użytkownikach niczego nie dowodzi, i wyłapywać klasyczne błędy: zatrzymanie testu pierwszego dnia, „bo już widać”, albo testowanie pięciu zmian naraz. Dla BA w zespole produktowym to chleb powszedni. A dobrze policzony eksperyment potrafi zakończyć miesięczny spór jedną liczbą - widziałem to i jest to bardzo satysfakcjonujący moment.

Każdy dział widzi swój kawałek: marketing kampanię, sprzedaż lejek, support tickety. Nikt nie widzi, że klient między tymi etapami trzy razy podaje te same dane i raz trafia w ślepy zaułek. Mapa podróży klienta skleja te kawałki w jeden obraz. Uczysz się tu budować journey mapy na danych (tickety, nagrania rozmów, analityka), a nie na wyobrażeniach zespołu o kliencie, tworzyć persony będące narzędziem pracy, a nie plakatem na ścianę, i zamieniać znalezione punkty bólu na konkretne pozycje w backlogu. Przećwiczysz na MediFlow: droga pacjenta od „boli mnie ząb” do wizyty, łącznie z momentem, w którym rejestracja nie odbiera telefonu. Bonus praktyczny: warsztat z mapą podróży to świetne narzędzie wydobywania, bo interesariusze sami zaczynają zauważać dziury we własnym procesie.

Otwórz dowolne ogłoszenie na mid z /praca i policz, ile razy obok BPMN pojawia się UML. To nie przypadek, że stoją parą. UML w pracy BA nie służy do projektowania klas Javy, tylko do dogadania się. Diagram przypadków użycia pokazuje, kto i po co wchodzi do systemu (kto rezerwuje wizytę w MediFlow: pacjent, rejestratorka czy lekarz?), diagram aktywności rozpisuje przepływ decyzji, sekwencji pokazuje rozmowę między modułami, a klas, na poziomie pojęciowym, porządkuje encje i ich powiązania. Tu nauczysz się czytać i rysować te cztery diagramy oraz wyczuwać granicę: proces biznesowy end-to-end zostawiasz BPMN-owi, a zachowanie i strukturę samego systemu bierze UML. Najczęstszy błąd, który łapię na rozmowach, to diagram klas z typami pól i metodami, czyli kod udający rozmowę z biznesem. Sponsor patrzy na taki obrazek i milczy, bo nic z niego nie rozumie. Diagram ma się tłumaczyć sam, bez ciebie stojącego obok z wyjaśnieniami. Na koniec podchodzisz do egzaminu i odbierasz certyfikat Podstawy UML, który ląduje w twoim profilu i portfolio.

Wklejasz fragment regulaminu MediFlow do publicznego chatbota, żeby „szybciej napisać wymagania" - i właśnie wysłałeś dane medyczne pacjentów na cudze serwery. To pierwsza rzecz, której się tu oduczysz. GenAI nie zastąpi analizy, ale przepisanie surowych notatek z warsztatu na draft user stories z kryteriami akceptacji potrafi skrócić robotę z godziny do dziesięciu minut, pod warunkiem że potem przejdziesz to zdanie po zdaniu, bo model zmyśli wymaganie, którego nikt nie zgłosił. Nauczysz się pisać prompty, które dają konkret zamiast lania wody: kontekst projektu, format wyjścia, jawne ograniczenia. Drugą połowę tego etapu zajmuje governance, czyli co wolno wkleić, a czego nigdy: kartoteki pacjentów, dane osobowe, fragmenty umów objętych NDA. Na rozmowach na mid coraz częściej pada pytanie „jak używasz AI w pracy i gdzie stawiasz granicę", a odpowiedź „wrzucam wszystko do ChatGPT" kończy rekrutację. Moje zdanie: hype jest przesadzony, ale analityk, który traktuje GenAI jak szybkiego stażystę do sprawdzenia, a nie wyrocznię, wygrywa kilka godzin tygodniowo.

"System ma się integrować z NFZ" to nie wymaganie, to życzenie, a integrację rozbija nie kod, tylko dziury w takim opisie. Na tym etapie uczysz się, czym API i REST są naprawdę: że to umówiony sposób, w jaki dwa systemy gadają, a JSON to format, w którym przesyłają dane. Zobaczysz, jak czytać kontrakt API (OpenAPI/Swagger), żeby wiedzieć, jakie pola system po drugiej stronie przyjmie, a które odrzuci. W MediFlow rezerwacja wizyty woła zewnętrzny kalendarz lekarza i tu pada decyzja, która spędza sen z powiek: synchronicznie (pacjent czeka na odpowiedź) czy asynchronicznie (dostaje potwierdzenie SMS-em za chwilę). Ten wybór to wymaganie biznesowe, nie techniczne, i to Ty musisz je nazwać. Nauczysz się pisać wymagania, które zespół integracyjny może wziąć i zbudować: jakie dane lecą, co się dzieje, gdy druga strona nie odpowiada, ile razy ponawiać próbę. Wejdź na /praca i policz oferty na mid, gdzie „doświadczenie w projektach integracyjnych" stoi w wymaganiach - to nie nisza, to standard. BA jest tu tłumaczem: biznes mówi „ma działać", zespół pyta „co dokładnie ma się stać o 2 w nocy, gdy API padnie", a Ty stoisz w środku.

"Działa" to za mało. Na mid musisz napisać, jak szybko, dla ilu naraz i co się stanie, gdy padnie. Ten węzeł uczy zamieniać życzenia na liczby: zamiast "system ma być wydajny" piszesz "lista wizyt w MediFlow ładuje się poniżej 2 sekund dla 500 użytkowników jednocześnie, dostępność 99,5% w godzinach 7-20". Poznasz trzy rodziny NFR-ów (wydajność, dostępność, bezpieczeństwo) i zrozumiesz, dlaczego NFR bez wartości progowej i sposobu pomiaru nadaje się tylko do kosza. Druga połowa to RODO od strony analityka: podstawa prawna przetwarzania, okres retencji kartoteki pacjenta, prawo do usunięcia (i co z danymi medycznymi, których prawo usunąć nie pozwala) oraz to, kiedy proces wymaga DPIA. Granica jest tu wyraźna: nie robisz threat modelingu ani audytu jak na ścieżce eksperckiej Cybersecurity, tylko piszesz mierzalne wymagania, które ten audyt potem sprawdzi. Wejdź na /praca i sprawdź ogłoszenia na mid: "wymagania niefunkcjonalne" i "RODO" pojawiają się tam częściej niż niejeden framework, a na rozmowie większość kandydatów zatrzymuje się na "no, system ma być bezpieczny". Po tym etapie nie będziesz jednym z nich.

Za każdym formularzem, raportem i integracją siedzi model danych - i jeśli jest zły, żadna ilość kodu tego nie naprawi. Senior BA modeluje dane na poziomie konceptualnym i logicznym: jakie encje istnieją w domenie, jak się mają do siebie, co jest unikalne, a co opcjonalne. W MediFlow: Pacjent ma wiele Wizyt, Wizyta ma jednego Lekarza i miejsce w Grafiku. A co z wizytą odwołaną? Z lekarzem na zastępstwie? Te pytania zadaje właśnie analityk, najlepiej zanim baza powstanie, bo potem każda odpowiedź kosztuje migrację. Nauczysz się rysować diagramy ERD, normalizować dane i świadomie od normalizacji odstępować (na przykład pod raportowanie) oraz rozmawiać z zespołem o modelu fizycznym bez wchodzenia mu w kompetencje. Ten etap spina Twojego SQL-a z architekturą: nagle widzisz, czemu baza wygląda tak, jak wygląda.

Na poziomie senior przestajesz pytać „jak to zbudować” i zaczynasz pytać „po co firma w ogóle to robi”. Strategia biznesowa daje narzędzia do tej rozmowy: SWOT i PESTLE robione porządnie, czyli z wnioskami i decyzjami, a nie jako tabelka do prezentacji, którą wszyscy znamy i wszyscy ignorujemy, Business Model Canvas do rozłożenia modelu firmy na 9 klocków oraz mapy strategii łączące cele finansowe z procesami i kompetencjami. Senior BA z tym warsztatem potrafi powiedzieć sponsorowi: ten projekt nie wspiera żadnego celu strategicznego, może go nie róbmy. Takie zdanie wymaga odwagi i danych - tutaj uczysz się jednego i drugiego. To również język zarządów: jeśli chcesz kiedyś rozmawiać o budżetach, musisz mówić strategią, nie backlogiem.

Senior BA często de facto prowadzi projekt, nawet jeśli na wizytówce ma to kto inny. Ten etap nie robi z Ciebie PM-a. Daje Ci warsztat, żeby rozumieć projekt jako całość: planowanie zakresu i kamieni milowych, budżet i ścieżkę krytyczną (czyli czemu opóźnienie jednego zadania o 3 dni przesuwa wdrożenie o miesiąc), zarządzanie ryzykiem z rejestrem, który ktoś faktycznie aktualizuje, oraz podstawy PMBOK i PRINCE2 na poziomie „rozumiem, w jakim świecie żyje mój project manager”. Znajomość obu perspektyw, analitycznej i projektowej, to częsty wymóg w ogłoszeniach na Lead BA. Test z zarządzania ryzykiem masz na platformie. I moment szczerości: część analityków po tym etapie świadomie skręca w stronę zarządzania projektami. To też jest wygrana - o ile to wybór, a nie dryf.

W pewnym momencie firma zaczyna Cię rozliczać nie z Twoich diagramów, tylko z tempa rozwoju juniorów obok Ciebie. Mentoring to przejście z „umiem” na „potrafię nauczyć” - a to dwie różne umiejętności. Uczysz się tu prowadzić rozmowy rozwojowe, dawać feedback, który zmienia zachowanie zamiast psuć relację (konkret i zachowanie, nie ocena człowieka), dobierać zadania na miarę, bo junior ma się rozciągnąć, nie utopić, i odpuszczać kontrolę. To ostatnie jest najtrudniejsze: pozwolić komuś zrobić coś gorzej, niż zrobiłbyś sam, bo inaczej nigdy się nie nauczy. Kompetencja wprost z ogłoszeń na Lead BA i Head of BA. Na platformie ćwiczysz ją od razu: recenzje w peer review i pomaganie w społeczności to mentoring w mikroskali, z prawdziwymi ludźmi po drugiej stronie.

Senior BA coraz częściej współprojektuje rozwiązanie, a nie tylko opisuje problem. Ten etap to architektura od strony wymagań: jak decyzje architektoniczne (monolit czy mikroserwisy, integracja synchroniczna czy kolejka) wynikają z wymagań niefunkcjonalnych, które TY spisujesz. „System ma być szybki” to nie jest wymaganie. „Wyszukiwanie terminu wizyty poniżej 2 sekund przy 200 równoczesnych użytkownikach” - z tego architekt coś zbuduje. Poznasz typowe wzorce integracji: API, zdarzenia, wymiana plików (tak, pliki wciąż żyją w polskich korporacjach i pożyją jeszcze długo), nauczysz się czytać diagramy architektury i uczestniczyć w decyzjach jako partner, nie notariusz. Stąd prowadzi ścieżka do roli Solution Architecta od strony biznesowej - jednej z naturalnych i dobrze płatnych końcówek kariery analityka.

Pojedynczy projekt optymalizuje swój kawałek. Architektura korporacyjna pilnuje, żeby sto takich projektów nie zbudowało stu silosów. Na tym etapie patrzysz na organizację z lotu ptaka: mapy zdolności biznesowych (capability maps) pokazujące, co firma robi niezależnie od tego, w jakich systemach, ramy TOGAF na poziomie roboczym - cykl ADM jako sposób myślenia, nie biurokracja do odhaczenia - oraz łączenie strategii z portfelem projektów, czyli odpowiedź na pytanie, czemu robimy ten projekt, a nie tamten. Senior BA z tą perspektywą wchodzi do rozmów, do których wcześniej nie miał wstępu: przeglądy portfela, rady architektury, planowanie roczne. To przedsionek ról Business Architect i Practice Lead, realnych szczytów tej ścieżki na polskim rynku. I tak, na tych spotkaniach naprawdę zapadają decyzje o budżetach.

„Klient” znaczy co innego dla sprzedaży, co innego dla rozliczeń i jeszcze co innego dla supportu - a wszyscy trzej mają rację. Domain-Driven Design daje na to język: bounded contexty, w których to samo słowo może legalnie znaczyć różne rzeczy, oraz ubiquitous language, czyli słownik wspólny dla biznesu i kodu w ramach jednego kontekstu. Dla senior BA to narzędzia ciężkiego kalibru: warsztaty event stormingu, na których cała domena ląduje na ścianie w godzinę, mapy kontekstów pokazujące, gdzie systemy muszą się dogadać, i rozmowa z programistami ich językiem. DDD bywa przeintelektualizowane, więc powiem uczciwie: nie każdy projekt go potrzebuje. CRUD-owa aplikacja do wniosków urlopowych nie. System rozliczeń sieci przychodni z NFZ - jak najbardziej. Nauczysz się odróżniać jedno od drugiego.

Data scientistą tu nie zostaniesz i nie o to chodzi. Zostaniesz analitykiem, który wie, kiedy problem nadaje się dla data science, a kiedy wystarczy dobry SELECT z GROUP BY. To rzadsza umiejętność, niż się wydaje. Nauczysz się rozpoznawać klasy problemów (predykcja, klasyfikacja, segmentacja), oceniać, czy firma w ogóle ma dane, żeby je rozwiązać, i tłumaczyć biznesowi, czemu model nigdy nie da 100% trafności. W projektach z zespołem DS rola BA to pilnowanie, żeby model rozwiązywał problem biznesowy, a nie ten, który było łatwo policzyć. Widziałem wdrożenie, gdzie zespół przez pół roku budował model odejść klientów, a biznes potrzebował po prostu listy ludzi do obdzwonienia w piątek. Ktoś powinien był to powiedzieć w pierwszym tygodniu. Ten ktoś to Ty.

BA nie robi pentestów i nie konfiguruje firewalli. BA pisze wymagania, przez które system albo przejdzie audyt, albo nie. Ten etap to bezpieczeństwo od strony analizy: wymagania niefunkcjonalne (kto może widzieć kartotekę pacjenta w MediFlow? po ilu minutach wylogować bezczynną sesję?), RODO w praktyce projektowej (retencja, prawo do usunięcia, rejestr czynności) i podstawy threat modelingu na poziomie „co może pójść nie tak w tym procesie”. Na rozmowach o pracę na mid i senior BA pytanie o RODO pada częściej niż pytanie o BPMN, a większość kandydatów odpowiada ogólnikami. Na platformie czeka test z RODO i compliance - sprawdzisz na nim między innymi, czy odróżniasz anonimizację od pseudonimizacji. Z doświadczenia: większość nie odróżnia.

Nie musisz niczego wdrażać w chmurze, żeby być dobrym BA. Musisz za to rozumieć, o czym mówi architekt, kiedy rzuca „postawimy to na lambdach”, i co to zrobi z budżetem projektu. Ten etap to chmura z perspektywy wymagań: modele IaaS/PaaS/SaaS, regiony i ich konsekwencje dla RODO, koszty pay-as-you-go kontra stała licencja. W projektach migracyjnych BA jest tłumaczem między biznesem („czemu to tyle kosztuje co miesiąc?”) a zespołem cloud. Widziałem analityków, którzy na warsztacie z architektem kiwali głową, a potem pisali wymagania niemożliwe do wycenienia. Nie idź tą drogą. Nie wkuwasz tu certyfikatów AWS na pamięć - uczysz się zadawać właściwe pytania i czytać estymaty kosztów bez paniki, bo to analityk pierwszy tłumaczy biznesowi rachunek za chmurę.

W pewnym momencie kariery przestajesz być rozliczany z własnych diagramów, a zaczynasz z tego, co umie Twój zespół. Szkolenia i warsztaty to naturalny etap seniora: wdrażasz juniorów, uczysz biznes pisać lepsze zgłoszenia, prowadzisz warsztat z notacji dla całego działu. To też najszybszy test, czy naprawdę coś umiesz - wytłumaczyć BPMN komuś, kto widzi go pierwszy raz, jest trudniejsze niż narysować najbardziej złożony proces. Nauczysz się projektować szkolenie od celu („po 4 godzinach uczestnik narysuje własny proces”), a nie od slajdów, prowadzić ćwiczenia zamiast wykładów i sprawdzać, czy cokolwiek zostało w głowach tydzień później. Dla części analityków to początek osobnej ścieżki: trener, konsultant, własna działalność. Sam tę drogę przeszedłem i wiem, że zaczyna się właśnie od pierwszego wewnętrznego warsztatu.

Klient mówi „chcemy AI w produkcie”. I co teraz? Ten etap uczy zamieniać takie hasło na wymagania, które zespół ML potrafi wycenić i zbudować. Poznajesz cykl życia modelu od strony analityka: skąd wziąć dane treningowe, kto je oznaczy, jakie metryki wybrać (precision czy recall - przy wykrywaniu fraudów ta różnica to realne pieniądze), co się dzieje, gdy model się pomyli, i kto wtedy odpowiada. Nauczysz się też pisać kryteria akceptacji dla funkcji opartych na ML, bo „system poprawnie rozpoznaje faktury” to nie jest kryterium, które ktokolwiek odbierze. Po 2023 roku komponent AI siedzi w prawie każdym większym projekcie, a analityków umiejących o nim rozmawiać konkretnie jest na rynku garstka. To dobra nisza na wyróżnienie się - bez przebranżawiania się na data scientista.

Senior odchodzi z projektu i nagle nikt nie wie, czemu rabaty liczą się inaczej dla klientów sprzed 2019 roku. Znasz to? Zarządzanie wiedzą to odpowiedź na dokładnie ten scenariusz. Uczysz się tu budować dokumentację, która żyje: rejestr decyzji projektowych (co postanowiono, kto i dlaczego), słownik pojęć domenowych, standardy opisywania procesów, onboarding nowego analityka w tydzień zamiast dwóch miesięcy. To kompetencja Lead BA i Practice Leada, czyli ludzi rozliczanych nie z jednego projektu, tylko z tego, jak pracuje cały zespół analityków. Różnica między „mamy Confluence” a „mamy wiedzę” jest brutalna: w pierwszym przypadku masz 400 nieaktualnych stron, w drugim nowa osoba znajduje odpowiedź szybciej, niż zdąży o nią zapytać. Da się to zaprojektować - i tego dotyczy ten etap.