Do tego wpisu zainspirował mnie jeden z ostatnich artykułów Harvard Business Review. Mówił o tym, że żyjesz mrzonkami, bo nie ma pracy idealnej. Jeśli chcesz zdobyć lub zmienić zajęcie, dowiedz się też, jakie są jego minusy. Czy analiza biznesowa ma minusy? Zmierz się z najczarniejszymi scenariuszami i odpowiedz sobie na pytanie, czy na pewno nadal chcesz zostać analitykiem?

*Uwaga* tekst zawiera lokowanie humoru hiperbolicznego

1. A czym Ty się właściwie zajmujesz?

Przygotuj sobie dobrą odpowiedź, bo będziesz pytany o to często i z prawdziwym zafrasowaniem. Będzie pytać nie tylko mama, ciotka i babcia, ale też Twój kolega z firmy, zespołu i zza biurka! Ludzie nie znają jeszcze w wielu miejscach takiego zjawiska jak analityk. Przecież programy piszą programiści! Nawet, jeśli ktoś spędził z Tobą w budynku czy open space kilka miesięcy, nadal może tego nie kumać. Przy którymśsetnym przytoczeniu tej samej historii, opadają Ci ręce i zaczynasz się zastanawiać, czy na pewno pracujecie w tej samej firmie, a może wrobiono Cię w wirtualne zadania, żeby zachować parytet zatrudniając na siłę 10% kobiet .

2. Nie ma Cię w domu

Pranie rośnie, kwiaty więdną, dzieci płaczą. Wiele spraw „stacjonarnych” przekładasz na inne dni i tygodnie. Delegacje wypadają w Twoje urodziny, rocznice i dni, kiedy znajomi świetnie bawią się bez Ciebie. A Ty jedziesz, lecisz, siedzisz, kwitniesz w bezproduktywnym czasie w ciemnym samochodzie albo w oczekiwaniu na przesiadkę. Jasne, że można zwiedzać, zażywać hotelowego życia, a nawet zarobić! Delegacja w Polsce zostawi Ci w kieszeni 30 zł dziennie! O ile nie wydasz 2 razy więcej na McZestaw, przydrożną kolację i 3 kawy na stacji.

3. Wychodzisz na głąba

Wdrożenie w projekt pochłania i fascynuje. Nowi ludzie, branże, firmy. Jednak kiedy bombardują Cię pytaniami, większość z nich jest jak przekrojowa, szczegółowa lub podchwytliwa, że po raz setny mówisz: „dowiem się”, „sprawdzę” albo brniesz w temat ćwicząc poker face. Możesz dzielnie podejmować dyskusję i próbować dawać odpowiedzi, ale po jakimś czasie i tak stwierdzasz, że nie wziąłeś pod uwagę 7 szalenie ważnych powiązanych tematów! Nie oszukuj się. Nie jesteś partnerem do rozmów i przez jakiś czas nie będziesz. Będziesz jak huba drzewna pasożytująca na innych i nie będziesz w stanie poprowadzić samodzielnie tematu, dopóki nie minie długi czas wdrożenia. Jeśli od samego początku masz do współpracy zespół, który na Ciebie bardzo liczy, to, o matko, współczuję (i nie wiem komu bardziej – im czy Tobie).

4. Klienci nie mają dla Ciebie czasu

Klienci bywają różni. Najczęściej są zajęci. Nie żyją projektem, którym żyjesz Ty i Twój zespół. Uginają się pod tyloma sprawami, że wpadną na spotkanie z Tobą przypadkiem, z zadyszką, bez materiałów i odpowiedzi. Czekasz potem długie dni usychając przy milczącym telefonie i skrzynce mailowej. W końcu wpadasz w furię i przypominasz się z uprzejmą prośbą o przesłanie odpowiedzi. A potem patrzysz w prosto w oczy podirytowanych programistów: „Odpowiem Ci w piątek”, a myślisz sobie „tylko nie wiem w który”.

