Jak powinien wyglądać dobry onboarding/wdrożenie?

I czy pytacie o to na rozmowie rekrutacyjnej(jeżeli tak to w jaki sposób), czy akceptujecie cokolwiek, bo nie jest to w praktyce dla Was takie ważne?

W moim doświadczeniu miałam 2 różne skrajne podejścia pracodawcy -
a) masz tu projekt, pogadanka godzinna w jaki sposób ten projekt zarabia na firmę, no to cześć, idę gasić pożary a ty czytaj kod, może dam ci jakiegoś taska za miesiąc, dwa. Aha, dokumentacji nie mamy.
b) Jest senior, on ogarnia, pytaj go o cokolwiek żeby jak najwięcej się nauczyć o projekcie. Jest dokumentacja projektu.

Wolę opcję B, bo wtedy wdrażam się szybciej i pracodawca jest bardziej zadowolony i daje lepsze podwyżki. Przynajmniej ja tak mam. Jakie są standardy w branży, czy B to rzadkość albo coś pomiędzy?

Sensowne wdrożenie powinno mieć pewne etapy. Przez pierwsze dni masz dokumentacje, potem robisz jakieś prostsze taski i tak z każdym dniem co raz bardziej się zagłębiasz.

Każdy bez względu na doświadczenie, w nowy projekt wchodzi jako junior. Przyjmuję się, że potrzeba średnio miesiąca - 3, żeby taką osobę odpowiednio wdrożyć (Zależy od domeny i rozmiaru projektu).

W wielu projektach niestety nie ma sensownie zaplanowanego procesu wdrożenia, bo nie ma czasu / środków / pomysłów. Wrzuca się delikwenta na głęboką wodę i niech dziubie (W końcu bierze za to pensje). Nie twierdze, że głęboką woda jest zła, ale często może przynieść efekt odwrotny do oczekiwanego - Klient się sfrustruje i ucieknie po okresie próbnym.

Z moich obserwacji wynika również, że finalny efekt wdrożenie składa się też własne podejście. Jeśli jesteś ciekawa projektu i chcesz się wdrożyć, to się szybko wdrożysz.

@Batgirl: ale wiesz ze wtedy zjadasz czas tego seniora, w ktorym on moglby zrobic cos innego (albo bedzie siedzial po godzinach by nadrobic jesli to Januszsoft).

Co mi sie podobalo: jest sobie zestaw spotkan wprowadzajacych (czesc z tego moze byc nagrana), tak zeby sie dowiedziec co gdzie jak kiedy i po co. Zeby odpalic projekt wystarczy cos w stylu git clone + mvn clean install, a nie 50 stron czcionka 8. Masz dokument przekazywany z pokolenia na pokolenie z odpowiedziami na czesto zadawane pytania/rozwiazaniami problemow. Jesli to nie wystarczy -> dopytujesz bardziej doswiadczonych osob ALE pozniej robiesz aktualizacje dokumentu.

Niestety im wiekszy i bardziej skomplikowany system, tym bardziej to kuleje.

Jest przynajmniej kilka aspektów:

• organizacyjny - kto pełni jaką rolę, za co jest odpowiedzialny, jak działają wszystkie procesy
• produktowy - co się buduje, dla kogo, jaką to wnosi wartość, co aktualnie jest rozwijane
• techniczny - techniczne aspekty tego jak ludzie tego używają, punkty styku z innymi systemami, architektura wewnętrzna
• pierdołowaty - uzyskanie dostępów itp

Aspekt organizacyjny jest według mnie najważniejszy, ale osoba z doświadczeniem o wiele szybciej jest w stanie to wszystko wychwycić. Aspekt produktowy jest unikalny, i tutaj bez wprowadzenia będzie trudno. Aspekt techniczny jest zdecydowanie najłatwiejszy do ogarnięcia bez pomocy.

W związku z tym:

• wszystkie pierdołowate aspekty są załatwiane przez zespół zanim w ogóle widzi się człowieka na oczy. Możliwe że setup laptopa będzie trzeba jeszcze zrobić samemu, ale tym bym się szczególnie nie przejmował i explicite kazał nic nie robić dokąd nie przejdzie się do aspektów technicznych

• zaczyna się od aspektów organizacyjnych - kto jest kim i co robi, jak wygląda organizacja poza tym pojedynczym zespołem

