Nietechniczna analityczka i toporna współpraca z nią

Jestem programistą od wielu lat i często zdarza się, że w projektach, przy których pracowałem, analiza biznesowa pozostawiała wiele do życzenia. W trzech na cztery firmy, w których byłem zatrudniony, analiza tego, co należy zrobić w konkretnym tasku przypisanym do mnie, była na beznadziejnym poziomie.
To dla mnie duży problem, ponieważ zrozumienie celu i wymagań jest fundamentalne, aby móc ruszyć dalej z pracą.

Powiedzcie mi, dlaczego programista musi pisać kod najwyższej jakości, przechodzić code review, dbać o clean code, odpowiednie nazewnictwo zmiennych i wysokie pokrycie testami, podczas gdy ludzie na nietechnicznych stanowiskach, product ownerzy, analitycy nie są w ogóle rozliczani z żadnych standardów, a ich poziom pracy rzutuje na efektywność programistów?

W moim projekcie jest analityczka osoba bez zaplecza technicznego, która weszła do branży w czasach boomu, po studiach zupełnie niezwiązanych z IT. Obecnie jest senior biznes analitykiem.
Z założenia to stanowisko powinno być pośrednikiem między klientem a programistami taka osoba zbiera wymagania i tłumaczy je na język techniczny. Niestety, w praktyce tak nie jest. W firmach, w których pracowałem, większość product ownerów lub osób kontaktujących się z klientem nie miała pojęcia o oprogramowaniu.

Irytuje mnie poziom, jaki reprezentują ci ludzie, oraz ich ignorancja w kwestii komunikacji i przekazywania wymagań programistom. Spoko, potrafią ładnie mówić po angielsku, potrafią uśmiechać się do klienta, ale według mnie nie potrafią rozmawiać z programistami i częściowo tłumaczyć te wymagania na język techniczny.

Przykład: Analityczka przygotowuje opis taska, załącza screenshot, zaznacza czerwoną ramką miejsce, gdzie klient chce zmianę, i krótko opisuje, na czym ma polegać. Czy to ma być analiza na odpowiednim poziomie?
Właśnie na tym często się kończy "analiza" tych osób. Ci ludzie nie potrafią czasem wysłać requesta do API, nie wiedzą jak zidentyfikować błąd w konsoli w przeglądarce...

Dochodzi do tego, że jestem zirytowany, bo sam muszę ustalać, co właściwie mam robić. Próbuję delikatnie sugerować, że stoję w miejscu, bo analiza jest niewystarczająca brakuje przypadków brzegowych, wymagania są niejasne. Sorry, ale wklejenia screena z opisem tu trzeba zmienić to nie jest analiza. Ta analityczka w moim zespole, nie opisuje nawet workflow jak działa system po kolei, żeby ułatwić programistom zrozumienie.

Zaczynam task i pojawiają się u mnie wątpliwości, co w przypadku X? Co w sytuacji Y? – bo te edge case’y nie zostały przeanalizowane.

Gdyby analitykiem była osoba z zapleczem technicznym i doświadczeniem w rozwoju oprogramowania, współpraca byłaby chyba łatwiejsza. Taka osoba rozumiałaby, jak wyciągnąć dane z bazy, jak sformułować zapytanie, aby uzyskać więcej informacji i przygotować kompletną analizę.

Niestety, techniczni analitycy to margines, do tej pory pracowałam z jednym technicznym analitykiem i był w miarę spoko. Rozumiem, że umiejętności miękkie i komunikacja są ważne na tym stanowisku, ale... uśmiechanie się na spotkaniach, umiejętność paplania trzy po trzy to nie są umiejętności miękkie. Prawdziwa komunikacja to umiejętność precyzyjnego przekazywania informacji i wyłuskiwania najważniejszych kwestii.

Mam wrażenie, że w korporacjach komunikacja miękka jest postrzegana jako gadatliwość, miłe usposobienie i rozwlekłe gadanie. Tacy ludzie są najgorsi we współpracy z programistą nie potrafią wydobyć kluczowych informacji, a ich "analiza" sprowadza się do wrzucenia screena z czerwoną ramką i napisania tu trzeba zmienić.