5. Specyfikacji nikt nie czyta

Szmata. To najbardziej wyrafinowane określenie specyfikacji wymagań, jakie słyszałam. Jedni mówią na głos, inni tylko w myślach, a trzeci pokazują swoją postawą. Developerzy nie urodzili się z głęboką tęsknotą do dobrej długiej biznesowo-projektowej lektury. Lepiej wykształcili zdolność generowania kodu z przetwarzania w locie streamingu słów, grafiki, zdjęć bazgrołów z tablicy i krótkich zdań w formacie „na komunikator” (niektórzy z etykietą „tylko nie podchodź do mnie rozmawiać!”). Głęboko mnie zastanawia jak to możliwe, że te systemy jednak powstają i jakoś działają, mimo, że programista nie zagłębił się w meandry zawiłej logiki biznesowej, którą znalazłby tylko w specyfikacji. Niektórym się nie chce. Inni mówią, że wymagania i projekt są oczywiste i nie potrzebują specyfikacji. Jeszcze inni patrząc na model dziedziny dostają „gula” i zaczynają monolog nie do przerwania, mimo wielu prób, o tym, że tak się klas w kodzie (albo bazie danych!) nie projektuje!!!

6. Programiści Cię nie szanują

Nie kumasz Laravela, fasad, gdzie co jest upchnięte w bazie, na którym z 50 środowisk znajdziesz potrzebne dane i w którym z 50 branchy masz szukać potrzebnych plików. Nie obczajasz jak skonfigurować tworzone przez nich od 5 lat rozwiązania i zadajesz jakieś dziwne pytania na temat ich integracji z innymi systemami. Po prostu jesteś na niższym levelu technologicznej świadomości. Niedokształcony. Nieogarnięty. Niezupdateowany. Nawet, jeśli kiedyś w sumie programowałeś i nawet skończyłeś informatykę. Jak masz szczęście, to wzbudzisz litość i coś Ci wyjaśnią albo jesteś dziewczyną (i może to przeważy nad brakiem technologicznego szacunku) albo mimo wszystko ujrzą w Tobie fajnego człowieka.

7. Wszystko robisz za długo

Siedzisz bez ruchu kolejną godzinę? Ciekawe czy trącą Cię z pytaniem czy żyjesz, czy zaczną drukować wypowiedzenie umowy. Tak, czasem po prostu potrzebujesz coś przeczytać. Tylko czemu tak długo? Czemu 10 stron dokumentu piszesz 2 tygodnie??? Czemu na analizę chcesz tyle godzin? Zwariowałeś!? Czemu na odpowiedź na pytanie trzeba czekać tyle czasu? Czemu zamiast zamknąć zadanie, Ty jeszcze je rozgrzebujesz i generujesz 3 następne? A w ogóle to czemu tak długo wdrażasz się w ten temat? Czemu tyle czasu przygotowujesz się do spotkania? Po co w ogóle przygotowywać się na spotkanie? Jakim cudem spędziłeś nad tym 12 godzin?! Czemu ten projekt tak długo trwa?!

8.Wkurzasz kierowników

No jasne, że tak. Miał mały zakres za dużą kasę, a potem przyszedłeś Ty, paskudo. Zakres się zmienia i żyć się nie da. Drążysz, doktoryzujesz się nad tym, co trzeba po prostu wziąć i zrobić. Harmonogram puchnie przez Twoje analityczne roboty – głupoty. Po tych rozmowach z Tobą klienci jeszcze wydłużają czas zastanawiając się nad problemami, których wcześniej było. Czasem też się irytują, że nie idzie tak szybko, jak miało, albo nie w tę stronę, co im obiecywano. Po wyprodukowaniu specyfikacji kierownik chciałby Cię już przerzucić do innego projektu, a Ty dalej rejestrujesz czas pracy w zadaniach na konsultacje z programistami i testerami.

