Ile czasu zajmuje Wam wejście w nowy projekt?

Hej,

jestem ciekawy ile zajmuje Wam wejście w nowy projekt? Wiadomo, nikt nie ogarnia wszystkiego od pierwszego dnia. Ale ile Wam mniej-wiecej czasu to zajmuje?

Jedyna prawidłowa odpowiedź na to pytania to "zależy" - jak projekt polega na rozwijaniu danego subsystemu w Linux kernel to maintainerzy danego subsystemu wchodzą jak w masło od pierwszego dnia, jak projekt ma tysiące linii, jest wielowątkowy i wymaga experckiej wiedzy domenowej z telekomunikacji to wchodzi się do niego miesiącami.

Między 1 dzień a 6 miesięcy.

Znajomi co kodzą w C++ mówią od roku do 3 lat na wprowadzenie.

Zależy czy jest dokumentacja i poprzednia załoga ;-) Jeśli nie to z 5 minut ;-)

4h

Zależy na kiedy jest to potrzebne, ale generalnie staram się nie wchodzić w nowe projekty, bo jeśli ktoś wie, że ja coś wiem, to już nie jest łatwo spychać robotę na innych.

W pierwszej pracy nie wdrożyłem się przez prawie dwa lata, bo kulała dwustronna komunikacja (ludzie muszą być kompatybilni), a w kolejnej zacząłem prowadzić praktycznie samodzielnie przypisane projekty po 2 albo 3 miesiącach.

Ile czasu zajmie wejście projekt to zależy od domeny, kolegów z zespołu, Twoich tasków, całego proces onboardingu etc. Na przestrzeni lat zauważyłem, że ważną rzeczą jest zasada by "zjeść słonia po kawałku". Innymi słowy ogarniasz w miarę to co jest Ci potrzebne do zrealizowania Twojego taska i nie skupiasz się na reszcie albo relatywnie niewiele czasu jej poświęcasz.

OP, a co masz na mysli pod wejściem do projektu? Zrobienie prostej zmiany, czy developowanie na rowni z reszta zespołu.

Na przykład do frontowego spaghetti, nad ktorym teraz pracuje bylem w stanie wprowadzać zmiany juz po parze dni. Aczkolwiek nawet po dwoch miesiącach jestem zaznajmiony dopiero z mniej niz polową codebase'a, i bardzo polegam na zespole by zrozumieć co sie
dzieje w reszcie apki.

Zależy od technologii, wielkości i jakości. Np w poprzedniej firmie u mnie było combo: c++max11 ale głównie to 03, kilka milionów i strasznie dużo pluginow a jakość była taka, że wielu rzeczy nikt inny nie mógł zrobić poza twórcą który siedzi na jednym stanowisku 20 lat (serio).
Wdrożenie w taki projekt jest cięższe myślę na tyle, że do końca nie wiedziałem nieraz co gdzie jest bo stos wywołań był wielki i pomieszany.
Także różnie bywa.

Czasami mam wrażenie, że ludzie, którzy są w projekcie od jego początku jeszcze się nie wdrożyli.

Kiedyś dołączyłem do zespołu gdzie rozwijano projekt przez 3 lata, około 40 mikroserwisow. Potem było tak że PM chciał abym po 2 tygodniach już latał bugi na produkcji. Oczywiście ja ciepła klucha zamiast powiedzieć że jeszcze nie ogarniam projektu po prostu myślałem że jestem słaby (przecież teraz tak łatwo to wmówić każdemu programiście).

Dla nas może faktycznie potrzeba czasu tych 2-3 miesięcy aby poznać ekosystem ale dla biznesu każda nasza godzina to hajs i często liczą że po około 2-3 tygodniach już będziemy robić jak inni. Często bywa to frustrujące.

Jak sobie z tym radzić?

