Jak dodać nowego programistę do zespołu

Prowadzę małą firmę złożoną tylko z 2 programistów. Budujemy bardzo dużą aplikację dla jednego z naszych klientów. Prace nad tym projektem trwają od 1,5 roku.

Teraz ten klient uzyskał ważny sponsoring i organizuje wydarzenia związane z tym projektem. Teraz mamy termin za 2 miesiące i nie możemy go przekroczyć.

Myślimy o dodaniu nowego programisty do zespołu i zastanawiam się, co możemy zrobić, aby pomóc w jego integracji.

Oto sytuacja:

• Zbliżamy się do progu prawa Brooksa - moment, w którym dodanie nowych programistów przyniesie efekt przeciwny do zamierzonego.
• Aplikacja jest stosunkowo dobrze zaprojektowana, ale w niektórych punktach implementacja jest chaotyczna (szczególnie starszy kod).
• Istnieją testy jednostkowe tylko dla nowszego kodu. Kiedy rozpoczął się ten projekt, nie przeprowadzaliśmy regularnie testów.
• Dokumentacja i komentarze są niekompletne.
• Aplikacja jest zarówno duża, jak i złożona.
• Klient zapisał prawie każdy szczegół na temat swojego projektu, w bardzo jasny i „przyjazny dla programisty” sposób.

Czy warto teraz dodać osobę? Jeśli tak, co możemy zrobić, aby pomóc nowemu deweloperowi zintegrować się z zespołem?

EDYTOWAĆ:

Sponsor organizuje internetowe wydarzenie sportowe na wiosnę. Musi zacząć się w określony dzień roku. Nie możemy tego zmienić.

Co my, programiści (jestem jednym z dwóch), musimy zrobić:

• Wypełnianie istniejącej aplikacji (około 25% pracy do wykonania).

• Stworzenie nowego modułu, niezbędnego do organizacji tego wydarzenia (około 75% pracy do wykonania). Tego nowego modułu nie można opracować bez zrozumienia API głównego programu.

Nie mogę dokładnie oszacować czasu, ale jesteśmy w ryzykownej sytuacji.

Najlepiej nie rzucać nowego programisty w ogień, ale zamiast tego opracować pewne funkcje i / lub poprawki błędów, do których programista nie powinien mieć problemów z wskoczeniem. Znajdź obszar, który wymaga pracy, która nie wymaga od osoby znajomości całej architektury, wymagań i bazy kodu jednocześnie. Może poproś go o pracę nad dokumentacją, aby szybciej nauczyć się systemu.

Zamiast dodawać nowego programistę do zespołu, rozważ dodanie doświadczonego konsultanta na okres od dwóch do trzech miesięcy, aby poradzić sobie z tymczasowym wzrostem obciążenia firmy. Chodzi o to, aby znaleźć kogoś, kto poradzi sobie z uruchomieniem prawie zera, ale jednocześnie niekoniecznie może być najlepszym dodatkiem do twojego zespołu.

Nawet jeśli uważasz, że wzrost obciążenia pracą nie jest tymczasowy, prawdopodobnie nie jest to najlepszy czas na organiczny rozwój zespołu: dodanie trzeciego programisty jest stresujące dla zespołu, nawet bez presji ze względu na termin realizacji projektu; krótki termin tylko pogarsza przejście.

Kompromis polega na tym, że w zamian za tymczasową pomoc otrzymasz kod napisany przez osobę z zewnątrz. Aby zminimalizować to ryzyko, upewnij się, że oboje dokonacie z nim wszystkich recenzji kodu. Upewnij się, że przejrzałeś i rozumiesz również wszystkie jego testy jednostkowe.

Czy warto teraz dodać osobę?

Nie. Jeśli to w ogóle możliwe, postaraj się, aby klient zgodził się na ograniczenie zakresu.

Dodanie osoby tak późno spowoduje znaczne ryzyko, a terminu nie można przesunąć (o ile rozumiem).

Nie rób tego

Jeszcze.

Tradycyjny widok

W swoim pytaniu odwołujesz się do prawa Brooksa z Mythical Man-Month .

Dodanie siły roboczej do późnego projektu oprogramowania sprawia, że ​​później.

Ignorowanie prawa Brookina pociąga za sobą cenę. Nie wielozadaniowość. Skoncentruj się na dostarczeniu minimalnego możliwego do uzyskania produktu (MVP). Następnie skoncentruj się na rekrutacji, pozyskiwaniu zasobów, szkoleniu i zarządzaniu nowym członkiem zespołu.

Dwa miesiące są tak krótkie. Zaplanuj rekrutację z wypaloną listą, a zobaczysz, ile czasu może to zająć.

Larry Page i Siergiej Brin spędzili dwa lata, wybierając początkowy zespół Google. Twój wybór dla pracownika trzeciego powinien być również ostrożny.