9. Wnerwiasz testerów

Bo gdyby w specyfikacji to było lepiej napisane, to by wiedzieli jak to porządnie przetestować. A, że piszesz tak, że się tego nie da zrozumieć czy znaleźć na dziesiątkach stron niepotrzebnych informacji, albo nie ma Cię pod ręką, kiedy akurat dyskutuje z rozjuszonym przez zgłoszony błąd programistą… Nie przemyślałeś wymagania, nie opisałeś wszystkich przypadków. Tester zrobiłby Twoją robotę 100 razy lepiej.

10. Klienci są nieusatysfakcjonowani

Miało być tak pięknie a brzydko się skończyło. Koniec (etapu) projektu to czas zbierania batów. Przestaje być miło. Zamiast roztaczanej wizji spełnionych marzeń, klient widzi rzeczywistość. Nawet, jeśli widział to już 55 razy i testował 5,5 razu. Po wdrożeniu wychodzą nowe wymagania, problemy, wprowadzane dane a nawet nowi interesariusze. Rozwiązanie klientowi się nie podoba, działa źle a w zasadzie to wcale. Zamiast pomocy, zrzuciłeś mu na głowę problem. Całe stado problemów, których by nie miał, gdyby nie zaczął tego projektu. A kogo winić? Analityka.

11. Wszystko Twoja wina

Co tam, że projekt tworzy cały zespół, a za jego pomyślność odpowiedzialność ponosi kierownik projektu. Co tam, że klient nie przemyślał inwestycji ani odpowiedzi na kluczowe pytania. Co tam, że management podejmował decyzje „korzystne inaczej”. Wina analityka. Że się klientowi coś nie podoba, że projekt trwa za długo, programiści mają algorytmiczne wyzwania, pojawia się szargająca nerwy liczba wątpliwości, biurko nie wysprzątane, kawa zimna, a po kanapkę daleko. Wina analityka.

12. Nie wiadomo czy robisz coś pożytecznego

Właściwie to siedzisz sobie przy tym biureczku, chodzisz na te spotkania, piszesz te dokumenty. Ale co z tego wynika? Czy świat bez Ciebie nie wyglądałby tak samo? Pewnie tak, bo ze spotkań przecież nic nie wynika, specyfikacji nikt nie czyta, a Twoje miejsce można by lepiej zagospodarować dodatkowym programistą.

13. Nie opłacasz się firmie

Mało kto mierzy faktyczny zwrot z inwestycji czy analizuje przyczyny źródłowe pojawiających się w projektach problemów. Jednak po nitce do kłębka, odczucia związane z wszystkimi poprzednimi podpunktami sprawiają, że ktoś w końcu się zorientuje, że z konta ubywa co miesiąc na Twoją wypłatę + na 2 kiwi w owocowe piątki. A skoro za Twoją cenę można mieć już pół programisty…

 

Tak naprawdę nie jest aż tak źle. Gorsze chwile przeplatają się z chwilami chwały, radości i satysfakcji z wykonywania tego zawodu. Pracujesz zazwyczaj z sympatycznymi, zaangażowanymi i mądrymi ludźmi. Potraktuj to jako listę czyhających potencjalnych kataklizmów, przygotuj się na taką ewentualność i wyrusz w drogę do analizy biznesowej z pełną świadomością.

Hania Tomaszewska
8 lat temu odkryłam, że analiza biznesowa to genialna rzecz. Od tamtej chwili zbieram doświadczenia w różnych firmach, branżach i projektach. Pracuję na etacie, prowadzę bloga, tworzę kursy, prowadzę szkolenia i konsultacje. Pomagam analitykom doskonalić warsztat pracy i rozwijać się, managerom układać procesy i rozwijać pracowników oraz przedsiębiorcom, aby rozwiązania IT wspierały ich działalność.

