11 nieskutecznych porad dla analityka biznesowego w IT

10 marca 2023

  • Autor: Lubik Kisluk

  • Złożoność: normalna

  • Czas: 12 min

Cześć, jestem Lubik Kisluck, Szef działu analiz marketingowych w Autodoc AG. Wcześniej pracowałem jako COO w Robosoft industries, a także jako head of BA w Adtelligent. Przez lata pracy w IT zarówno jako wykonawca, jak i klient sam wiele razy robiłem błędy i widziałem, jak inni je robią. Do dzisiejszych porad dodałem studia przypadków z własnej praktyki, żebyś wiedział, czego NIE robić! Przygotuj sobie kawę albo herbatę i zapraszam do nauki!

Jak nie pracować z interesariuszami i zespołem

Gdziekolwiek pracujesz i cokolwiek robisz, są ludzie, z którymi musisz wchodzić w interakcje. Od dobrej komunikacji z nimi wiele zależy: produktywność, dalsza współpraca, ocena twojej firmy na rynku. Powiem ci teraz, jak najszybciej stworzyć negatywne wrażenie o sobie w oczach tych wszystkich ludzi.

1. Nieuzgodnienie wymagań z klientem

Nieuzgodnienie wymagań z klientem

Wiesz, czego chce klient lepiej niż on sam – po co dodatkowe spotkania?

Aby zatrzymać klienta przy swoim zespole jak najdłużej, należy trzymać się następującej sekwencji: najpierw klient mówi ci swoje „zachcianki”, ty jako analityk opracowujesz wymagania biznesowe, omawiasz je z zespołem programistów i przed rozpoczęciem pracy, klient potwierdzasz opracowane wymagania . Niektórzy lekceważą tę prostą zasadę.

Sam grzeszyłem tym na wczesnych etapach kariery, gdy zabrakło mi czasu, lub gdy wydawało mi się, że wszystko mam przemyślane i jest to dokładnie to, czego oczekiwał klient. Tak naprawdę ważne jest, aby sam klient podpisał się pod tym, co ma być zrobione w następnej kolejności.

Zapamiętaj wszystko ze słuchu, miej wiarę w swoją pamięć!

Zapamiętaj wszystko ze słuchu, miej wiarę w swoją pamięć!

Bardzo dobrym narzędziem, z którego doradzam korzystać moim uczniom i stażystom do rejestrowania wymagań jest dyktafon. Uratował mnie wiele razy, w różnych  sytuacjach. Dyktafon pomaga uzyskać trzy rzeczy:

  1. Nic ci nie umyka. Zdarza się, że interesariusz jest nielogiczny, lub mówi w języku, który trudno zrozumieć, więc nie zawsze możliwe jest uchwycenie jego myśli w locie.
  2. Nie musisz prosić o 10-krotne powtórzenie, jeśli jeszcze nie zrozumiałeś terminologii i kontekstu nowego projektu. Wystarczy nagrać wszystkie myśli i życzenia interesariuszy, a następnie z pomocą bazy wiedzy lub innych ekspertów jakoś rozszyfrować, co mają na myśli.
  3. Jeśli interesariusz po fakcie stwierdzi, że robiliście co innego, niż wynikało z przebiegu rozmowy, będziesz miał dowód na to, że mówił inaczej. Często nawet zdarza się tak nie dlatego, że klient chce zrobić komuś na złość, ale dlatego, że faktycznie mógł zapomnieć.

W mojej praktyce nikt nigdy nie odmówił używania dyktafonu – wręcz przeciwnie, wszyscy się zgadzali. Najważniejsze to prawidłowo uzasadnić użycie tego narzędzia — zapewnij klienta, że nie nagrywasz go, aby wykorzystać coś przeciwko niemu w sądzie, ale po to, aby niczego nie przeoczyć i szybciej i lepiej opracować wymagania.

Nie musisz pytać za każdym razem: “Czy mogę Pana/Panią nagrać?” Zazwyczaj pracuje się w firmie przez dość długi czas i wystarczy powiedzieć tylko raz: “Za Państwa zgodą pozwolę sobie nagrać naszą rozmowę, żeby nic mi nie umknęło i żeby lepiej można było opracować wymagania”.

2. Utrzymanie przyszłego wdrożenia w tajemnicy przed zespołem technicznym

