Jak najszybciej wdrożyć programistę do nowego projektu?

Dziś na tapet wrzucam temat wdrożenia nowego programisty do istniejącego projektu. Dostałem przez ostatni czas wiele pytań od czytelników jak szybko wdrożyć programistę do projektu? Szczerze mówiąc zdziwiło mnie zainteresowanie tym tematem bo wydawało mi się, że jest oczywisty, ale skoro nie jest – moja pomoc dla Ciebie w tym wpisie.

Czas wdrożenia

Wdrożenie jest czasochłonne. Musisz sobie z tego zdawać sprawę. Minie wiele tygodni zanim nowa osoba w projekcie będzie realizowała zadania tak płynnie jak pozostali członkowie zespołu.

Przedstawię ci kilka metod w postaci listy kroków, dzięki którym czas wdrożenia programisty ulegnie skróceniu.

FYI: w ramach czytelności treści na osobę wdrażającą się do projektu będę używał terminu świeżak i rekrut.

Nauka Technologii

Mało osób zdaje sobie sprawę z tego, że często osoba wdrażająca się w nowy projekt ma główne dwa problemy do rozwiązania.

Pierwszym z nich jest nauka technologii. Wydawałoby się oczywiste, ale niektóre osoby zakładają błędnie, że jeśli ktoś zna Framework X, to odnajdzie się technologicznie w każdym projekcie używającym Framework X. Z mojego doświadczenia wynika, że nie zawsze tak się dzieje.

Zazwyczaj projekt jest wypadkową wielu technologii, nie wystarczy znać „głównej” by się w nim odnaleźć. Kolejną rzeczą jest to, że każdy developer ma unikalny styl rozwiązywania problemów. Często technologia pozwala na dowolność konwencji – więc pomimo znajomości technologii problemem jest nieznajomość rozwiązań w projekcie.

Jeśli już jesteśmy na temacie niestandardowych rozwiązań to odsyłam Cię z tego miejsca do mojego wpisu o wiedzy plemiennej w projektach.

Wiedza plemienna jest czymś czego najtrudniej się nauczyć, bo zazwyczaj nie jest nigdzie dokumentowana. Nauka technologii jest o tyle prostsza, że zazwyczaj jest (lepsza lub gorsza) dokumentacja od autora.

Zazwyczaj zespół projektowy nie ma czasu na dokumentowanie „smaczków projektowych” (wiedzy plemiennej).

Nauka Projektu (Zakresu)

Kolejnym problemem z jakim będzie musiał mierzyć się developer to nauka projektu. Mam tutaj na myśli zakres projektu.

Większość projektów ma skomplikowane procesy, mechanizmy i zasady. Które ciężko zrozumieć ucząc się projektu – nawet pomimo opisania w dokumentacji. Dzieje się tak ze względu na nieznajomość kontekstu czytanego dokumentu.

Właśnie dlatego osoby będące długo w jednym projektem porozumiewają się skutecznie i szybko (na przykład jednym zdaniem). Dzieje się tak bo oboje myślą w tym samym kontekście.

Nowa osoba niestety nie myśli kontekstem projektu i w jednym zdaniu może być sporo niewiadomych. Dlatego taka osoba potrzebuje szczegółowego wyjaśnienia każdej kwestii.

Jak (najszybciej) wdrożyć programistę? – lista kroków

Zebrałem swoje przemyślenia w listę kroków, jakimi powinniśmy się kierować podczas wdrożenia nowego programisty do projektu.

0. (NIE) Czytaj o technologiach projektowych

Z tego co zauważam w większości zespołów krokiem 0 jest to, że nowa osoba „czyta sobie o technologiach projektowych”, robi research.

Nie jest to błędem – czytanie o technologiach nikomu nie zaszkodzi. Według mnie nie przynosi wymiernych korzyści. Poniżej uzasadnienie.

Po pierwsze to zadanie zrobienia researchu zazwyczaj nie jest określone czasowo, ani wynikowo. Osoba dostaje listę technologii (lub nie) i ma o nich poczytać. Można czytać 15 minut, jak i 3 dni. Można zrozumieć czytany tekst „bardzo” lub „mało”. To zadanie zazwyczaj można zamknąć w dowolnym czasie z dowolnym rezultatem. Dlatego jestem przeciwnikiem samego podejścia w ten sposób do tematu.

Po drugie czytanie nie jest najefektywniejszą metodą nauki (według mnie). Jestem zwolennikiem tego, żeby osoba doświadczona w projekcie opowiedziała o „technologiach” projektowych nowej osobie.

W godzinę czasu można przekazać naprawdę dużo informacji. Co ważniejsze – istotnych informacji. Według mnie lepiej wychodzi zdzwonienie się i porozmawianie o projekcie przez 1h (dwóch osób, czyli koszt to 2RBH).

Zapewniam Cię, że osoba, która czytałaby samodzielnie przez 2 RBH (ekwiwalent rozmowy) zrozumiałaby dużo mniej przez naukę samodzielnie.

