Na naszym job boardzie jest dziś 330 aktywnych ofert dla analityków biznesowych. Poziom junior deklaruje 25 z nich. Dwadzieścia pięć. Mid i senior mają po dziewięćdziesiąt kilka. Wejście do zawodu to wąskie drzwi, a w kolejce przed nimi stoją kandydaci z niemal identycznymi CV: ten sam kurs, ta sama lista narzędzi, zero dowodów.
Rekruter nie ma jak odróżnić osoby, która przerobiła materiał na serio, od osoby, która przewinęła wideo w niedzielę. Chyba że któraś z nich pokaże pracę. W tym tekście dostaniesz cztery projekty do zrobienia bez pracy w IT (każdy w jeden weekend), szablon opisu projektu i checklistę do odhaczenia przed wysłaniem linku. Trzy rzeczy do zapisania na później.
Po co portfolio analityka biznesowego, skoro „nie jesteś programistą”
Znam ten argument. Programista ma GitHub, grafik ma Behance, a analityk co niby pokaże? Notatki ze spotkań?
Otóż praca analityka zostawia artefakty: diagramy procesów, dokumenty wymagań, user stories, analizy z wnioskami, rekomendacje. Każdy z nich da się pokazać. Na poziomie wejściowym prawie nikt tego nie robi. I właśnie dlatego to działa.
CV mówi, portfolio pokazuje. To nie jest slogan, tylko różnica w tym, co rekruter może zweryfikować. Deklarację „znam BPMN” musi wziąć na wiarę. Diagram procesu z trzema sensownymi usprawnieniami ocenia w dwie minuty, sam, bez dzwonienia po referencje.
Uczciwie o danych: mój agregator ogłoszeń nie taguje tego, ile ofert wprost prosi o przykłady pracy, więc takiej liczby tu nie podam. Ale dwie rzeczy z bazy widzę czarno na białym. Po pierwsze, w 566 ogłoszeniach dla analityków z ostatnich 90 dni nazwa żadnego certyfikatu nie padła ani razu w tytułach, zajawkach i tagach wymagań. Papier nie jest filtrem. Po drugie, filtrem są kompetencje: BPMN pojawia się w 22% aktywnych ofert, UML w 20%, SQL w 15%. Portfolio to najkrótsza droga, żeby te kompetencje udowodnić, zanim ktokolwiek zaprosi Cię na rozmowę.
Moim zdaniem na etapie wejścia dobre portfolio robi większą różnicę niż kolejny kurs, bo kursy mają wszyscy, a dowody pracy prawie nikt. Dotyczy to też osób bez doświadczenia komercyjnego: żaden z czterech projektów poniżej nie wymaga pracy w IT ani zgody pracodawcy. Jak portfolio wpisuje się w całą ścieżkę do pierwszej roli, opisałem w tekście o wejściu do zawodu bez doświadczenia.
Co zawiera dobre portfolio BA - 5 elementów
Zanim rzucisz się w projekty, ustalmy, z czego portfolio analityka w ogóle się składa. Nie z listy ukończonych kursów i nie ze skanów zaświadczeń. Z pięciu rzeczy:
- Artefakty, nie opisy artefaktów. Konkretny diagram, konkretny dokument wymagań, konkretna analiza z zapytaniami. 2-4 sztuki. Piętnastu projektów nikt nie otworzy, trzy dobre robią robotę.
- Kontekst biznesowy przy każdym artefakcie. Jaki problem, czyj problem, dlaczego wart rozwiązania. Diagram bez kontekstu to obrazek. Diagram z kontekstem to dowód, że rozumiesz, po co powstał.
- Twoja rola, w pierwszej osobie. Co Ty ustaliłeś, co Ty sprawdziłeś, co Ty zdecydowałeś. „Zespół przeanalizował proces” nie mówi o Tobie nic.
- Wnioski i decyzje. Co zarekomendowałeś, co odrzuciłeś i dlaczego. To tu widać myślenie analityczne, nie w składni notacji.
- Publiczny link, który działa na telefonie. Rekruter otworzy Twoje portfolio między spotkaniami, na komórce. Jeśli zobaczy ekran logowania albo załącznik 20 MB, zamknie kartę i wróci do kolejnego CV.
Jeszcze jedno, skoro część firm rekrutuje po angielsku: w ogłoszeniach zagranicznych ten sam dowód pracy funkcjonuje jako „business analyst portfolio” i działa identycznie. Te same artefakty, tylko opisy w dwóch językach.
4 projekty do portfolio, które zrobisz bez pracy w IT (każdy w 1 weekend)
Zasada wspólna: każdy projekt kończy się artefaktem plus opisem według szablonu z następnej sekcji. Weekend wystarczy, jeśli nie wpadniesz w pułapkę dopieszczania w nieskończoność. Wersja skończona bije wersję idealną.
Projekt 1: mapa procesu z Twojej obecnej pracy (as-is plus 3 usprawnienia)
Najlepszy projekt na start, bo materiał masz pod ręką od dziś, niezależnie od branży. Księgowość, logistyka, gastronomia, urząd, szkoła - wszędzie są procesy i wszędzie coś w nich zgrzyta.
Co zrobić: wybierz proces, który Cię regularnie irytuje. Obieg faktury, onboarding nowego pracownika, obsługa reklamacji, zamawianie materiałów. Rozpisz go krok po kroku tak, jak działa naprawdę (as-is), nie jak powinien - 8-15 kroków, z decyzjami i pętlami zwrotów. Porozmawiaj z dwiema, trzema osobami, które w nim uczestniczą. Oszacuj czasy kroków, wskaż wąskie gardła i zaproponuj trzy usprawnienia z przewidywanym efektem. Rozdzielenie stanu obecnego od docelowego rozpisałem w artykule o analizie as-is i to-be.
Artefakt: diagram procesu plus jedna strona rekomendacji. Najlepiej w notacji BPMN, bo prosi o nią 22% ofert z naszej bazy; podstawy notacji masz w tekście o BPMN.
Jak opisać: zacznij od problemu („faktura utykała, nikt nie wiedział gdzie”), nie od narzędzia. I koniecznie zanonimizuj: zmień nazwę firmy, nazwiska, wrażliwe liczby zaokrąglij. Pokazujesz umiejętność, nie dane pracodawcy.
Projekt 2: analiza SQL na otwartym zbiorze danych
Kolejność ma znaczenie: najpierw pytania biznesowe, potem zapytania. Analiza, która zaczyna się od składni, kończy się tabelką bez wniosków.
Co zrobić: weź otwarty zbiór danych - dane publiczne GUS, otwarte dane miejskie, publiczny zbiór sprzedażowy. Sformułuj 5-7 pytań, które zadałby właściciel tego biznesu: co się najlepiej sprzedaje i kiedy, którzy klienci odchodzą, gdzie ucieka marża. Do każdego pytania napisz zapytanie i, co ważniejsze, wniosek jednym zdaniem. Całość zamknij jedną rekomendacją: co bym zrobił na miejscu właściciela i czego się po tym spodziewam.
Artefakt: dokument z pytaniami, zapytaniami i wnioskami, 3-5 stron.
Jak opisać: przez decyzje, nie przez składnię. Pułapka tego projektu to popisywanie się JOIN-ami. SQL jest w tej pracy narzędziem, nie gwiazdą - rdzeniem analizy biznesowej pozostają wymagania, procesy i interesariusze, a rekrutera obchodzi, czy z danych umiesz wyciągnąć decyzję. Ile SQL-a naprawdę potrzebujesz, opisałem w tekście SQL dla analityka biznesowego.
Projekt 3: dokument wymagań dla aplikacji, której Ci brakuje
Nie wymyślaj fikcyjnego banku. Weź realną lukę z własnego życia: zapisy do przychodni, w której wisisz na telefonie, rezerwacja sal w Twojej firmie, grafik zmian w lokalu, w którym pracowałeś. Realny problem daje realne wymagania.
Co zrobić: opisz problem i cel biznesowy. Wypisz interesariuszy i czego każdy z nich potrzebuje - pacjent chce się zapisać w minutę, rejestratorka nie chce podwójnych rezerwacji, kierownik chce widzieć obłożenie. Wyznacz zakres, koniecznie z sekcją „poza zakresem”, bo to ona odróżnia analityka od marzyciela. Potem 10-15 user stories z kryteriami akceptacji i priorytetyzacja, na przykład metodą MoSCoW.
Artefakt: mini-specyfikacja na 4-6 stron. Formę przećwiczysz z dwoma tekstami: jak pisać user stories i jak pisać kryteria akceptacji. A jeśli chcesz pójść o krok dalej, strukturę pełnego dokumentu znajdziesz w artykule o specyfikacji wymagań SRS.
Jak opisać: podkreśl decyzje zakresowe. „Wyciąłem moduł płatności z pierwszej wersji, bo bez niego produkt też rozwiązuje główny problem” brzmi jak zdanie analityka z doświadczeniem, a wymaga tylko przemyślenia.
Projekt 4: case study usprawnienia (problem, analiza, rekomendacja)
Ten projekt najbardziej przypomina to, co analityk oddaje na koniec realnej pracy: dokument, który prowadzi czytelnika od problemu do decyzji.
Co zrobić: wybierz problem znany z autopsji. Porzucane koszyki w sklepie, w którym kupujesz, kolejki w punkcie obsługi, chaos komunikacyjny w projekcie. Opisz go z liczbami - własne obserwacje i szacunki są w porządku, jeśli jawnie napiszesz, że to szacunki. Przeanalizuj przyczyny, rozpisz 2-3 opcje rozwiązania z kosztami i ryzykami, zarekomenduj jedną i uzasadnij. Dopisz, czego nie wybrałeś i dlaczego.
Artefakt: 2-3 strony tekstu z jedną tabelą porównania opcji.
Jak opisać: struktura problem, analiza, rekomendacja obroni się sama, jeśli jej nie rozmyjesz. Potrzebujesz wzorca? Na platformie Analify mamy 12 case studies rozpisanych krok po kroku - zobacz, jak prowadzą od pytania do wzorcowego rozwiązania, i odtwórz ten szkielet na własnym temacie.
Jak opisać projekt: szablon KONTEKST → DZIAŁANIE → WYNIK
Najczęstszy błąd w portfolio, jaki widuję, to opisywanie narzędzi zamiast decyzji. Porównaj:
Źle: „Wykonałem diagram procesu w notacji BPMN 2.0 w draw.io, z bramkami XOR i zdarzeniami pośrednimi.”
Dobrze - trzy akapity według szablonu (liczby przykładowe, podstaw własne):
KONTEKST: W biurze rachunkowym, w którym pracuję, akceptacja faktury kosztowej potrafiła trwać ponad tydzień i nikt nie umiał wskazać, gdzie dokument utyka. Rozrysowałem proces, żeby to zlokalizować.
DZIAŁANIE: Zmapowałem 12 kroków procesu as-is na podstawie rozmów z trzema osobami, które w nim uczestniczą. Oszacowałem czasy i znalazłem dwa wąskie gardła: ręczne przepisywanie danych oraz akceptację uzależnioną od jednej osoby. Rozpisałem trzy usprawnienia z przewidywanym efektem każdego.
WYNIK: Zarekomendowałem zastępstwo w akceptacji plus prosty rejestr statusów - według moich szacunków skraca to proces o około jedną trzecią bez kupowania nowego systemu. Dwa pozostałe usprawnienia odrzuciłem, bo koszt wdrożenia przewyższał spodziewany zysk.
W drugiej wersji nie ma ani słowa więcej o narzędziu, a mimo to widać, że autor pracuje jak analityk: rozmawiał z ludźmi, szacował, odrzucał opcje. Bramka XOR nie jest argumentem w rozmowie rekrutacyjnej. Odrzucona opcja z uzasadnieniem jest.
Wypełnij ten szablon dla każdego z czterech projektów. Trzy akapity, maksymalnie osiem zdań. Rekruter przeczyta wszystkie właśnie dlatego, że są krótkie.
Gdzie hostować portfolio (i czemu PDF w mailu to za mało)
PDF wysłany mailem ginie w skrzynce, źle wygląda na telefonie i umiera w dniu wysyłki: nie zaktualizujesz go, nie podepniesz w CV, nie wkleisz na LinkedIn. Portfolio potrzebuje adresu, który wpisujesz wszędzie tam, gdzie pojawia się Twoje nazwisko.
| Opcja | Co daje | Na co uważać |
|---|---|---|
| Notion albo prosta strona | pełna kontrola nad formą, start w godzinę | sprawdź uprawnienia (link publiczny, nie „tylko zaproszeni”) i widok na telefonie |
| LinkedIn, sekcja Polecane | zobaczy je każdy, kto wejdzie na Twój profil | to witryna, nie dom - podlinkuj stąd pełne portfolio |
| Portfolio na Analify | publiczny adres działający bez logowania, projekty, pliki i diagramy w jednym miejscu, eksport do PDF na życzenie | część platformy, więc najwięcej daje w komplecie z resztą nauki |
O opcji trzeciej piszę otwarcie, bo to mój produkt. Każdy użytkownik platformy dostaje portfolio z publicznym adresem: rekruter klika i widzi projekty, pliki oraz diagramy bez zakładania konta. Jest też rzecz, której nie da Ci żaden hosting: zanim link trafi do rekrutera, możesz oddać pracę do peer review. Inni analitycy ocenią ją w trybie double-blind - oni nie wiedzą, czyją pracę czytają, Ty nie wiesz, kto czyta - więc dostajesz szczery feedback zamiast grzecznościowego „super!”.
Którą opcję wybrać? Moim zdaniem dowolną, byle z publicznym linkiem i byle w tym tygodniu. Portfolio hostowane „kiedyś, jak skończę wszystkie projekty” nie istnieje.
Checklist przed wysłaniem do rekrutera
Osiem punktów. Odhacz wszystkie, zanim link opuści Twoją skrzynkę:
- Link otwiera się w oknie incognito, bez logowania i próśb o dostęp.
- Portfolio da się przeczytać na telefonie, bo tak zostanie otwarte.
- Każdy projekt ma kontekst biznesowy w 2-3 zdaniach: jaki problem i czyj.
- Przy każdej decyzji widać Twoją rolę: „ja”, nie „zespół”.
- Są wnioski i decyzje, nie same artefakty - w tym co najmniej jedna odrzucona opcja z uzasadnieniem.
- Dane firm i osób zanonimizowane, wrażliwe liczby zaokrąglone albo jawnie oznaczone jako szacunki.
- Projekty to 2-4 sztuki, najlepszy na górze. Jakość wygrywa z ilością.
- Ktoś przeczytał całość przed rekruterem: peer review, znajomy z branży, ktokolwiek z dystansem.
Zapisz sobie tę listę razem z szablonem opisu i planem czterech projektów. Cztery weekendy od dziś masz komplet materiałów i gotowość do aplikowania popartą dowodami, nie deklaracjami.
Najczęstsze pytania o portfolio analityka
Czy analityk biznesowy potrzebuje portfolio, skoro nie pisze kodu?
Tak - i właśnie dlatego, że na poziomie wejściowym prawie nikt go nie ma. Praca analityka zostawia artefakty: diagramy procesów, dokumenty wymagań, user stories, analizy z wnioskami. Deklarację „znam BPMN" rekruter musi wziąć na wiarę, a diagram z trzema sensownymi usprawnieniami ocenia w dwie minuty. W 566 ogłoszeniach dla analityków z ostatnich 90 dni nazwa żadnego certyfikatu nie padła ani razu - filtrem są kompetencje, a portfolio to najkrótsza droga, żeby je udowodnić.
Ile projektów powinno mieć portfolio analityka biznesowego?
2-4 artefakty, najlepszy na górze. Piętnastu projektów nikt nie otworzy - trzy dobre robią robotę. Każdy potrzebuje kontekstu biznesowego (jaki problem i czyj), Twojej roli opisanej w pierwszej osobie oraz wniosków i decyzji, w tym co najmniej jednej odrzuconej opcji z uzasadnieniem.
Jakie projekty do portfolio zrobię bez pracy w IT?
Cztery, każdy w jeden weekend: mapa procesu z obecnej pracy (as-is plus trzy usprawnienia), analiza SQL na otwartym zbiorze danych, dokument wymagań dla aplikacji, której brakuje Tobie, oraz case study usprawnienia (problem, analiza, rekomendacja). Żaden nie wymaga pracy w IT ani zgody pracodawcy.
Jak opisać projekt w portfolio?
Szablonem KONTEKST - DZIAŁANIE - WYNIK: trzy akapity, maksymalnie osiem zdań. Opisuj decyzje, nie narzędzia - „odrzuciłem dwa usprawnienia, bo koszt wdrożenia przewyższał zysk" znaczy na rozmowie więcej niż nazwa notacji i programu, w którym rysujesz.
Gdzie opublikować portfolio analityka?
Tam, gdzie rekruter otworzy je jednym kliknięciem na telefonie, bez logowania: Notion albo prosta strona, sekcja Polecane na LinkedIn, albo portfolio na Analify - publiczny adres, projekty, pliki i diagramy w jednym miejscu, a przed wysłaniem linku możesz oddać pracę do peer review w trybie double-blind. PDF wysłany mailem ginie w skrzynce i umiera w dniu wysyłki.
Nie wiesz, czy wiedza nadąża za portfolio? Zrób darmowy test wiedzy - bez konta, wynik od razu. A świeże liczby z rynku, którymi podpieram ten tekst, znajdziesz na Barometrze rynku BA.