Utrzymanie przyszłego wdrożenia w tajemnicy przed zespołem technicznym

Zgrywaj eksperta we wszystkich niuansach technicznych i wyznaczaj zespołowi dowolne cele – oni je zrealizują. Jeśli zawiodą, trzeba zmienić zespół.

Jeśli chcesz być autorytetem dla swojego zespołu i ułatwiać mu życie, to zawsze przed zatwierdzeniem wymagań biznesowych z klientem, uzyskaj od zespołu potwierdzenie, czy cele i sposoby realizacji są możliwe do wdrożenie i jakich zasobów będą wymagały. Dopiero wtedy można udać się do interesariusza i przedstawić realistyczny kosztorys.

Jeśli słyszysz od klienta jawne bzdury (zbuduj rakietę za $10) i rozumiesz, że jest to niemożliwe do wdrożenia, powiedz o tym na etapie dyskusji.

Kiedy nie jesteś pewien, czy żądanie jest wykonalne czy nie, ważne jest, aby wyjaśnić, że musisz omówić te szczegóły z liderem technicznym lub innym menedżerem, który jest odpowiedzialny za rozwój produktu.

Po potwierdzeniu z technical leadem, że da się to zrobić, możesz odpowiedzieć klientowi w jakiej formie i w jakim budżecie jesteś skłonny rozwijać daną funkcjonalność.

3. Kto potrzebuje optymalizacji procesu interakcji z zespołem i klientem. Wieje nudą!

Kto potrzebuje optymalizacji procesu interakcji z zespołem i klientem

Wszystko, co łączy zespół i klienta to ty, ich zaufany kolega analityk biznesowy! Jednak oszczędzaj pochwał, bo jeśli wszystkich za bardzo chwalisz, mogą oni pomyśleć, że jesteś tylko dodatkową osobą, z którą trzeba sobie radzić przy projekcie i wchodzić w zbędne interakcje.

Interakcja z zespołem i klientem powinna być stała i ciągła. Jeśli klient jest wewnętrzny i jest dodany do twojego trackera zadań, możesz udostępnić mu funkcję, która stawia approve przy kolejnych wymaganiach.

W mojej praktyce przy jednym z projektów używaliśmy jiry i mieliśmy klienta, który chciał, żeby żaden ticket nie przeszedł bez jego zgody. Na tablicy umieściliśmy ticket, że status zadania to “need username approve”. Lista tych ticketów była wysyłana do klienta codziennie rano, a on przeglądał ją i albo zatwierdzał, albo odrzucał poszczególne punkty. Jest to dość skuteczny mechanizm i dobrze się u nas sprawdził.

Inną możliwą opcją jest komentarz z zatwierdzeniem od klientów w dokumencie z wymaganiami.

Mnie osobiście wygodnie pracuje się nad wymaganiami w google docs, komuś może bardziej odpowiadać Confluence lub Quip, to kwestia gustu. Jeśli zdecydujesz się na pracę z google docs – po prostu daj wszystkim zainteresowanym dostęp do komentowania, a gdy klientowi wszystko się spodoba, może napisać w tytule dokumentu, że zatwierdza wymagania. To zwykle wystarcza, aby wszystko działało sprawnie.

Jeśli, powiedzmy, korzystasz z dokumentacji papierowej, co też czasem ma miejsce, to potwierdzeniem może być klasyczny podpis na papierze. Osoba podpisuje się pod tym, co zamówiła.

Ważne jest, aby zebrać pytania od zespołu technicznego i odpowiedzieć na nie

Jedną z opcji mechanizmu komunikacji jest dostęp do komentarzy do opracowywanego dokumentu. Może to być również jakiś rodzaj regulowanego spotkania, gdzie spotykacie się raz w tygodniu, aby przejść przez wymagania, które zamierzacie zatwierdzić.

Podczas opracowywania wymagań zalecałbym, abyś dał członkom zespołu (a przynajmniej leadowi) dostęp do komentarzy, aby mogli od razu zadawać pytania o to, jak opisujesz niektóre rzeczy, które mogą nie być w pełni zrozumiałe. Odpowiadając na pytania mogą, po pierwsze, przedstawić jakieś propozycje, które są lepsze od tych, które opisujesz, albo powiedzieć ci, czy coś jest możliwe do wdrożenia, czy nie – krótko mówiąc, dostarczyć informacji, które dalej przekażesz klientowi.

