Dziwna sytuacja w nowej pracy i stres

Kiedyś na linkedin ktoś wysrał post, że programiści oprócz analizy od A do Z powinni jeszcze wymyślać nowe funkcjonalności i proponować je klientom, zostawiając PMowi tylko wycenę. Mam wrażenie, że niektórym tutaj ten pomysł by się spodobał.

Bardzo ciekawy wątek Od siebie dodam, że najkrócej ujmując wszystkie wypowiedzi - chodzi po prostu o zdrowy rozsądek. Czy na nieprecyzyjne wymagania na poziomie „chcę ładną łazienkę” powinno się stawać na głowie aby coś zrobić dla samego faktu roboty? Oczywiście, że nie. Czy powinno się arogancko olać temat odpowiadając „za mało szczegółów”? Oczywiście, że nie. Należy zachować balans w relacji i w dobrej wierze najlepiej jak umiemy pomóc tej drugiej stronie. Jako programista, specjalista techniczny, zamiast odpisać „za mało szczegółów” można zadać konkretne pytania / wskazać pkt które są istotne jako wsad. Jako taki PO, widząc że coś chyba jest nie tak, bo niewiele się dzieje, też jako laik mógłby się zapytać „Czy wszystko ok? Może czegoś brakuje i mogę pomóc?”.

Z ogólnego opisu OPa można by wywnioskować że tak na prawdę to nikt tam nie stawia sobie żadnej poprzeczki profesjonalizmu i porusza się skrajnościami. „Biznes” rzucając trzy słowa „tytułu” potrzeby i nie posiadający czasu aby po prostu temat przegadać. „IT” nie wspierające tego „biznesu” jako spece w tym aby sensownie wymagania zebrać

Biznes często tak robi bo: dev się nie szanuje. Dev jest tańszy niż człowiek z biznesu (często siedzący w centrali w drogim i bogatym świecie) więc taniej jest rzucić devowi ochłap i niech on już tam rozwiązuje za te swoje 200PLN/h.

Kiedyś byłem w takiej sytuacji. Firma nie radziła sobie z projektem własnymi siłami i jak to korpo - jest problem to znaczy, że brakuje zasobów. Na szybko zatrudnili kupę "konsultantów", w tym mnie do odblokowania projektu. Tak jak u Ciebie nikt nic nie wie, nowi ludzie rzuceni w otchłań, zero wiedzy biznesowej etc - jedynie deadliny były dość konkretne. Opcje masz 2 albo uciekać albo coś z tym zrobić.

Jeśli zdecydujesz się na tą drugą opcję to po pierwsze musisz być mega asertywny i zacząć od innych ludzi wymagać. Macie SM - to przecież człowiek od rozwiązywania takich sytuacji. Opisz mu cała sytuację i poproś o zorganizowanie spotkania. Oznacz sytuację w Jirze jako blocker z szerokim komentarzem co się musi wydarzyć aby odblokować task, jakie działania podjemujesz, jaki to ma impakt na timeline. Jesteś po prostu w takiej sytuacji, że osoby z wiedzą są w deficycie i reagują na tych, którzy najwięcej krzyczą.

Będąc w podobnej sytuacji zorganizowałem spotkanie wszystkich developerów (w sumie to było kilka teamów pracujących nad produktem), PM'ów i kierownika działu, żeby przedstawić problem, bo miałem wrażenie, że tam każdy mówi co innego. Wypunktowałem wszystko na liście, przedstawiłem rzeczywisty przebieg projektu w różnych zespołach, jakie są blokady, zrobiłem coś a'la wykres Ganta, gdzie każdy z subprojektów podzieliłem na fazy i potem z każdego teamu poprosiłem developerów o umiejscowienie swojego projektu na tym wykresie i wyjaśnienie czemu są tam gdzie są i czego brakuje.

Sytuacja była o tyle zabawna, że projekty były gdzieś tam w 10-15% gotowe, a zarząd uważał, że jesteśmy gdzieś na 75%. Najzabawniejsze było w tym wszystkim, że deweloperzy byli święcie przekonani, że góra wie o problemach i ogólnej fazie realizacji projektu "bo mówili".