Przyczyną jest tego, że przyswoiła by mnóstwo informacji, które będą nieistotne. Natomiast jeśli wdrożenie przeprowadza bardziej doświadczona osoba to przekazuje pigułkę wiedzy – samo mięso.

W ogólnym rozrachunku wychodzi szybciej i efektywniej. Dlatego moja rada: nie czytajcie o technologiach. Niech osoba bardziej doświadczona opowie o stacku technologicznym.

1. Mistrz i Uczeń – Prowadź Za Rączkę

Trzeba wyznaczyć osobę wdrażającą „świeżaka”. Kogoś, kto poprowadzi go przez całą wiedzę plemienną projektu i technologie projektowe.

Nie chodzi o to, by osoba wdrażająca poświęcała cały czas pracy naszemu „świeżakowi”. Chodzi o to by miała kilka godzin tygodniowo, które mu poświęci.

Zazwyczaj projekty są w jakiś sposób dokumentowane. Dla osoby nowo dołączającej do projektu mimo, że analiza będzie napisana w sposób prawidłowy – może być nie jasna. Dlatego bo nie zna kontekstu projektowego. Pisałem o tym kilkanaście zdań wcześniej w Nauka Projektu (Zakresu).

Tutaj sprawa ma się podobnie jak w przypadku „czytania o technologiach” przed projektem. Można poświęcić na to dużo czasu i w raz nie rozumieć dokumentu. Dlatego w tym miejscu polecam by osoba wdrażająca opowiedziała świeżakowi najistotniejsze rzeczy.

Chodzi tu o opowiedzenie o elementach, które są kluczowe. Opowiedzieć o projekcie – bardzo ogólnie. To osoba wdrażająca powinna trzymać pieczę nad świeżakiem i odpowiednio dozować mu porcję wiedzy, która będzie mu przydatna przed realizacją poszczególnych zadań.

Mówienie wszystkich detali na samym początku mija się z celem – są one za bardzo abstrakcyjne na początku. Tak czy siak zapamiętamy tylko niewielki procent z nich.

Lepiej wychodzi dozowanie informacji na temat zakresu projektu przed konkretnym zadaniem. Osoba wdrażająca decyduje jaki fragment wiedzy ma podać.

Świeżak powinien zacząć od zadań bardzo prostych. Takich, które osoba zaznajomiona w projekcie wykonuje do 0.5 rbh. Oczywiście świeżakowi zajmą one dużo więcej czasu.

Ważne jest by te zadania nie miały dużego wpływu na projekt. Warto zacząć od np modyfikacji wyglądu, przemieszczenia kontrolek. Świeżak powinien nauczyć się na takim zadaniu workflow projektowego.

Takie etap powinien trwać do około 40rbh przepracowanych przez świeżaka. Dłużej nie ma sensu, w przypadku prostych projektów można ten czas nawet skrócić do około 20 rbh.

FYI: to doskonały sposób na wyczyszczenie zadań z backlogu, które mają niski priorytet i nikt nie miał czasu się nimi zająć. Dla świeżaka jak znalazł!

2. Zadania Z Planem Realizacji (~2 rbh)

Świeżak ma już za sobą 20-40rbh pracy na prostych zadaniach nie mających wpływu na zakres.

Czas na krok drugi, czyli przydzielanie zadań świeżakowi, które osobom znającym projekt zajmują około 2 rbh.

Te zadania oprócz opisanego zakresu projektu powinny zawierać jeszcze jedną rzecz – plan realizacji zadania. Jeśli samo pisanie planów realizacji jest dla Ciebie niejasne – daj znać w komentarzach. Jeśli zainteresowanie będzie duże to popełnię wpis na ten temat.

Osoba, wdrażająca świeżaka powinna ułożyć dokładny plan realizacji takiego zadania. Chodzi o ułożenie listy kroków i wskazanie miejsc w projekcie, w którym dana logika powinna się znaleźć.

Taki plan powinien odpowiadać na wszystkie pytania techniczne odnosnie danego zadania. Świeżak po przeczytaniu go powinien móc zrealizować dane zadanie według konwencji projektowej i dobrych wzorców projektowych. Bez planu to byłoby mało prawdopodobne, że rozwiązanie świeżaka nie będzie wymagało refactoringu.

Niektórzy zamiast planu realizacji opowiadają świeżakowi jak coś ma być zrobione, on ich pyta o dalsze kroki i w ten sposób postępuje realizacja. Nie jest to błędem, jednak nie jestem zwolennikiem tej metody. Opisane plany realizacji mogą posłużyć innym programistom, którzy kiedyś dołączą do projektu. Poza tym – co powiedziane jest ulotne. Zapisane może posłużyć do rozbudowy wiki projektowego. Jeśli nadal nie jesteś przekonany co do przygotowywania planu realizacji rzuć okiem na ten wpis, w którym poruszałem temat wydajności zespołów zdalnych i lokalnych.

Taki plan wbrew pozorom powinien zaoszczędzić czas osobie wdrażającej. Będzie rzadziej odrywana od pracy przez świeżaka z pytaniem „jak to zrobić?”.