Ale z reguły spotkania zabierają trochę czasu – to środki i pieniądze, natomiast jedna osoba może przejrzeć dokument przez 15-20 minut i od razu wycinać rażące błędy lub możliwość/niemożliwość realizacji, co jak wynika z mojej praktyki, jest dość skuteczne.

Zbieraj informacje zwrotne od zespołu na temat kanałów i mechanizmów komunikacji

Słuchaj sugestii i akceptuj to, co może poprawić komunikację, przyspieszyć proces lub zmniejszyć koszty (usunięcie dodatkowego kroku z flow, dodanie lub usunięcie spotkania). Ludzie są rzeczywiście zwykle bardzo chętni do dawania pewnych sugestii i lepiej reagują w przyszłości, jeśli słuchasz, akceptujesz i stosujesz te sugestie.

4. Analizowanie rynku tylko na etapie inicjowania projektu

Analizowanie rynku tylko na etapie inicjowania projektu

Jeśli stale analizujesz rynek i konkurencję – to kiedy masz pracować?

Częstym błędem popełnianym przez analityków biznesowych jest wykonywanie  analizy konkurencji w projektach długoterminowych tylko raz, na etapie inicjacji. Ważne jest, aby analizować konkurencję przynajmniej raz na jakiś czas. Wszystko zależy od dziedziny, w której pracujesz. Jeśli jest to jakiś mobile gamedev, to analiza konkurencji jest potrzebna niemal cały czas. Jeśli opracowujesz instrumenty finansowe lub jakieś inne produkty w długim czasie – musisz przeprowadzić taką analizę przynajmniej raz na pół roku.

Kiedy goście, z którymi pracowałem, chcieli rozwijać jeden produkt w 2018 roku, zrobiliśmy analizę konkurencji i zdaliśmy sobie sprawę, że na rynku brakuje pewnych funkcji, a my zawojujemy rynek, jeśli wejdziemy z tymi funkcjami. Potem rozproszyło nas rozwijanie innych produktów, a osiem miesięcy później postanowiliśmy wrócić do rozwijania tego produktu. Wszystkim dopisywała myśl, że rok temu nikt tego nie miał, teraz trafimy na rynek i będziemy bogaci.

Podjąłem inicjatywę i postanowiłem ponownie przeprowadzić analizę konkurencji i okazało się, że wszystkie funkcje, o których mówiliśmy rok temu, zostały już wdrożone przez dwóch konkurentów w takiej czy innej formie. Gdybym nie zrobił analizy, kilka miesięcy rozwoju poszłoby na marne.

To, czy BA powinien robić analizę konkurencji, zależy od tego, jaka jest rola analityków biznesowych w danym projekcie lub produkcie. Jeśli klient jest dobry w swojej dziedzinie i cały czas trzyma rękę na pulsie, to analityk nie musi wykonywać podwójnej pracy. A jeśli klient, powiedzmy, czegoś chce, ale jednocześnie nie jest na bieżąco z rynkiem, to analityk powinien wyróżnić głównych graczy i od czasu do czasu przynajmniej zajrzeć na ich stronę internetową, kanał informacyjny i śledzić treści.

Narzędzia i zasoby do analizy są bardzo proste – konkurencja powie ci wszystko. Wejdź na ich bloga i zobacz oś czasu tego, co rozwinęli i kiedy. 

Jak nie opracowywać wymagań

5. Ignorowanie szybkości na rzecz jakości

Ignorowanie szybkości na rzecz jakości

Niech żyje perfekcjonizm! Dopracuj do perfekcji wymagania każdego zapytania, nawet jeśli zajmie ci to 20 lat!

Czasami „młodzi” analitycy starają się skrupulatnie opracować wymagania we wszystkich niewłaściwych miejscach i nie biorą pod uwagę, że rynek zmienia się co minutę.

Oto przykład z mojej własnej praktyki, gdzie zespół spędził bardzo długi czas na opracowaniu dość standardowej funkcjonalności rejestracji logowania. Wymagania ciągnęły się przez 20 stron, opisywały niemal wszystko, co można było opisać, choć tak naprawdę należało skupić się na sednie projektu i po prostu wdrożyć tę funkcjonalność jako standardową i dopracować ją podczas kolejnych iteracji. W takim momencie należy ocenić ilość poświęconego czasu i znaczenie jakości przy opracowywaniu wymagań, podobnie jak w przypadku rozwoju produktu.