Nie wiem, kto decyduje o zatrudnianiu nietechnicznych osób na stanowiska analityków. Programiści? Widzę, że tak się dzieje osoba po studiach humanistycznych zostaje analitykiem i tworzy opisy tasków, których nie da się nawet nazwać analizą. To wprowadza chaos i nakłada dodatkową pracę na programistów.

Dlaczego zatrudnia się analityków bez podstawowej wiedzy technicznej? Jeśli ktoś nie rozumie architektury aplikacji, mikroserwisów ani podstaw działania systemów jak można z nim efektywnie współpracować?

Próbowałem poruszać ten temat w zespole, ale inni programiści nie widzą problemu. Przymilają się do tej analityczki, bo jest sympatyczną koleżanką i wychodzi na to że ja się czepiam, jestem rozczeniowy, a oni robią pracę za nią i im to nie przeszkadza.

Tak to już jest. W korpo analityk i programista to zazwyczaj inny poziom hierarchii, gdzie analityk ocenia programistów (tj. coś nie jest dowiezione, bo areczek się obija), gdzie w drugą stronę to tak nie działa. Jeśli góra ma to w d***e to nic z tym nie zrobisz

Ten problem jest generalnie widoczny wszędzie, gdy ktoś operuje na "wysokim" poziomie abstrakcji, gdzie nikt nie weryfikuje jego poczynań. Jak architekt wymyśla kocopoły to jest to problem programistów, żeby jednocześnie produkt działał i była spełniona wizja. Jak jakiś project manager nie ogarnia który zespół odpowiada za co to programista odpowiedzialny za task robi risercz. Jak analityk nie ogarnia to po prostu programista zrobi analizę.

Dlaczego zatrudnia się analityków bez podstawowej wiedzy technicznej? Jeśli ktoś nie rozumie architektury aplikacji, mikroserwisów ani podstaw działania systemów jak można z nim efektywnie współpracować?

Bez przesady. Dla mnie analityk o małym zacięciu technicznym to i tak skarb, jeśli umie rozumować w sposób logiczny i to co mówi trzyma się kupy. Najgorzej jest, gdy taki analityk nic nie wnosi do dyskusji

Próbowałem poruszać ten temat w zespole, ale inni programiści nie widzą problemu. Przymilają się do tej analityczki, bo jest sympatyczną koleżanką i wychodzi na to że ja się czepiam, jestem rozczeniowy, a oni robią pracę za nią i im to nie przeszkadza.

Granice kompetencji są różne w każdej firmie. W jednej analityk będzie ci pisał testy, gdzie twoja rola sprowadza się do kodującej małpy. W drugiej developer odpowiada za wszystko

To nie jest tylko analiza biznesowa, ale problem wszystkich "nietechnicznych" ról w IT. Pamiętam jak zaczynałem w pierwszej pracy miałem nietechniczną SM i w pewnym sprincie został 1 dzień do końca i jeden task oflagowany, który miał zająć ok. 2 dni i przez godzinę tłumaczyliśmy dlaczego nie możemy tego taska bardziej rozdrobić i nie robić go jednocześnie, albo dlaczego jeżeli we dwójkę albo trójkę będziemy patrzeć się w jeden monitor to nie będzie szybciej. xD U testerów to już chyba standard wrzucanie bugów bez numeru wersji, środowiska czy opisu ze stepami do reprodukcji, ale najgorsze - bez oczekiwanego rezultatu. Dostajesz takiego taska, nie wiesz kiedy wystąpił, gdzie i jak w ogóle powinno się zachować. Techniczni za to mają tendencję do wtrącania się do estymat, ale za to część roboty zrobią samodzielnie. Przykładowo kiedyś techniczny analityk dorzucił jeszcze skrypt do wstępnej obróbki danych, bo były nieintuicyjne zależności i próg zrozumienia dość wysoki.

Problem polega na tym, że ci ludzie - nawet jakby chcieli - to nie potrafią lepiej wykonać tej pracy. W czasie boomu właśnie wiele osób szło też w testy i analizę, bo tam kontakt z klientem jest ważny i jest to rola "nietechniczna". Kto zatrudnia analityka? Senior czy tam Lead analityk (Ok, zatrudnia HR Manager, ale interview jest z analitykiem). Sam mówisz, że nie ma ona kompetencji, a stanowisko na podstawie zasiedzenia Co każe Ci w takim wypadku oczekiwać od niej prawidłowego sprawdzenia kandydata? Jak ona oceni, że kandydat ma podobne skill'e do niej to znaczy, że jest good enough. Potem ona zmieni firmę, a osoba, którą zatrudniła zostanie kolejnym seniorem i tak w koło.