Krok drugi z planem realizacji powinien trwać różnie. W zależności od różnorodności zadań. Warto, żeby był plan na każdy typ zadań jaki może wystąpić w projekcie – coś z modyfikacją modelu, coś w logice, coś połączenie logiki i frontu etc. Ciężko mi tu podać przykład, który będzie pasował do Twojego przypadku bo każdy projekt jest inny. Mam nadzieję, że wiesz co mam na myśli.

Możesz przyjąć, że taki etap powinien trwać od 30-60rbh przepracowanych przez świeżaka.

3. Dłuższe Zadania z Planem Realizacji (~4-8 rbh)

Krok 3 jest krokiem analogicznym do drugiego. Z tą różnicą, że dajemy trudniejsze i dłuższe zadania do realizacji. Takie, które osobie doświadczonej w projekcie zajęłyby 4-8 rbh.

Po wykonaniu kroku trzeciego, świeżak powinien już mieć styczność z każdym typem zadań projektowych.

Taki etap powinien trwać objętościowo podobnie jak krok drugi – od 30-60 rbh.

Osoba wdrażająca w tym kroku powinna poczuć mniej pytań ze strony świeżaka. Samo przygotowanie planu będzie mogło być już mniej szczegółowe, w związku z tym, że zadania są dłuższe – będzie ich mniej. Co znaczy mniej planów realizacji do przygotowania. Osoba wdrażająca powinna odczuć, że ma więcej czasu na swoje zadania.

4. Świeżak Przygotowuje Plan Realizacji

Kolejnym krokiem jest również praca na dłuższych zadaniach 4-8 rbh. Z tą róznicą, że to świeżak przygotowuje plan realizacji, a osoba wdrażająca go weryfikuje i koryguje.

Chcemy osiągnąć to, żeby świeżak umiał sam projektować rozwiązania do zadań i pisał zgodnie ze standardami. Krok drugi i trzeci miały go nauczyć jak poruszać się w projekcie. Krok czwarty to weryfikacja tego, co zostało w głowie świeżaka. Jest on już prawie samodzielny.

Krok czwarty powinien trwać od 40-80 rbh. Po jego ukończeniu możemy uznać, że programista jest wdrożony do projektu, na tyle, że może samodzielnie się w nim poruszać. Wie, gdzie szukać rozwiązań, przebrnął przez większość „common problems”. Ma do dyspozycji kilkanaście planów realizacji do których może wrócić.

W razie czego zawsze może dopytać innych członków zespołu o detale, które mu umknęły lub jeśli trafi na nowy rodzaj problemu.

To, że programista przeszedł takie wdrożenie, nie znaczy, że będzie realizował funkcjonalności tak szybko jak reszta zespołu. To znaczy jedynie tyle, że posiadł narzędzia do rozwiązywania samodzielnie problemów.

Minie jeszcze kilka tygodni zanim będzie realizował zadania tak szybko jak pozostali.

Podsumowanie

Wdrożenie nowego programisty zajmuje dużo czasu. Co zazwyczaj przekłada się na duży koszt firmy.

Osoba wdrażająca się ma dwa główne problemy do rozwiązania: poznać technologie projektowe i poznać zakres projektu.

Czytanie o technologiach i dokumentacji (uczenie się zakresu) nie zawsze jest optymalną metodą nauki. Zazwyczaj więcej efektów w krótszym czasie osiągniemy jeśli wyznaczymy osobę wdrażającą świeżaka w projekt. Przekaże on wtedy samo „mięso” – najważniejsze rzeczy.

Pierwszym krokiem wdrożenia jest realizacja zadań bardzo krótkich, które nie mają większego wpływu na projekt. Dzieje się to pod okiem osoby wdrażającej.

Drugim krokiem jest realizacja prostych zadań (osobie doświadczonej w projekcie zajęłyby ~2rbh), gdzie osoba wdrażająca układa plan realizacji, według którego świeżak realizuje zadania.

Trzecim krokiem jest dozowanie trudności zadań. Przydzielamy świeżakowi zadania dłuższe – takie, które osobie doświadczonej zajęłyby 4-8 rbh. Utrzymujemy przygotowywanie planu realizacji.

Krok czwarty jest ostatnim krokiem wdrożenia. Świeżak dostaje zadania, które osobie doświadczonej zajeły by 4-8rbh. Różnicą jest to, że to świeżak układa plan realizacji zadania. Osoba wdrażająca go weryfikuje i koryguje.

Jak wyceniać czas wdrożenia znajdziesz w jednej z lekcji mojego kursu Dokładna Wycena Projektów IT – rzuć okiem na agendę!

To co opisałem powyżej powinno być dostosowane do Twojego przypadku, typu projektu, możliwości i umiejętności programistów. Nie zawsze to co opisuję powyżej jest możliwe do wykonania – z różnych przyczyn.

Mam nadzieję, że pomogłem – w razie pytania zostaw komentarz.