6. Niewyznaczanie priorytetów w backlogu

Niewyznaczanie priorytetów w backlogu

Musisz czuć w sercu, które zadanie jest najważniejsze.

Kiedy backlog jest skompilowany, ważne jest, aby zdać sobie sprawę, że nie będzie służył tylko przy jednej iteracji, ponieważ priorytety mogą się zmienić, lub cecha może stać się niepotrzebna, albo zespół może sobie nie poradzić.

Klient będzie bardzo niezadowolony, bo najdroższą rzeczą w IT dla klienta jest koszt zespołu deweloperskiego, więc lepiej postaraj się, żeby backlog był lepszy, niż na 1 sprint.

Są sytuacje, w których bardzo trudno jest nadać priorytety backlogowi.

Pracowałem nad produktem i natknąłem się na sytuację, w której klient mówił, że musimy pilnie wdrożyć jedną rzecz. Support mówił, że nie możemy żyć bez czegoś innego. Sprzedawca krzyczał: “Odłóż to wszystko na później, musimy sprzedać klientowi coś trzeciego!”. Właściciel firmy mówił: “To wszystko bzdury, dajcie mi to! Chcę, żeby było, jak u konkurencji”.

Siedzisz i zdajesz sobie sprawę, że masz dwumiesięczny backlog, a wszystkie funkcje mają maksymalny priorytet. W takich przypadkach istnieje bardzo przydatna praktyka, którą zapożyczyłem ze scaled agile framework – WSJF.

WSJF (Weighted Shortest Job First) to system, który pozwala punktować zadania pod kątem wielu czynników i zebrać numerowaną listę, która zaczyna się od najłatwiejszych do realizacji, ale też najbardziej wartościowych z biznesowego punktu widzenia.

Wzór WSJF = Cost of Delay / Job size

Wzór WSJF = Cost of Delay / Job size, gdzie

Cost of Delay = (Business Value + Time Criticality + Risk Reduction lub Opportunity Enablement).

A teraz wszystko po kolei:

  • Business Value (wartość biznesowa) — jak bardzo dana funkcja będzie przydatna dla biznesu i klienta (im wyższa wartość, tym lepiej).
  • Time Criticality (krytyczność czasowa) — czy zadanie powinno być wykonane natychmiast, czy może poczekać? Ważne jest na przykład wyprzedzenie konkurenta (im wyższa wartość, tym lepiej).
  • Risk Reduction and/or Opportunity Enablement (czynnik ryzyka (lub możliwości)) — czy dana cecha zmniejsza ryzyko, czy może otwiera możliwości na nowych rynkach? (im wyższa wartość, tym lepiej).
  • Job duration / size (złożoność pracy) — techniczna złożoność wdrożenia funkcji (im niższa wartość, tym lepiej).

Jeśli firma i zespół mają czas na optymalizację przepływu pracy, idealnym sposobem na zastosowanie WSJF byłoby ogólne spotkanie z zespołem programistów i przedstawicielami klienta. Niech każda ze stron oceni zadania w story points, w wyniku czego powstanie wspólna tabela, składająca się z kolumn: Nazwa feature/inicjatywy, Business Value (im wyższa wartość, tym lepiej), Time Criticality (im wyższa wartość, tym lepiej), Risk Reduction and/or Opportunity Enablement (im wyższa wartość, tym lepiej), Job duration / size (im niższa wartość, tym lepiej).

Po ocenie każdej z cech dla wszystkich parametrów stanie się jasne, które z zadań należy rozpocząć jutro, a które mogą poczekać dłużej niż miesiąc.

Jak nie załatwiać formalności

7. Nieaktualizowanie dokumentacji

Nieaktualizowanie dokumentacji

Każdy lubi szukać 200 różnic między dokumentacją projektu a jego realizacją.

Powiem teraz, jakie mogą być konsekwencje nieaktualizowania dokumentacji.

Spotkałem się z sytuacją, w której organizowałem przejście z zespołu zdalnego do wewnętrznego. Projekt był dość złożony, rozwijany na bardzo dynamicznym rynku i dlatego dokumentacja była nieaktualna.