Jak się w firmie zorientowano w jakiej czarnej d...ie jesteśmy z projektem to przez tydzień był straszny dym, ale potem wiele tematów się odblokowało i przez miesiąc prace ruszyły z kopyta. U mnie skończyło się tak, że zamiast kodować zostałem de facto PM'em, co chwila jakieś spotkania, odblokowywanie tematów nawet jakieś spotkania z zarządem wpadły. Trochę to było męczące bo development był w godzinach polskich, a devops i biznes w amerykański i trzeba było jeszcze hindusów wpleść, więc się działo. Finalnie jednak fajnie wyszło i dość ciekawe doświadczenie jak można odblokować projekt.

Oczywiście problemy nadal były bo jak to w korpo wszystko musi być pod górkę, ale przynajmniej wiem, że jak już mi się kodowanie znudzi to się w korpo odnajdę. Z firmy finalnie odszedłem (dłuższa historia, trafiłem tam trochę z przypadku i kontraktownia trochę nie dowiozła tego co obiecała), ale tak jak pisałem warto spróbować to dla sportu zrobić, a jak to nic nie da albo po prostu czujesz, że to nie Twoja bajka to uciekać.

I taki jeszcze jeden pro tip - musisz mocno uważać aby nikogo personalnie nie urazić. Jak ktoś nawala (np. PO nie przekazuje informacji na czas) to podkreślaj, że wiesz jak bardzo jest zajęty i proponuj aby firma dała mu kogoś do pomocy. Jak koledzy z zespołu sobie nie radzą, to mów, że macie zespół niedostosowany specjalizacjami i warto byłoby zrobić kilka przesunięć itd itp. W skrócie jak mówisz o kimś dobrze to z imienia, a jak źle to mówisz o problemie nie o osobie. Staraj się wymusić jakieś zobowiązania - np. codziennie 30 minut PO o stałej godzinie na spotkanie z zespołem etc.

BTW - w tej historii ludzie chwalą Hindusa a ja mam jeszcze większy szacun dla SM. Koleś bierze kasę kilka razy większą od Hindusa za wrzucenie daily do kalendarza.

Na szybko zatrudnili kupę "konsultantów", w tym mnie do odblokowania projektu. Tak jak u Ciebie nikt nic nie wie, nowi ludzie rzuceni w otchłań, zero wiedzy biznesowej

Takie rzeczy da się wyniuchać na etapie rozmowy przedwstępnej.

Dodam trochę do tego co napisał @hadwao
W typowym korpo nie ma większej groźby niż zadanie pytania "czy potrzebujesz jakiejś pomocy?". Dla każdego z odrobiną zdrowego rozsądku/doświadczenia przekaz jest jasny - czekam na to co zrobisz, jak faktycznie z czymś utknąłeś, to ci pomogę, ale bardziej prawdopodobne, że jednak zwyczajnie się opierdalasz i twój manager, albo jego manager jak zaczną rozwiązywać problem, którego nie znają, tak ci dowalą swoimi pomysłami, że może jednak znajdź te 30 minut i zrób, zamiast bujać sie z tą pomocną dłonią przez najbliższe 6 miesięcy.

Co do podejścia "ja jestem od pisania kodu" - kompletnie się z nim nie zgadzam. Software developer jest od tworzenia produktu w postaci jakiejś aplikacji, lub usługi. Nie chodzi mi o bycie szwajcarskim scyzorykiem, ale kompletnie pasywne podejście "napiszą coś co zrozumiem, to ja napiszę kod" jest szkodliwe dla projektu, produktu i samego programisty. W innych wątkach są tutaj dyskusje "kim jest senior" i "po ilu latach można zostać seniorem". Moim zdaniem, przejęcie odpowiedzialności za sukces projektu jest jedną z podstawowych cech takiej osoby w moim rozumieniu. Nie chodzi tylko i wyłącznie o jakość kodu, ale rozumienie podstawowych wymagań biznesowych, dostrzeganie problemów w projekcie i aktywne ich rozwiązywanie. To nie oznacza, że mam być kozłem ofiarnym, jak coś nie pójdzie, ale jeżeli widzę jakiś problem, to nie tylko powiem o nim koledze/przełożonemu, ale również zaproponuję rozwiązanie jakie widzę, albo zrobię Rejtana w momencie kiedy jakaś potencjalna zmiana według mnie rozwali pracę.