Ja nie znalazłem lepszego rozwiązania jak w przypadku testerów - edukowanie jakie są Twoje oczekiwania względem nich, a od analityków - przeciągania refinementu zadając taką ilość pytań, aby wykazać, że ich analiza jest useless. I albo ktoś wyżej na to zareaguje, albo się z tym pogodzisz, albo zmienisz firmę, tyle. Jeżeli ktoś ma lepsze techniki to chętnie się zapoznam.

no masz rację, analityk i inni bliscy zespołu menażerowie powinni być techniczni, od dawna to powtarzam
ale korpo przypisują stanowiska bez zrozumienia, stosując cargo cult
jak ja byłam analitykiem (nie analityczką, i jeśli koleżanka sama nie używa tego feminatywu to jesteś niepotrzebnie złośliwy) to szef akurat za dobrą analizę miał do mnie problemy, bo jak eksperci PiSu nie chciałam mówić tego co mi kazał tylko to co było technicznie prawdziwe,tak właśnie w korpo jest :(

c0der25 napisał(a):

Powiedzcie mi, dlaczego programista musi pisać kod najwyższej jakości, przechodzić code review, dbać o clean code, odpowiednie nazewnictwo zmiennych i wysokie pokrycie testami, podczas gdy ludzie na nietechnicznych stanowiskach, product ownerzy, analitycy nie są w ogóle rozliczani z żadnych standardów, a ich poziom pracy rzutuje na efektywność programistów?

https://www.linkedin.com/in/gosia-mitr%C4%99ga-48b94037/

Po socjologii i zarządzeniu, teraz producent wykonawczy Wiedźmina 4...
Cudowne, zasłużone przebranżowienie?
Czy po prostu etat do obsadzenia, a brudną robotę i tak wykonują inne osoby decyzyjne i ona to przyklepuje?

c0der25 napisał(a):

Powiedzcie mi, dlaczego programista musi pisać kod najwyższej jakości, przechodzić code review, dbać o clean code, odpowiednie nazewnictwo zmiennych i wysokie pokrycie testami, podczas gdy ludzie na nietechnicznych stanowiskach, product ownerzy, analitycy nie są w ogóle rozliczani z żadnych standardów, a ich poziom pracy rzutuje na efektywność programistów?

Bo sami nałożyli na siebie chomąto. Product owner będzie miał w pompce jak nazywasz zmienne i czy używasz modnych wzorców czy nie.

Ale wracając do sedna to zdarzało mi się pracować z podobnymi analitykami i pożytek był z nich marny. Raczej rola ograniczała się do bycia kronikarzem i spisywania bez składu i ładu tego co chce klient.

A w jakichś bardziej skomplikowanych technicznie projektach bez analityka systemowego ani rusz - no chyba że ktoś chce to zrzucić na deweloperów.

Założyłem sobie specjalnie konto, bo powiem Ci, że to jest globalny problem w IT jak pracuję.

Na 5 firm w których pracowałem tylko w jednej miałem ogarniętego analityka systemowego. Np. teraz pracuję z Analitykiem Systemowym zatrudnionym w trakcie hossy COVIDowej po studiach z Zarządzania w banku.... Dziewczyna nie ogarnia podstaw takich jak np. różnice {}, a [] w JSONIE, nawet nie zna podstawowej struktury JSON'a, nie wpominając o XML'u. Pracuję w banku.Tak samo metod typu GET, POST, no totalny brak elementarnej wiedzy.

Ale tak jak wspomniałeś, w hierarchii jest wyżej niż programiści. Np. ona ma spotkania raz na 2 tygodnie z wyższym managerem i raportuje nasz statusów prac i może się "skarżyć" lub "chwalić" pojedynczych developerów. Jest bardzo dobra w uprawianie polityki, branie udziału w feministycznych ruchach w korporacji i tak dalej. Nieraz jak z nią rozmawiam to mam wrażenie jakbym gadał z losową kobietą ulicy i jej coś tłumaczył.

Odpowiedzi w stylu "aha", "yhy". "Co mam wpisać w zadaniu?" "Na ile wyceniasz"

Oczywiście poskarżyć się nie mogę bo jest to żona kierownika z całkiem innego departamentu...... I ma mocne plecy.

Musiałem to z siebie wydusić bo męczę się z nią już 2 lata.

Macie kogoś kto Wam analizuje taski? Jak dotąd wszędzie miałem jednolinijkowy opis funkcjonalności która robiliśmy 2-3 miesiące i "zróbcie tak żeby było dobrze"
Cała patola typu scrum masterzy i inni niby są "wyżej", ale finansowo byli jednak niżej.

RicardoEureka napisał(a):

Założyłem sobie specjalnie konto, bo powiem Ci, że to jest globalny problem w IT jak pracuję.

Na 5 firm w których pracowałem tylko w jednej miałem ogarniętego analityka systemowego. Np. teraz pracuję z Analitykiem Systemowym zatrudnionym w trakcie hossy COVIDowej po studiach z Zarządzania w banku.... Dziewczyna nie ogarnia podstaw takich jak np. różnice {}, a [] w JSONIE, nawet nie zna podstawowej struktury JSON'a, nie wpominając o XML'u. Pracuję w banku.Tak samo metod typu GET, POST, no totalny brak elementarnej wiedzy.

Ale tak jak wspomniałeś, w hierarchii jest wyżej niż programiści. Np. ona ma spotkania raz na 2 tygodnie z wyższym managerem i raportuje nasz statusów prac i może się "skarżyć" lub "chwalić" pojedynczych developerów. Jest bardzo dobra w uprawianie polityki, branie udziału w feministycznych ruchach w korporacji i tak dalej. Nieraz jak z nią rozmawiam to mam wrażenie jakbym gadał z losową kobietą ulicy i jej coś tłumaczył.

Odpowiedzi w stylu "aha", "yhy". "Co mam wpisać w zadaniu?" "Na ile wyceniasz"

Oczywiście poskarżyć się nie mogę bo jest to żona kierownika z całkiem innego departamentu...... I ma mocne plecy.

Musiałem to z siebie wydusić bo męczę się z nią już 2 lata.

Czyli jej czas w pracy opiera się na "modnych" eventach, no to tak jak większość ludzi, którzy nie ogarniają dlaczego są w IT. Skoro nie mają wiedzy, żeby się wykazać to można iść do korpo na akcję "kobiety w IT" "kobiety programują" "gdzie jest praca dla programistek", a potem "programistka" nie odróżnia GET od POST, więc zamiast się douczyć o różnicy przez 10 minut to woli posiedzieć 4h na firmowych spotkaniach jak to kobiety są uciskane i nikt ich w IT nie rozumie.

A śmiali się, że jak wybrali Trumpa na prezydenta, to mieli ukrócić takie idiotyczne przedsięwzięcia, majkrosoft miał zwolnić zespół od promowania gejów czy innych zboczeńców w korporacjach, a fejsbuk przejść jakąś restrukturyzację żeby też obniżyć ilość pedalskich bredni w korpo. Pogadali pogadali, narobili nadziei i nagłówków w gazetach, a jakoś spektakularnych efektów nie widać i dalej pedzie którzy nie odróżniają XML od JSON panoszą się po korporacjach i zajmują miejsca pracy ogarniętym ludziom.

Spoko, może nie odróżnia GET od POST, ale ma całe 8h w pracy żeby chodzić na debilne spotkania jak to kobiety są uciemiężone w IT, nikt ich nie rozumie, nikt ich nie chce. One takie biedne. Akurat znam spoko analityczkę, ale ona zamiast chodzić na idiotyczne korporacyjne spotkania to pracuje i wywiązuje się z obowiązków, da się z nią dogadać, tylko że ona lubi swoją pracę i ogarnia o co w niej chodzi.

Jak Anetka po humanistyce, która nie odróżnia GET od POST i nic nie umie ma dyrygować programistami, to ma dwa wyjścia: 1. nauczyć się swojego zawodu, 2. mieć wywalone w swój zawód i chodzić na strajki korporacyjne że biedne kobiety nie mają jak znaleźć pracy w IT bo nikt ich nie chce. Opcja druga jest łatwiejsza, pogada głupoty i nie musi się doszkalać, w dodatku jej IQ mniejsze od rozmiaru buta mogłoby nie przetrwać spotkania z pierwszą opcją.

U znajomej w gooooogle szukali jakiś tam 3-4 "menadżerek" na wyższe stanowiska do kierowania zespołem. Było tylko jedno wymaganie że mają to być kobiety. Nawet ogarnięty facet chciał się zgłosić, ale dostali info, że nie ma nawet po co wysyłać CV bo i tak go nie otworzą. Chcieli zatrudnić kilka babeczek, żeby było modnie, że kobiety na stanowiskach pną się w karierze, dzięki gooooogle które ich docenia.
Masz odpowiedź dlaczego potem zespołem dyryguje kobieta, która nie odróżnia GET i POST, bo po prostu ona nie ma tego w zakresie obowiązków. W jej zakresie obowiązków pracowniczych jest bycie kobietą i chodzenie na modne spotkania żeby się chwalić że dzięki wspaniałej korporacji objęła wysokie stanowisko.

Aktualnie widzę niejednokrotnie na stronach korpo jakieś modne hasełka z takimi babeczkami co chodzą w takich czarnych workach na ziemniaki do chowania różnych bombowych rzeczy pod nimi. Potem dzieją się jakieś dziwne eksplozje w metrze lub rozróby we Francji. Niby dzięki korpo one mają pracę xDDD Wcześniej byli geje, murzyni, ostatnio nawet ciapatych mniej, tylko te panie w workach na paszę. Ja tam osobiście wolę bluzę, na mieście często widać kobiety np. w ramoneskach, no ale może niektórzy lubią chodzić w workach, tylko dziwne czemu potem jakieś ładunki wybuchają, może to korporacji nie przeszkadza, jak dotąd żaden CEO nie zginął.

Pracowałem na fabryce automotive gdzie szefem produkcji była kobieta po germanistyce. Na pytanie jakie ma pojęcie o spawaniu, montażu, klejeniu czy wykonywaniu podzespołów padła odpowiedź, że nie musi się znać na technikaliach od tego ma wykwalifikowanych ludzi, ona ma zarządzać i realizować plan narzucony przez zarząd. Jeszcze mało w życiu widzieliście szeregowy jak analityczka po humanistyce was dziwi …

mitowski napisał(a):

Na pytanie jakie ma pojęcie o spawaniu, montażu, klejeniu czy wykonywaniu podzespołów padła odpowiedź, że nie musi się znać na technikaliach od tego ma wykwalifikowanych ludzi, ona ma zarządzać i realizować plan narzucony przez zarząd.

No, czyli to nie przypadek który tutaj obcas omawiamy. Bo analityk nie jest od zarządzania i nie ma wykwalifikowanych ludzi od przeprowadzenia analizy.

Problemem IT (innych branży pewnie też, ale nie znam ich za dobrze, więc się nie wypowiem) jest brak ścieżki kariery od czeladnika do mistrza. Wbrew pozorom widzę, że kiedyś takie podejście miało sens- przychodził młody człowiek na praktykę do warsztatu stolarskiego i zaczynał od miotły- sprzątanie, dbanie o porządek, potem był awans na stanowisko "przynieś- zamieć- pozamiataj", potem powoli coś dłubał pod okiem doświadczonego mistrza. Dzięki temu wiedział jak wszystko działa od A do Z, wiedział że równie istotne jest dobre spasowanie elementów jak i porządek w warsztacie itd. Zresztą to nie tylko domena dawnych małych warsztacików, swego czasu czytałem sporo o ludziach z branży motoryzacyjnej i np. byli projektanci, którzy zaczynali od pracy na linii do wytłaczania karoserii, potem przechodzili do działu projektowego i powoli pięli się wyżej. Kolejna sprawa- w mądrze zarządzanych firmach rodzinnych jeśli syn czy córka mieli przejąć schedę po ojcu, to najpierw zaczynali od najniższych stanowisk, żeby poznać firmę, wiedzieć dokładnie co i jak się robi (znam takie firmy, aczkolwiek to chyba mniejszość). Natomiast co mieliśmy i mamy w IT? Przychodzi młody programista do pracy, ale nikt z nim nie siądzie, nie sprawdzi dokładnie kodu itd., bo nie ma czasu, bo musisz być samodzielny a firmy nie stać na inwestowanie czasu seniora w naukę młodych. Na stanowisko PM-a czy analityka przychodzi ktoś, kto nie ma zielonego pojęcia o rozwoju oprogramowania i mamy co mamy. W mojej kilkunastoletniej karierze pracowałem z różnymi analitykami i niestety potwierdzam, że najgorsi byli ci nietechniczni. Niestety często nadrabiali brak wiedzy brakiem kultury, zwalaniem winy na cały świat dookoła, żyli w ciągłym zagrożeniu, że ktoś ich zwolni. Natomiast najsensowniejsi byli ci, którzy wcześniej pracowali w IT jako testerzy, programiści, ba- nawet ludzie którzy odpowiadali za support już coś tam wiedzieli. Oczywiście, na czysto ludzkim poziomie bywali mało sympatycznymi ludźmi, ale przynajmniej wiedzieli co i jak, potrafili w tasku opisać co dokładnie trzeba zrobić i (co bardzo ważne), na co zwrócić uwagę, żeby nie popsuć/ zmienić czegoś innego przy okazji. Dla uczciwości jeszcze powiem, że zdarzyło mi się, że pracowałem z 1-2 analitykami, którzy nie mieli pojęcia o IT, ale naprawdę przykładali się do swojej roboty, pytali, douczali i w ciągu kilku miesięcy zrobili taki progres, że ktoś z zewnątrz pomyślałby, że to osoby mocno techniczne. Także czasem da się, no ale trzeba chcieć.

micheangelo napisał(a):

kiedyś takie podejście miało sens- przychodził młody człowiek na praktykę do warsztatu stolarskiego i zaczynał od miotły- sprzątanie, dbanie o porządek, potem był awans na stanowisko "przynieś- zamieć- pozamiataj", potem powoli coś dłubał pod okiem doświadczonego mistrza.

Ładnie to opisałeś, problem jest taki że IT jest o wiele inne od normalnej pracy pod każdym względem.

Każdy z nas pewniej by chciał żeby w pracy mistrz poprowadził cię za rękę. Ale to nigdy nie miało i mieć nie będzie miejsca w IT. Lekarze tak mają, najpierw studia, potem specjalizacje, staże, i możesz czuć się poprowadzony za rękę i pewny swojego. W IT nic nie jest pewne. Rozwiązanie z jednej firmy "zawsze tak robimy bo to jest mądre" jest bezużyteczne to i obśmiewane w innej. Myślę że to jest spora część trudności IT i wypalenia zawodowego o które tu łatwiutko.

Rozwala mnie infantylność i naiwność postów w tych wątków. Bo analityczka nie wie jak wysłać request do api, albo nie znają różnicy między {} [].

Analityk to nie jest słaby programista z miękkimi skillami tylko zupełnie inna rola w projekcie. Analityk ma gdzieś (i słusznie) wasze metody i requesty.

To jest człowiek, który ma zebrać wymagania biznesowe od PO i wam je przekazać. Architekt ma zrobić do tego architektuję, a devowie zaklepać kod.

Podstawą przekazania wymagań powinno być spotkanie, na którym analityk przedstawia wymagania, a devowie zadają mu wszystkie trapiące was pytania. Najlepiej jakbyście mieli wcześniej czas zapoznać się z taskami i na spotkanie przyjść już przygotowanym.

Nie ma żadnych sprintów, w ramach których przygotowywane są taski, a następne wszystko jest omawiane na zbiorczym spotkaniu? Tylko sobie lata jakiś analityk bez ładu i składu i wrzuca od przypadku do przypadku jakieś taski bez kluczowych informacji, a wy to macie zakodzić?

Nie macie żadnych retro, na których możecie opowiedzieć co wam się nie podobało w kwestii organizacji w danym sprincie?
Przecież to są absolutne podstawy zarządzania projektem.

Jest problem => jest wskazanie problemu na retro => jest rozwiązanie / ulepszenie procesu => developerzy są szczęśliwi.

ja umiem takie analizy bo jestem programistą, polecam się :D