14 KOMENTARZE

  1. Bardzo dołujący artykuł (nie, to nie jest wina analityka ;)
    Jak Twoim zdaniem można się przygotować na poszczególne trudności?

  2. To teraz czas na 7* powodów, dla których warto być analitykiem :)

    *- bo szczęśliwa liczba, jakby kto pytał ^^

  3. Przeczytałam i niestety nie zgadzam się z żadnym z punktów. Tez bym sie zastanawiała dlaczego ktos pisze 2 strony tak długo, przeciez jest etap analizy, pisanie jest jedynie dokumentowaniem tego etapu. Analitycy biznesowi maja o tyle trudniej, poniewaz chcąc opisywać rozwiazania techniczne w swoich dokumentach o pomoc muszą poprosic programistów. Bo faktycznie nie znaja branchy, releasow, tabel bazodanowych a gdzie mowic o jakimkolwiek projektowaniu. Analitycy systemowi czy nawet inzynierowie wymagan mają łatwiej bo dla nich opisywanie struktur bazodanowych ktore nalezy utworzyć to codzienność. Nie jest winą analityka brak zrozumienia jego roli w zespole, lecz firmy ktora nie przygotowala zespolu na ta rolę. Jeśli zdarzaja sie sytuacje kiedy jako analityk slyszysz ze twoja dokumentacja jest nieprzydatna moze warto zapytać jaka dokumentacja jest oczekiwana przez zespół. I nie, odpowiedzią właściwą nie jest :”zadna”. Bo potrzeba wiele czasu, bardzo dobrej dokumentacji ktora jest pomocna dla zespolu programistow, testerow ktorzy maja opisane przypadki uzycia na podstawie ktorych przygotowuja scenariusze testowe. A programisci maja dodatkowo wrzucone przyklady obrazujace opisaną wcześniej logikę. Potrzeba czasu, wytrwałości, schowania dumy do kieszeni aby zespol mogl dojrzec do roli analityka. Uwazam ze posiadanie w zespole analityka dla samego stanowiska, ktory: nie zna dziedziny i nie jest w stanie jej ogarnac, przygotowuje dokumentacje ktora jest opisem slowno muzycznym nic nie wnoszacym do projektu a po prostu jest, bo opisuje warstwe biznesową o reszte niech sie martwią pozostali, nie jest wsparciem dla zespołu, to marnotrawienie swojego i innych czasu. Ja mam doświadczenia zupelnie inne ale kosztowalo mnie to czasu i wiele bardzo dobrych dokumentow ktore pokazaly ze jestem nieodlacznym czlonkiem zespolu projektowego. Moi programisci bez analizy, projektow okien, warstwy bazodanowej ani rusz ;)

    No chyba ze ten caly wpis mamy traktowac jako humorystyczne spojrzenie na incydentalne zdarzenia ;)

    • Wiadomo, że to świetny zawód. Inaczej wszyscy już byśmy się przekwalifikowali (poza masochistami :).
      Każda sprawa, czy to marzenie zawodowe czy każde inne, ma dwie strony – jasną i ciemną. Można marzyć o podróżach po świecie, własnej firmie, związku, dzieciach czy konkretnym zawodzie, który sprawi, że będziemy w końcu spełnieni. Wszystko ma swoje minusy. Nie znaczy to, że mamy tego nie robić. Ale zamiast wierzyć w zawsze cudowną rzeczywistość, warto wiedzieć wcześniej z czym to się wiąże.

      Np. założenie własnej firmy wymaga wielu poświęceń. Kokosów nie zarabia się od razu. Możliwe, że przez długi czas zarabia się znacznie mniej niż wartość posiadanych kompetencji i znajomi w korporacjach. Możliwe, że przez wiele miesięcy nie zarabia się nic. Wymaga to poświęcania mnóstwa czasu, żeby stworzyć produkty, usługi, ustalić od początku procesy, zebrać zespół. Wykonuje się też wiele zadań administracyjno – sprzedażowo- nie związanych z tym, co kochasz najbardziej. Może dla kogoś to nie są duże minusy. Może u kogoś część z tych rzeczy będzie marginalna albo nie wystąpi w ogóle. Warto jednak wiedzieć, że istnieje takie ryzyko, bo występuje u wielu osób. Wtedy można podjąć decyzję bardziej dojrzałą i odpowiedzialną – opartą na znajomości nie tylko cudownych stron, ale też potencjalnych wad, które będziemy monitorować, zapobiegać albo stawiać czoła.

  4. Co do nomenklatury, to bywa różnie. Każda firma może nazwać stanowisko inaczej. Zawsze nazywałam się wg firmy analitykiem biznesowym, a robiłam różne rzeczy – od celów, strategii, procesów, po konfiguracje narzędzi i bazy danych. Znaczna większość osób, które brały udział w badaniu kompetencji (ponad 200 osób) czy z którymi rozmawiam nazywają się Analityk Biznesowy. Robią jednak różne rzeczy, w zależności od projektu i firmy.
    Miałam też styczność z podziałem na analityka biznesowego i analityka wymagań w jednym projekcie. Może jest za tym jakaś myśl, ale nie widzę póki co tych korzyści. Jeśli mam opisywać odpowiedzialnie wymagania jako analityk wymagań, to ciężko mi to robić mając informacje z drugiej ręki od analityka biznesowego i nie mając w ogóle kontaktu z biznesem. Trochę jak głuchy telefon.

  5. Artykuł podnoszący na duchu. Sama jestem analitykiem po przekwalifikowaniu, dodatkowo jedynym w mojej firmie i jest to bardzo pocieszające że to nie tylko ja się z tym spotykam.
    :)

    • Pomyślałam, że może kogoś rozbawić, ale, że podnieść na duchu… ;) W każdym razie cieszę się, że taką miałaś myśl. Tak – nie jesteś sama ;) :) Jeśli jesteś jedynym w firmie – to przed Tobą dodatkowe wyzwania. Trzymam kciuki! :) W razie kryzysu – pisz :)

  6. Czy pisząc te punkty stosowałaś jakąś hierarchię?
    Zastanawiam się, dlaczego podróże są na drugim miejscu. Właściwie jest to jedyna rzecz, która mnie zaniepokoiła (może poza różnicami w wymaganiach firm zatrudniających na stanowisko analityka).
    Z mojej obserwacji wynika, że analityk często kontaktuje się z klientem osobiście, ale dzieje się to w godzinach pracy. Istotną kwestią jest lokalizacja klienta i firmy. Jednak, czy faktycznie analityk biznesowy tak dużo podróżuje poza godzinami pracy, czy są to okresy przejściowe, stały element pracy?

    • Nie, w takiej kolejności po prostu przyszło mi do głowy. Podróże – jak piszesz, są bardzo indywidualną sprawą. Zależą od tego, gdzie znajduje się siedziba firmy, gdzie siedziba klienta, jaki jest model współpracy, itd. Jeśli Ty pracujesz w Warszawie i klient też w Warszawie, to nie ma większego problemu. Jeśli pracujecie w innych miastach, to już gorzej, ale zawsze zostają telefony i wideokonferencje. Nie każde spotkanie musi oznaczać wyjazd. Niektórzy jeżdżą np. 1 na tydzień, inni praktycznie siedzą u klienta od poniedziałku do piątku, a jeszcze inni jeżdżą raz na miesiąc na 2 dni lub wcale. Dla niektórych też wyjazdy kończą się i tak wróceniem do domu o zwykłej porze lub tylko trochę później. W „najgorszym” razie siedzisz u klienta non-stop, ale są to raczej okresy przejściowe podczas wdrożenia, np. tydzień do 3 miesięcy. W takich przypadkach jednak jesteś informowana o tym jak to wygląda zanim się zdecydujesz na pracę czy projekt.

ZOSTAW ODPOWIEDŹ