Rozwój zawodowy i psychologia, Wydarzenia,
16 września 2020
Dzień Porażki 2020
Sukcesy są fajne, ale to przez porażki wiedzie prawdziwe życie. I droga do sukcesów. Trzeba umieć uczyć się na błędach.
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
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 .
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.
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).
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”.
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!!!
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.
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?!
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.
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.
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.
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.
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ą.
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ą.
Jako strategiczny analityk biznesowy na pograniczu zarządzania i IT zapewniam, że projekty i działania w organizacji przynoszą wartość biznesową. Dostarczam kompetencji analitycznych managerom i zarządom z Polski, Niemiec i Szwajcarii przy tworzeniu strategii oraz wdrażaniu jej w kilkuset osobowej międzynarodowej organizacji.