Argumentami. Jak jesteś "ciepła klucha" i siedzisz cicho, jak ci wciskają zadania z którymi sobie nie poradzisz, to im dłużej z nimi siedzisz, tym bardziej masz przerąbane. W większości przypadków takie "biznes chce na wczoraj, a wymagania dostarczy jutro" powoduje, że projekt ma więcej długu niż implementacji i nie wejdziesz w to szybko. Brałem kiedyś udział w czymś co przez 20 lat pisał gość "po swojemu", zero dokumentacji, miejscami kod taki, że sonar wyświetlał cognitive complexity metod w tysiącach, plus podszyta brakiem kompetencji bucowatość niby-leada. Do tego zaspół biegający pod humor tego gościa jak ze sraczką, bo "biznes ustawił deadline" i nikt nie ma czasu wdrożyć nowych ludzi. Zapomniałbym powiedzieć o jakiś customowych skryptach do obsługi repo i innych wynalazkach. Powodzenia we "wdrożeniu się" w czymś takim. Pracować zacząłem po miesiącu (wcześniej nie miałem dostępu do repozytorium, bo gość, który miał to wyklikać był "zawalony robotą"), ale przez rok mojej pracy w tym czymś nie mogę powiedzieć, że się wdrożyłem. Najzabawniejsze jest to, że do tej pory nie wiem po co właściwie ten projekt był robiony, a mowa o kilkudziesięciu osobach "robiących coś".

@zibenek26 @piotrpo -- o tym, o czym rozmawiacie świetnie pisze Robert C. Martin w "Mistrzu czystego kodu" (tak ciąg dalszy "Czystego kodu", ale bardziej nastawiony na pracę z ludźmi niż z kodem).

Wejście w nowy projekt zależy od skali skomplikowania projektu, istniejącej dokumentacji i szkoleń, a także dostępności osób, od których można zasymilować część wiedzy. Wydaje mi się, że najdłużej to trwa w przypadku projektów wydzierganych od zera, z własniymi bibliotekami i skomplikowaną domeną; a najkrócej dla projektów powtarzalnych i korzystających z popularnych frameworków. Ciężko więc porównywać.

@thematthew173: zdefiniuj wejscie w nowy projekt. Najszybciej robilem commita juz w pierszy dzien (prosty fix, pod nadzorem goscia ktory dluzej pracowal). Zeby zaczac cos dostarczac to przewaznie miesiac - dwa , zabranie wiekszej odpowiedzialnosci - pol roku - rok. Ogarniecie calosci projektu w 100% z wszystkimi kruczkami -> nigdy bo to zawsze wielkie kobyly byly nad ktorymi pracowalo sporo zespolow.

U mnie nie ma czasu na wdrażanie się w projekty. Firma ma kilkanaście aplikacji wewnętrznych. Dziś naprawiam bugi w jednej aplikacji, bo ktoś tam znalazł, jutro poprawiam, lub dodaje nowe funkcjonalności do innej aplikacji i tak w kółko. PM jeszcze wymaga ze jak rzuci kilka tematów do zmian to z biegu będzie miał zrobiony co najmniej jeden temat w max 1 dzień lub kilka godzin.

Ja mam wrażenie ze zawsze zajmuje mi za długo.

Np. Projekt niezbyt duży: 4 devów, każdy backendowiec który bawi się czasami na froncie. Pewne technologie były czymś nowym dla mnie - po 3 miesiącach czułem się pewnie w backendzie (ale zaznaczam, projekt dosyć mały, ale architektura zepsuta od samego początku).

Na pewno zależy to od wielkości projektu, jak i od metody wprowadzania nowego członka do projektu. Raz dołączyłem do projektu w którym na początku nawet nie miałem dostępu do Jira, git, kod pisałem i kolega robił commit. Po prostu siadaj i pisz.
Innym razem spędziłem tydzień w delegacji, dowiedziałem się bardzo wiele o projekcie, narzędziach używanych w nim i bardzo mi to pomogło wdrożyć się w projekt. Także warto zainwestować czasem trochę czasu na wprowadzenie nowego członka do projektu.