Lepszy sposób na szkolenie nowych pracowników [zamknięte]

Zespół, w którym obecnie uczestniczę, ma dość duże obroty, a członkowie zwykle przenoszą się do różnych projektów w ramach tej samej firmy. Obecnie naszym „szkoleniem” dla nowych członków jest powiązanie ich z głównym kontaktem (zazwyczaj ostatnią osobą, która ukończy szkolenie), która zapewni im praktyczne doświadczenie i zapyta więcej starszych programistów, czy nowi pracownicy zatrudniają mentora nie wie Daje to szansę na szybkie zaangażowanie nowego pracownika i prosi mentora o lepsze zrozumienie systemu.

Jednak, jak możesz sobie wyobrazić, ten styl szkolenia jest bardzo czasochłonny i nie zapewnia bardzo dobrego transferu wiedzy (rozpowszechniają się nieporozumienia, powiększają się luki).

Zadanie polegało na generowaniu dokumentacji i materiałów szkoleniowych dla naszych przyszłych nowych pracowników. Od czasu do czasu piszę teksty techniczne, ale są one przeznaczone dla użytkowników końcowych i są bardzo specyficzne z dużą ilością zrzutów ekranu i zajmują dużo czasu.

Tworzenie nowej dokumentacji dla nowych pracowników jest uważane za niski priorytet i mam obecnie tylko ~ 40 godzin, aby nad tym popracować. Dokumentowanie systemu obecnym sposobem, w jaki piszę dokumentację techniczną, ledwo zarysowałoby powierzchnię w 40 godzin. Zwłaszcza biorąc pod uwagę, że muszę dokumentować nie tylko bazę kodu, ale także wdrożenia i wsparcie.

Jak mogę szybko napisać dokumentację, aby jak najszybciej uzyskać informacje o nowych pracownikach bez poświęcania znacznej ilości czasu na pisanie dokumentacji?

Informacje dodatkowe:
Obecnie mamy zarówno wiki, jak i dokumentację szkoleniową, jednak obie są dość rzadkie.

Dobre pytanie. Szkolenie w miejscu pracy dla programistów jest bardzo rzadko traktowane poważnie, o czym często się nie mówi.

Niektóre pomysły, które widziałem, działają dobrze:

• Na swojej wiki przygotuj nowy dokument do wypożyczenia (ten, który piszesz). W tym dokumencie opisz zadania, które nowy wynajmujący wykona przez pierwsze 1-2 tygodnie. Tam, gdzie pracuję, można znaleźć wiele informacji od samego początku, od wewnętrznego oprogramowania / narzędzi, przez procesy, aż po lokalizacje określonych rodzajów informacji. edytuj> mamy instrukcje takie jak „zainstaluj x, y, z w kolejności” ze zrzutami ekranu do konfiguracji itp. Więc konfigurowanie systemu lub farmy (VM) z Win Server, SQL Server, SharePoint, BizTalk, nasze oprogramowanie nie jest tak proste, jak to Dźwięki. Dotyczy to innych wersji obsługiwanych przez nas aplikacji.
• Ćwicz problemy. Tam, gdzie ja jestem, mamy produkt, który eksponuje wielkoformatowy interfejs API. Dlatego zawsze dobrze jest przejrzeć naszą własną dokumentację produktów, aby napisać (z góry określone) rozszerzenia, tak jak zrobiliby to nasi klienci. Jeśli więc posiadasz bibliotekę matematyczną jako część interfejsu API swojego produktu, napotkasz problem praktyczny polegający na „napisaniu kalkulatora przy użyciu naszego interfejsu API” lub czegoś podobnego.
• Mentorzy są dobrzy. Zachować je. Robimy to również tutaj, i nie tylko jest to dobry sposób na poznawanie ludzi / przyjaciół, ale są nieocenione jako źródło wiedzy. Polecam nie mający być ostatnią osobą, aby zakończyć trening, ponieważ nie mam historię wiedzy korporacyjnej, że ktoś inny może. Niech wszyscy robią to na zmianę.
• Robimy (z grubsza) cotygodniowe prezentacje / rozmowy techniczne. Poproś nowych pracowników, aby wybrali coś z twojego produktu (lub przydzielili go) i zrobili prezentację po 3 tygodniu. Upewnij się, że wiedzą, że jest miejsce, w którym mogą się pomylić, a zespół może je poprawić, jeśli popełni błąd w prezentacji.
• Niech nowi zatrudnieni pracują nad dokumentacją po uruchomieniu. Zmusza ich do przeczytania.