Od tworzenia produktu jest zespół deweloperski w skład którego wchodzi deweloper, grafik, analityk, tester i jakiś owner/lead.
Możliwe, że jedna osoba ma kilka ról ale wtedy to jest ustalone w umowie/ofercie.

@itsme: Jasne, że za produkt odpowiada "zespół projektowy". Mało istotne jaki ma skład, czy są tam wydzielone role, hierarchia, czy wręcz przeciwnie - płasko i płynny przydział obowiązków.
Ten zespół składa się z ludzi współdzielących odpowiedzialność za ostateczny kształt produktu. Jeżeli jako programista napiszesz super kod, ale on nie będzie robił tego co oczekuje klient, to produkt będzie kiepski, więc jak widzisz ze swojej perspektywy, że coś nie ma sensu, to również twoim obowiązkiem jest to wyciągnąć na wierzch, a jak widzisz lepsze rozwiązanie to powinieneś o tym informować resztę zespołu, zaczynając od osoby, która za to odpowiada w pierwszej kolejności.

Jest też drugi, osobisty powód dla którego warto wyjść trochę poza własną kuwetę. Możesz być świetnym programistą, ale zarabiać mniej niż taki trochę mniej dobry, ale widzący projekt szerzej niż przez okno IDE. W dodatku praca nad czymś, co rozumiesz, widzisz potencjalną wartość, jaką to przyniesie klientowi, albo rozumiesz jaki problem to rozwiąże jest dużo przyjemniejsza i dająca dużo więcej satysfakcji.

W zamierzchłej przeszłości pracowałem z agencjami digitalowymi. Ludzie od produktu nie mieli pojęcia o swojej robocie więc przerzucali tematy na zespoły. Na spotkania paliliśmy długie godziny, dnie albo tygodnie. Efekty takich działań były takie, że żadne. Raz kiedyś udało się odnaleźć przysłowiowego Graala. Taką januszerkę odwalało się dwie dekady temu. Wtedy wszyscy robili wszystko, a jedyną słuszną metodą pracy był pożar w burdelu.

O tworzeniu produktów / projektowaniu usług popełniono trochę książek, opisano liczne przykłady, opracowano procesy, powstały dobre praktyki. Jak dla mnie
to pewna dyscyplina wiedzy która ma swoje miejsce w obszarze marketingu, zajęcie na full time job, a na pewno nie coś czym można zająć się przy okazji.

Product owner generuje rozmaite tematy oraz dostarcza wymagania. Oczywiście wymagania mogą być takie albo inne. W tym rola zespołu aby wypracować konsensus. Product owner umówił się z managementem na jakieś kpi, na poprawienie tego czy tamtego, na dowiezienie pewnych rzeczy albo wycofanie jakiegoś złomu więc siłą rzeczy jest dysponentem czasu programistów. Oczywiście programista może złożyć nieformalny wniosek aby zająć się tym czy tamtym niemniej to prawo, a nie obowiązek. .

Uruchomienie jiry, utworzenie ticketa, wpisanie tytułu oraz uzupełnienie treści które bardzo często zaczyna się od "As a member of (...) team I'd like to have (...)" z kilkoma bullet pointami niewiele kosztuje, a nadaje sprawie jakiś wymiar formalny. Potem każdy może do tego wrócić, uzupełnić, skomentować.

Rozumiem, że jak ktoś jest nowy to nalezy mu czy jej pomóc, podpowiedzieć, zasugerować i dać takie osobie góra kwartał na ogarnięcie się. Rozumiem, że po stronie klienta jest osoba którą siłą wcielono w taką rolę, nie za bardzo się orientuje to też trzeba pomóc. Natomiast w pozostałych przypadkach to lepiej uciekać z takiego projektu zanim dojdzie do aktów sprawiedliwości ludowej.