Okazało się, że wiele punktów w dokumentacji nie zostało zaktualizowanych, ponieważ w zespole nie było analityka biznesowego. Project Manager po prostu opisał, jak będzie wyglądał produkt na etapie inicjacji i niczego dalej nie aktualizował.

Kiedy mój zespół zajął się projektem, istniała ogromna różnica między tym, co było napisane w dokumentacji, a tym, jak produkt faktycznie działał. Było to bardzo mylące dla wszystkich zaangażowanych.

Utrzymanie spójności dokumentacji nie jest takie trudne: wystarczy po każdym sprincie wprowadzić zmiany. Niektóre rzeczy w dokumentacji i tak będą niedopracowane: czegoś nie dało się zrobić, zmieniono jakąś funkcjonalność, ale podstawowa struktura powinna odpowiadać rzeczywistości.

8. Pozostawienie narzędzi i technik analizy biznesowej teoretykom

Pozostawienie narzędzi i technik analizy biznesowej teoretykom

Po co tracić czas na teorię, skoro praktyka jest inna! Ucz się na bieżąco i nie zawracaj sobie głowy zbędnymi informacjami.

Dla dobrego analityka biznesowego ważne jest korzystanie z diagramów User Story, Use Case i UML (diagram state machine, entity relationship lub activity diagram), ponieważ:

  •  pozwalają na łatwe i zrozumiałe opisanie bardziej złożonych rzeczy;
  •  pomagają opisać rzeczy, których w ogóle nie da się opisać słowami;
  • pozwalają na wizualizację wymagań, ponieważ znacznie łatwiej jest odebrać wizualizację systemu, niż jego tekstowy opis.

Na samym początku mojej kariery dostałem zadanie opisania jednej bardzo skomplikowanej funkcji i musiałem ją opisać w bardzo krótkim czasie, żeby nie mieć kłopotów.

Nie miałem tych narzędzi, o których wiem teraz, więc okazuje się, że miałem jakieś zadania, ale brakowało mi w arsenale środków, żeby te zadania rozwiązać. Siedziałem i myślałem o tym, jak mogę opisać wymagania w sposób, który ma sens. Pamiętam, jak siedziałem w pracy do świtu, ramię w ramię z energetykami. W końcu udało mi się user story, opis User flow i coś w rodzaju Use Case, choć nie znałem wtedy żadnego z tych narzędzi. Z punktu widzenia wymagań byłem nowicjuszem, więc wymyśliłem dla siebie taką skrzywioną wersję w/w narzędzi.

Kiedy przestudiowałem narzędzia i udoskonaliłem swoje umiejętności, zrozumiałem, że mogę poświęcić na to godziny, a nie noce, więc od tamtego czasu radzę wszystkim poszerzać swój zestaw narzędzi. Niektórych rzeczy możesz nawet nie używać, ale jeśli napotkasz problem, będziesz miał szeroki arsenał, który pomoże ci go rozwiązać. To faktycznie bardzo przyspiesza pracę.

Jeśli chodzi o narzędzia do wizualizacji, to osobiście pracowałem z:

  • Balsamiq (dla wireframe i prostych mockupów);
  • Lucidchart (dla diagramów);
  • Invision Studio (do złożonych mockupów i dynamicznych prototypów).

W rzeczywistości narzędzi jest o wiele więcej, ale na początkowym etapie te trzy wystarczą ci w zupełności.

9. Zapomnij o strukturze dokumentacji

Zapomnij o strukturze dokumentacji

Jesteś artystą, taka jest twoja wizja i nie masz czasu na upiększanie czcionek i nagłówków. Liczy się istota, a nie forma!

Jeśli chcesz przyspieszyć proces rozwoju, twoja dokumentacja powinna być nie tylko przejrzysta, ale także łatwa w nawigacji i przyjemna w czytaniu. Niby drobiazg, ale po dłuższej pracy z dokumentacją i obejrzeniu dokumentu mojego stażysty, zdałem sobie sprawę, że ten punkt powinien znaleźć się w poradach.

Pod względem treści opis był poprawny, ale pod względem formatowania był bolesny do oglądania i trudny w nawigacji. Nie chodzi o perfekcjonizm. Chodzi o to, że różne czcionki i różne rozmiary nagłówków są mylące, porządek dokumentacji jest zaburzony i cierpi na tym możliwość logicznego analizowania wymagań.