Jak zauważa Dan McGrath, dobrym pomysłem jest zachęcenie nowych pracowników do ulepszenia wiki również dla nich.

Po pierwsze, zasugerowałbym, abyś nie musiał przygotowywać nowego dokumentu szkolenia dla pracowników tak dokładnie, jak napisałbyś dla klienta. Musi być wystarczająco techniczny, aby nowy deweloper mógł go używać jako przewodnika, ale nie tak szczegółowy, aby opisywał każdą drobiazg. Będą mogli porozmawiać z zespołem, jeśli w końcu będą mieli pytania.

Jakie 10 najważniejszych rzeczy powinien wiedzieć nowy pracownik, aby był użyteczny dla Twojego zespołu? Skoncentruj się na tych rzeczach. Ustaw je jako listę hitów przedmiotów, aby nowy deweloper miał wystarczająco dużo do zrobienia i wystarczającą ilość informacji, aby je kontynuować. Jeśli masz zbyt wiele rzeczy na liście, zadaj sobie pytanie, czy będą to robić w ciągu pierwszych dwóch lub trzech tygodni. Jeśli nie będą robić czegoś w tym czasie, być może nie powinno to być w przewodniku pokładowym.

W każdej sekcji przewodnika upewnij się, że na górze jest wyróżniona osoba, do której należy przejść. W ten sposób, jeśli nowy pracownik ma jakieś pytania, wiedzą, do kogo zwrócić się o pomoc. Upewnij się również, że jeden członek zespołu nie jest osobą, do której należy zbyt wiele sekcji. Nie chcesz poświęcać czasu jednej osobie na nowe pytania dotyczące zatrudnienia, jeśli nie są one mentorem.

Nie spędzaj całego tygodnia na tym dokumencie. Daj sobie trochę czasu na dostosowanie go po tym, jak pozwolisz mu przejść przez co najmniej jednego nowego zatrudnionego. Zobacz, co działa dobrze, a co nie, i napraw.

Niedawno zacząłem pisać podobny dokument w moim miejscu pracy, z podobnymi ograniczeniami czasowymi. Rozumiem, że łatwo jest napisać to na bardzo szczegółowym poziomie, tak jak na początku też, ale może to faktycznie przynieść efekt przeciwny do zamierzonego.

Jeśli ktoś zaczyna nową rolę, prawdopodobnie jest zalewany informacjami przez pierwsze kilka tygodni. Ich wstępne szkolenie będzie zrzutem głowy programisty, który pracuje w firmie od wielu lat, moim zdaniem znacznie skomplikuje to, co ktoś powinien wiedzieć przez pierwsze kilka miesięcy, a nawet rok na tym stanowisku. Utrzymaj go na wysokim poziomie, spróbuj użyć standardowego żargonu i pojęć, a następnie rozwinąć je zgodnie ze specyfiką procesów firmy.

Dla mnie pierwsza iteracja tego dokumentu to po prostu zarys SDLC, z którego korzystamy w moim miejscu pracy, wraz z listą ról związanych z każdym krokiem, kilkoma przykładami osób, które pełnią te role, oraz szczegółowymi listami kontrolnymi związanymi z także na każdym etapie cyklu życia. Osobiście uważam, że listy kontrolne są niezbędne do celów szkoleniowych, ale także do wszystkiego, co robię w pracy. Na przykład:

• Project Manager (Joe) przydziela ci zadanie w Jira.
• Ustaw szacowany czas realizacji zadania na podstawie wzoru x.
• Ustaw bilet jako „w toku”, gdy zaczniesz nad nim pracować.
• Utwórz oddział z git, kliknij link, aby wyświetlić 30-sekundowe wideo na temat tego postępu.
• Napisz testy jednostkowe na podstawie ograniczeń w dokumencie projektowym, zobacz stronę y, aby zapoznać się z konwencjami nazewnictwa testów jednostkowych.
• Ustaw bilet do recenzji i prześlij kod do przeglądu systemu ... ”itp.

Twój nowy pracownik powinien mieć nadzieję, że zapozna się z większością koncepcji, a teraz będzie miał przewodnik krok po kroku, w jaki sposób procesy są stosowane w firmie. Robię też szybką demonstrację tego procesu od początku do końca, używając prawdziwych dokumentów z projektów, które moim zdaniem zostały dobrze wykonane.

Jak wspomniano, jest to również żywy dokument, więc sekcje można rozbudowywać, gdy okaże się, że potrzebują one więcej informacji. Cały zespół powinien być zaangażowany w aktualizowanie go. Może to być wiki, dokument OneNote, cokolwiek, ale coś, co wszyscy ludzie mogą edytować i przeglądać, a następnie zacząć angażować inne osoby w ulepszanie go, gdy mają wolną godzinę tu i tam. W ten sposób jedna osoba nie robi tego i nie rozpowszechnia swojego procesu wśród wszystkich nowych pracowników.

Po zapoznaniu się z procesem poproś go o wykonanie drobnych poprawek / błędów w projekcie o znaczeniu innym niż krytyczny i poproś, aby zadali pytania, których dokument nie obejmuje. Zapisz, jakie są te pytania, ponieważ prawdopodobnie powinny to być pierwsze rzeczy, które dodasz do dokumentu przy następnej pracy.

Nie można łączyć robienia czegoś takiego bez spędzania czasu. Przynajmniej jeśli chcesz to zrobić sam. Powinieneś zadać sobie pytanie, czy naprawdę konieczne jest udokumentowanie go tak precyzyjnie, jak próbujesz?

Jedyną alternatywą byłoby pozwolenie nowym pracownikom na wykonanie głównej pracy. Pozwól im napisać niektóre części. Czas poświęcony na ich poprawienie (w formie informacji zwrotnej) będzie krótszy niż w obecnych sytuacjach. Podaj kilka dobrych szablonów i nie musisz się martwić o układ.

Wierzę, że już wiesz, że zlecili ci misję niemożliwą. Jako pisarz prawdopodobnie znasz już cytat Marka Twaina:

Gdybym miał więcej czasu, napisałbym mniej.

Biorąc pod uwagę praktycznie brak zasobów, prawdopodobnie najlepsze, co możesz zrobić, to zdobyć szafkę na akta i poprosić wszystkich, aby zrobili kopię tego, co już mają, i umieścili ją w szafce na akta. W ten sposób możesz przynajmniej powiedzieć nowemu najemnikowi: „Jeśli chcesz dowiedzieć się czegoś o systemie, zacznij od szafki na dokumenty”.

Dobre pisanie wymaga czasu i kropki. Ponadto należy go dostosować do grupy docelowej. To, co działa dla użytkowników końcowych, nie będzie tym, czego potrzebuje programista.

Nie wspominając o tym, że dobre szkolenie nie ogranicza się do materiałów pisemnych, obejmowałoby pełne wykorzystanie zasobów edukacyjnych, w tym on-line, zajęć, multimediów itp.

Jak mówią: „Jeśli uważasz, że edukacja jest droga, spróbuj kosztować ignorancję”.

Ponadto oczywiste jest, że przeglądanie dokumentacji jako czegoś, co należy zrobić po fakcie, zamiast uczynienia jej integralną częścią procesu od pierwszego dnia, wskazuje na systemowy problem organizacyjny.