Zwinny, nowy widok Millenium

Rywalizacja napędza dynamiczne zespolenie bardziej teraz niż w erze, w której powstał Mythical Man-Month (połowa lat 60.). Długie kariery w jednej firmie już minęły. Teraz często migrujemy między projektami i firmami. Szybkie budowanie zespołu tworzy sukces. Powolne przyspieszenie jest poważnym czynnikiem ograniczającym. Świetne przykłady pochodzą z projektów typu open source, startupów oraz zwiększonego wykorzystania projektów zespołowych na kursach informatyki.

Potencjalnie zespoły zwinne uwzględniają ograniczenia w swoich harmonogramach. Nie spóźniają się, ponieważ są zoptymalizowane do dostępnych zasobów. Integracja nowego personelu jest jeszcze jednym ograniczeniem i jest uważana za kompromis między celami krótko- i długoterminowymi. Zespół Agile nieustannie integruje kod, więc dlaczego nie ludzie?

Zwinny zespół integracji technicznej i społecznej dla nowych pracowników może wykorzystać:

• codzienne młyny
• programowanie par
• refaktoryzacja
• dodawanie brakujących testów jednostkowych
• tuczenie szczupłej dokumentacji
• recenzje kodu

Baranek ofiarny

W „ Wzorach organizacyjnych zwinnego tworzenia oprogramowania” James Coplien omawia dynamikę grupy i koszty dodawania nowych członków zespołu. Jego wzór „Ofiarny Baranek” przypisuje mentoring i szkolenie jednej osobie, chroniąc resztę zespołu przed zakłóceniami.

Jest to strategia, którą warto rozważyć wdrożenie.

Inną strategią jest wyznaczenie nowego mentora (-ów) zatrudnionego, który odpowiada za pytania od nowych pracowników na określone godziny każdego dnia. Jeśli możesz oszczędzić tylko jednego faceta, być może pracuje on bez przerwy rano lub po południu i odpowiada na pytania odpowiednio po południu lub rano. W grupie, w której przebywam latem ubiegłego roku było dziesięciu stażystów, więc wiele osób zostało bardzo przerwanych.

Obecnie mentoring jest prowadzony przez jedną osobę, przede wszystkim w trakcie i bezpośrednio po naszym porannym scrumie (8:30 do około 9:15 łącznie), a po południu między 12 a 3:30 (pracuje od 7:00 do 3:30 po południu).

Cieszę się, że wspomniałeś o prawie Brook'a. Ładnie wykonane. Podstawowym problemem związanym z dodawaniem innego programisty jest narzut związany z przyspieszaniem go i narzut związany z synchronizowaniem stanu z tym, gdzie jesteś w projekcie. Dlatego jeśli zdecydujesz się na trzeciego programistę, spróbuję:

• Daj nowemu facetowi obszar, w którym koszty szybkiego wzrostu są niskie, a on może zacząć działać tak szybko, jak to możliwe. Będzie to zależeć w dużej mierze od tego, kogo zatrudnisz i jakie umiejętności mają.
• Upewnij się, że ten obszar jest luźno połączony z innymi obszarami aplikacji, aby narzut synchronizacji był mniejszy. Wysłanie go do intensywnej pracy z DB i reorganizacja tabel może być zbyt duże.
• Rób, co możesz, aby utrzymać morale. Jak zauważyli inni, dodanie nowego członka zespołu może być stresujące, więc być może inwestycja w gazowane napoje może pomóc.

Jeśli będziesz ściśle przestrzegać Prawa Brook, prawdopodobnie nigdy nie powiększysz swojego zespołu.

Sztuką jest sprowadzenie nowej osoby bez zbytniego spowolnienia w obecnym zespole. W końcu nowa osoba będzie nabierać rozpędu i możesz pokonać garb.

W Twoim przypadku? Polecam nowej osobie napisanie wszystkich brakujących testów jednostkowych.

1. Są one bardzo potrzebne jako zabezpieczenie przed błędami regresji, które spalą cię szybciej niż jakiekolwiek spowolnienie Brooksa.
2. Nowa osoba pozna wnętrzności twojego systemu. To trochę próba ognia, ale ich produkcja nie wchodzi w kod produkcyjny, więc ryzyko tam jest niewielkie.
3. Ustaw sztywny limit czasu, jaki inni członkowie zespołu mogą poświęcić. Na przykład, niech ustawią się w kolejce pytań i zezwalają na 30 minut dziennie na interakcję z innymi członkami zespołu, aż do osiągnięcia terminu.

Spójrzmy prawdzie w oczy: będziesz musiał zarządzać zasięgiem i oczekiwaniami klientów, niezależnie od tego, czy sprowadzisz nową osobę, czy nie. Wypłata następuje w następnym cyklu.