• dalej mówi się o produkcie tak żeby dać jakikolwiek kontekst - najlepiej w formie przejścia jakiejś ścieżki użytkownika żeby widać było jak ludzie z tego w ogóle korzystają. Niektóre firmy mają bootcamp uczący jak korzystać z rozwiązania, taki sam jaki mają dostępny użytkownicy, i to się dobrze sprawdza.

• po takim wprowadzeniu można zająć się resztą - powinien być jakiś "buddy" którego można pytać o różne aspekty i który wprowadzi do generalnych praktyk w zespole, wprowadzenie techniczne najlepiej zrobić jakimś zestawem prostych tasków do zrobienia (ale najlepiej dotykających jak najwięcej mechanizmów)

Z czasem rola buddiego jest redukowana i taka osoba funkcjonuje coraz bardziej samodzielnie. Warto też zwrócić uwagę że nikt nie zapamięta wszystkiego, więc różnego rodzaju materiały (tak jak np org chart, jakiś product passport, może część diagramów C4) powinny być aktualne i dostępne do wglądu.

Nie pytam o to na rozmowach, bo

1. mnie to nie obchodzi
2. i tak nie powiedzą prawdy (nie że świadomie okłamią, po prostu opiszą w jaki sposób by to miało wyglądać, a nie w jaki sposób jest realizowane)

Tak jak napisali wyżej @Zawzięty jaszczur i @ledi12 - są różne aspekty wdrożenia, i nieważne jak dobra jest dokumentacja czy opowiedzenie o projekcie, po prostu trzeba na to czasu - właśnie najczęściej 1-3 miesiące.

Wdrożenie powinno uwzględniać to o czym mówi @Zawzięty jaszczur , a w praktyce to mnie nigdy nie było porządnego wdrożenia.
W obecnej pracy to aż patologia była taka, że nawet nie dostałem configów do artifactory i innych configów jak np. runtimowe (nie wiem czemu nie skonfigurowali sobie wszystkie w app.properties tylko springowe configi wrzucali do runtime), musiałem samemu dopytywać o wszystko, a scrum masterka po 2 tyg. zapytała czy będę jeszcze miał jakieś pytania.
Biznesowo to nie wiem nic. Do dziś nie wiem w ogóle do czego ten projekt ma być. Nigdy nie odpaliłem nawet tej aplikacji w całości, nie widziałem GUI. Początkowo sądziłem, że to dlatego, że ludzie w zespole są chamscy, ale przekonałem się, że nikt w zespole nigdy nie odpalił i nie widział GUI. Do tego nikt nie poczuwa się do wdrażania innych, nie ma lidera mimo że oficjalnie jest, ale ciągle siedzi cicho, chyba się boi odzywać.
Na szczęście projekt (powstawał kilka lat) zaorali i siedzę na płatnej ławce.

• co i po co
• accessy
• jak to odpalić
• coś nt. architektury/patternów/konwencji/WTFów użytych
• jakieś docsy/teoria

Najlepszy onboarding jaki widziałem robił jeden z moich ludzi odpowiedzialny za projekty w określonej technologii (był taką "czapką" eskpercko-tim-liderską). On po prostu robił show i prezentację danego systemu, w którym miał człowiek pracować, ale też technologii (bo była mniej popularna, więc często brało się do niej osoby z innych, które chciały się spróbować z czymś innym). Później człowiek dostawał tour po dokumentacji (gdzie co leży, co na początek, co może poczekać) i oczywiście tour po osobach, żeby wiedzieć z czym do kogo uderzać.

Takie podejście dawało jeden z lepiej zgranych zespołów. Ludzie wiedzieli co i dla kogo robią, dlaczego działa tak, a nie inaczej i łatwiej im było swoje miejsce odnaleźć w tym wszystkim.

Wszystkowiedzoncy napisał(a):

Dobry onboarding/wdrożenie powinien mieć na celu przygotowanie nowego pracownika do wykonywania swoich obowiązków i zapoznanie go z firmą oraz jej kulturą. Powinien również zapewnić nowemu pracownikowi wsparcie i narzędzia potrzebne do osiągnięcia sukcesu w nowym miejscu pracy.

Oto kilka kluczowych elementów, które powinien zawierać dobry onboarding/wdrożenie:

1. Przedstawienie firmy i kultury organizacyjnej: nowy pracownik powinien poznać historię i misję firmy, a także dowiedzieć się o jej wartościach i zasadach.
2. Przedstawienie zespołu i przełożonych: nowy pracownik powinien poznać swoich kolegów z pracy i przełożonych, co pozwoli mu lepiej zintegrować się z zespołem.
3. Określenie celów i oczekiwań: nowy pracownik powinien wiedzieć, czego od niego oczekuje się w nowym miejscu pracy i jakie są jego główne obowiązki.
4. Przedstawienie narzędzi i technologii: nowy pracownik powinien poznać narzędzia i technologie, które będzie wykorzystywać w codziennej pracy.
5. Sesje pytań i odpowiedzi: nowy pracownik powinien mieć możliwość zadawania pytań i uzyskiwania odpowiedzi, co pomoże mu lepiej zrozumieć swoje obowiązki i firmę.
6. Mentoring lub mentoring grupowy: nowy pracownik powinien mieć możliwość korzystania z pomocy i wsparcia doświadczonego pracownika lub grupy mentoringowej, co pomoże mu lepiej zrozumieć swoje obowiązki i rozwiązywać problemy.
7. Plan rozwoju: nowy pracownik powinien mieć określony plan rozwoju, który pomoże mu osiągać swoje cele zawodowe w nowym miejscu pracy.

1. Strata czasu -> Nie interesuję mnie historia firmy a na pewno nie będzie miała wpływu na mój performance.
2. IMO tylko ludzi z któymi będę bezpośrednio współpracował, czyli tacy od których zależy moja praca i vice versa. W wielu korpo jest jakaś dziwna moda zapoznawania się całych zespołów, nawet jeśli ze sobą nie współpracują - Znowu strata czasu.
3. Zgoda
4. Od poznania narzędzi i technologii jest rozmowa rekrutacyjna. Ale przyjmijmy, że chodzi o np architekturę, wtedy zgoda :)
5. Zgoda
6. Tylko w przypadku juniora / stażysty. Wszystko ponad to specjaliści, przynajmniej z założenia. Tacy ludzie mają być samodzielni a jeśli nadal potrzebują mentoringu to coś poszło nie tak z procesem rekrutacyjnym (Patrz 4).
7. Znowu, dobre dla juniora/stażysty. Plany rozwoju to również kolejny korpo wymysł.

@ledi12:
Rozumiem, że masz pewne obiekcje co do niektórych elementów typowego onboardingu/wdrożenia. Jednak należy pamiętać, że każda firma jest inna i ma inne potrzeby, więc niektóre elementy mogą być bardziej lub mniej istotne w danym przypadku.

Jeśli chodzi o przedstawienie historii firmy i kultury organizacyjnej, to choć może wydawać się to stratą czasu, to jest to ważne, ponieważ pozwala nowemu pracownikowi lepiej zrozumieć, w jakiej firmie pracuje i jaka jest jej misja. Może również pomóc mu lepiej zintegrować się z zespołem i lepiej odnaleźć się w nowym miejscu pracy.

Jeśli chodzi o przedstawienie całego zespołu, to może faktycznie nie jest to konieczne w przypadku, gdy nowy pracownik będzie bezpośrednio współpracować tylko z niektórymi osobami. W takim wypadku lepiej skupić się na przedstawieniu tych osób, z którymi nowy pracownik będzie współpracować najbliżej.

Jeśli chodzi o narzędzia i technologie, to faktycznie powinny być one przedstawione na etapie rekrutacji, ale jeśli chodzi o bardziej szczegółowe informacje na temat architektury czy innych aspektów technicznych, to może być konieczne ich przedstawienie w trakcie onboardingu/wdrożenia.

Mentoring lub mentoring grupowy mogą być przydatne dla juniorów lub stażystów, ale dla specjalistów mogą być mniej potrzebne. Zależy to jednak od indywidualnych potrzeb i oczekiwań nowego pracownika oraz od tego, jak dobrze zna on dany obszar działalności firmy.

Jeśli chodzi o plany rozwoju, to faktycznie nie są one konieczne dla wszystkich pracowników, szczególnie tych z dużym doświadczeniem.

Przy pracy zdalnej trzeba pytać, bo zrypany onboarding ma wpływ na wasze samopoczucie w pierwszych miesiącach pracy.
Jeżeli na rozmowie odpowiedzą coś ogólnego, „że jest spoko i onboarding jest miły”, to znaczy, że nie mają żadnego planu.

U mnie to wyglądało tak jak poniżej, tylko bez pierwszych trzech obrazków, bo poprzednik już nie pracował. Oczywiście, nie było nawet readme.