Zgłaszanie problemów z projektem

Nie wiem czy dobry dział, ale projekt jest z WebDevu więc tu zostawię.

Wchodzicie do projektu, kod w tasku który robicie jest poplątany - widzicie, że może być problem z wdrażaniem nowych feature-ów, wdrożenie tej jednej prostej rzeczy wymaga zrozumienia bardzo (i niepotrzebnie) skomplikowanej logiki.

Co robicie?

a) taski dalej, na razie nie robicie boruty ewentualnie, bardzo delikatnie wspominacie na spotkaniu projektowym, że trochę ten kod przy którym robiliście był skomplikowany, co trochę opóźniło zadanie
b) mówicie jasno na spotkaniu projektowym, że był problem z kodem i jeśli dalsza część jest tak napisana, to może być problem z wdrażaniem następnych feature-ów
c) informujecie PM-a na osobności o problemach

(osoby które wcześniej robiły projekt nadal w nim są i są obecne na spotkaniach)

Idziesz na daily i mówisz, że z tym kodem jest taki i taki problem. Możesz dodać, że Ty widzisz to tak i tak (czyli, że jest chooynia z patatajnią i trzeba przepisać i przebudować bo nie da się nowych ficzerów dokleić). Oczywiście starasz się to mówić jak najbardziej dyplomatycznie.
Patrzysz jaka jest reakcja. Jeśli się zgadzają to ustalacie razem plan działania. Razem, po to byś miał podkładkę, że zespół jest za, a nie że to twoja własna fanaberia.

Jeśli jest sugestia, że owszem jest chooynia ale zrób tak i tak, bo nie mamy czasu i budżetu na sensowne zmiany, to znowu: razem ustalacie plan działania.

Jesli próbują Ci wmówić, że kod jest super a Ty się nie znasz na robocie, to czym prędzej szukaj nowej roboty i już więcej z nikim nie dyskutuj bo i nikogo nie przekonasz a i tak jesteś na przegranej pozycji.

wrzucasz projekt do AIa o ile macie w firmie i kazesz mu wytlumaczyc co gdzi ejak, narysowach schematy itp.

Wybierasz podpunkty A i B i czekasz na reakcje. To raczej normalne, ze będziesz robił taska w kodzie, którego wcześniej nie widziałeś. Dlatego trzeba zwiększyć estymatę. Możesz poprosić o wprowadzanie do projektu. Może ktoś już na tym siedział.

WhiteLightning napisał(a):

wrzucasz projekt do AIa o ile macie w firmie i kazesz mu wytlumaczyc co gdzi ejak, narysowach schematy itp.

Raczej żadnej dokumentacji nie dostanie. Skoro wrzucili go do kodu, którego wcześniej nie widział i może nie znać bez jakiegoś onboardingu to znaczy, że już ktoś tam nie ogarnia. Prawdopdobnie twórcy już nie ma a w projekcie nikt nie ogarnia. Standardowy case, który spotykałem. Trzeba grać karty, które się ma. Na pocieszenie z reguły ludzie to rozumieją i robi się taski po prostu dłużej. (niektórzy tak robią OE, że niby task trudny itd)
Jak ktoś Ci będzie mówił, że jesteś słabym programistą, bo nie umiesz sobie poradzić w kodzie to wtedy masz przesrane, bo rynek jest c**** obecnie na zmiane pracy.(długo trwają rekrutacje)

A i nie rób nic z cursorem. Z doświadczenia wiem, że AI bardzo słabo radzi sobie z pokrętną logiką i przekomplikowanym, przestarzałym starym API. Widziałem już jak ludzie siedzą z sprintu na sprint bo nie umieją czegoś i tylko wrzucają do cursora aż wypluje.

Przez pierwsze 3 miesiące nie narzekaj i nie próbuj sugerować przepisania. Nie masz jeszcze autorytetu żeby krytykować poprzedników.
“(osoby które wcześniej robiły projekt nadal w nim są i są obecne na spotkaniach)” - to ekstra ważne info - management nie widzi żadnego problemu w ich wynikach. Prawdopodobnie narobisz sobie wrogów poprzez “panie, a kto panu tak tu spierdolił?”.

Każdy projekt legacy ma swoje trupy w szafach. To, co widzisz jako problem na początku, zwykle jest drobnostką, a prawdziwe WTF są głębiej. Wybierz swoje walki mądrze, jak już zrozumiesz z kim i o co walczysz.

“informujecie PM-a na osobności o problemach” - PM widzi tylko zamknięte tickety. Jeśli w zespole ma innego programistę, który zamyka tickety i nie narzeka, to nie masz szans wytłumaczyć mu problemów z jakością kodu. Rozmawiasz z technicznymi kolegami i swoim przełożonym.