Ed Yourdon miał świetny komentarz na temat prawa Brook'a. Powiedział: oczywiście dodawanie ludzi sprawi, że zwolnisz - ale gdy projekt jest zagrożony, jedyny czas, w którym zarząd przyniesie nowe osoby. Więc: weź je, zminimalizuj wpływ na bieżącą wersję i pozbądź się słabych wykonawców tak szybko, jak to możliwe. W ten sposób z czasem możesz zbudować silny zespół.

Jeśli masz pracę nad innymi projektami, które możesz mu dać, to zwalnia czas dla 2 obecnych programistów na skoncentrowanie się na dużych terminach, które mogłyby pomóc.

Mówisz, że musisz ukończyć 25% oryginalnej pracy plus nową pracę. I musisz to zrobić w ciągu dwóch miesięcy - kiedy zajęło ci to 18 miesięcy, aby wykonać 75% pracy. Mówiąc wprost, oznacza to dla mnie, że twoje umiejętności szacowania są w przybliżeniu przeciętne dla programisty skupionego na kodzie - to znaczy, że myślisz, że zajmie ci to około pół do jednej trzeciej, o ile tak naprawdę jest.

Heroika może pozwolić ci na dostarczenie produktu, na który podpisałeś umowę, ale nie wyrządzi to tobie ani twojemu klientowi żadnych przysług. W tych warunkach będzie tandetny i zepsuty, a ty będziesz uciekał z oparów.

Pamiętaj, że czas spędzony na zatrudnianiu będzie miał duży wpływ na twoją dostępność - nie jest to coś, co możesz zrobić tylko w weekend, znalezienie utalentowanych pracowników, którzy dobrze pasują. Spodziewaj się spędzić przynajmniej kilka tygodni na wyszukiwaniu, przeprowadzaniu wywiadów itp. Oczekuj, że Ty i Twój obecny pracownik stracicie około 10 godzin tygodniowo produktywnego czasu podczas wyszukiwania.

Moja rekomendacja:

Usiądź ze swoim klientem, wyjaśnij, że masz nad głową, i pracuj z nim, aby ograniczyć zasięg do absolutnego minimum.

Edytuj Właśnie widziałem datę tutaj. Jak to się skończyło? (Dzięki Ars Technica za opublikowanie trzymiesięcznego pytania;)

Istnieje kilka różnych sposobów rozważenia zbadania:

1. Wstrzymaj się z zatrudnieniem nowego programisty, aż do upływu terminu, aby łatwiej było skupić się na przekazywaniu wiedzy o domenie nowemu facetowi. To byłoby moje preferencje, ponieważ może to być nieco trudne na kilka sposobów.

2. Sprowadź nowego programistę do pracy nad dokumentacją, testami jednostkowymi i innymi rzeczami, które nie zmieniają żadnego z istniejących kodów. To właśnie zasugerowałbym, jeśli sprowadzisz nowego faceta, aby zminimalizować wpływ na bieżące obciążenie pracą.

Data już minęła, ale dla każdego, kto przeczyta to później.

Kluczową rzeczą do rozważenia jest to, że klient w tej sytuacji ma znacznie więcej do stracenia niż ty. Wydali już dużo pieniędzy i nadchodzi kluczowe wydarzenie, które może przynieść lub załamać ich działalność. Masz już ich pieniądze, a utrata jednego klienta nie powinna zepsuć firmy. Jeśli tak, to masz inne poważne problemy biznesowe poza strasznym zarządzaniem projektami.

Najlepiej jest wynegocjować niezbędny podzbiór funkcjonalności, a następnie pracować w nadgodzinach, aby to zrobić. Jeśli nie możesz zrobić mniejszego podzbioru lub nie chcesz pracować w nadgodzinach w takiej sytuacji, prawdopodobnie nie powinieneś być w biznesie. Może to oznaczać zawieszanie innych klientów, jednak domyślam się, że inni klienci nie zapłacili za 3 lata, więc przechowuj zasoby tam, gdzie są pieniądze.

Jeśli nie chcą negocjować zakresu, oznacza to, że nie powiodą się.

Nie ma szans na dostarczenie tego projektu całkowicie w terminie. Jeśli uważasz, że masz 25% na projekt, którego realizacja zajęła 18 miesięcy, oznacza to, że zostało Ci co najmniej 6 miesięcy (spośród ~ 2 programistów). Dodanie innej osoby nie zmieni tego znacząco.

Jak już wspomniano, rekrutacja wymaga czasu. Z mojego doświadczenia wynika, że ​​zajmuje to miesiąc z absolutnym minimum. Następnie dodaj trening, a twój czas się skończy.

Mam nadzieję, że ci się udało.