Ważne:

  • Opracuj wszystkie szablony i standardy dokumentów z wymaganiami w ramach projektu, nad którym będziesz pracował;
  • zrób listę dokumentów, które są oczekiwane w tym projekcie;
  • upewnij się, że wszyscy zaangażowani w proces mają świadomość, jakie dokumenty znajdują się w projekcie, na jakich etapach są opracowywane i na jakie pytania odpowiadają.

Na przykład, być może Ty i klient zdecydowaliście, że najpierw zrobicie dokument Product Vision, potem Product Requirement Document, a dopiero po nim specyfikację. Uświadamiasz to zespołowi i jego członkowie oczekują, że zobaczą wizję biznesową, PRD i szczegółowe specyfikacje, a nie byle jakie dokumenty. Oczekują, że nic innego do nich nie trafi i mają do tego pełne prawo.

10. Pozostawienie zespołu bez dostępu do dokumentacji

Pozostawienie zespołu bez dostępu do dokumentacji

Nie mogą źle wdrażać tego, o czym nie mają pojęcia!

Upewnij się, że wszyscy uczestnicy mają niezbędny dostęp i uprawnienia oraz że są powiadamiani o ważnych zmianach w odpowiednim czasie.

Pracując z dokumentami Google, poleciłbym od razu podczas tworzenia doku dać dostęp do komentowania przez link w firmie (czyli tylko na pocztę firmową).

Jeśli masz dobrą komunikację z klientem, to wprowadzasz zmiany i informujesz go poprzez osobisty kanał komunikacji, np. telefonicznie lub przez komunikator: „Wprowadziłem zmiany w wymaganiach i potrzebuję, żebyś je zatwierdził”.

Ty jako autor dokumentu wymagań, powinieneś być również moderatorem tego procesu. Pytania, na które już udzielono odpowiedzi, komentarze, które nie mają już znaczenia – usuń je! Pozostaną one w historii komentarzy, a to, co było w nich wartościowe, zostanie wprowadzone do treści dokumentu.

11. Zapomnij o dobrym pomyśle, który przyszedł ci do głowy

Zapomnij o dobrym pomyśle, który przyszedł ci do głowy

Wszyscy pamiętacie, że nie chcecie przeciążać dokumentacji!

Kiedy np. opracowujesz dokument na kolejną iterację i przychodzi Ci do głowy pomysł, którego realizacja teraz na pewno nie będzie częścią wymagań, ale zdajesz sobie sprawę, że dobrze byłoby go zrealizować w przyszłości – udokumentuj ten pomysł w ramach dokumentacji projektowej. Często o takich rzeczach się zapomina, a kilka miesięcy później przypominasz sobie, że chciałeś jeszcze coś zrobić, ale konkurencja już cię ubiegła i wdrożenie funkcji nie ma już sensu. Warto więc wprowadzić blok z sugestiami i pomysłami zespołu, aby produkt mógł się lepiej rozwijać.

I AM BA

Wnioski

Aby zminimalizować ryzyko niepowodzenia, wyciągnij wnioski z mojego doświadczenia:

  1. Uzgodnij wymagania z klientem.
  2. Omów przyszłe wdrożenie z zespołem technicznym podczas opracowywania wymagań.
  3. Zoptymalizuj proces interakcji z zespołem i klientem.
  4. Przeanalizuj rynek i konkurentów.
  5. Zachowaj równowagę między prędkością a jakością.
  6. Ustal priorytety w backlogu.
  7. Aktualizuj dokumentację.
  8. Wykorzystaj narzędzia i techniki analityki biznesowej.
  9. Przestrzegaj struktury dokumentacji.
  10. Upewnij się, że wszyscy uczestnicy mają niezbędny dostęp i otrzymują terminowe i istotne powiadomienia o ważnych zmianach.
  11. Wprowadź blok sugestii i pomysłów.

Lubik Kisluk

Szef działu analiz marketingowych w Autodoc AG. Wcześniej pracował jako Lens Production Manager w Snap Inc., był COO w Robosoft industries, kierował działem BA w Adtelligent. Aktywnie zaangażowany w realizację procesów biznesowych, kontrolę funkcjonowania firmy, bezpośredni nadzór nad działem BA. Potrafi pracować z wymaganiami na wszystkich poziomach.