Jak dodać nowego programistę do zespołu

24

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.

lortabak
źródło
11
nie jesteś u progu prawa strumyka, które zostało uchwalone ponad rok temu.
Ryathal
3
Nie napisałeś ani słowa o tym, jaki cel masz w tym terminie. Dodać jakieś funkcje specyficzne dla tego sponsora? Zrób prezentację produktu na wydarzenia? Utworzyć pakiet instalacyjny? Napraw niektóre z najważniejszych problemów? Jakie masz problemy, których nie możesz rozwiązać w obecnym zespole?
Doc Brown,
Ile czasu zdaniem 2 programistów będą potrzebować na własną rękę? 3 miesiące (obliczenie wynosi 2 devs * 3 miesiące to 3 devs * 2 miesiące)?
scarfridge
@DocBrown Dodałem więcej szczegółów do pytania. Mam nadzieję, że teraz jest jaśniej.
lortabac
„Dokumentacja i komentarze są niekompletne” ... „Klient zapisał prawie każdy szczegół na temat swojego projektu, w bardzo jasny i„ przyjazny dla programisty ”sposób”. Poproś nowego faceta, aby przetłumaczył pisma klienta na dokumentację projektową, a następnie: „Są testy jednostkowe tylko dla nowszego kodu. Kiedy ten projekt się rozpoczął, nie przeprowadzaliśmy regularnie testów”, każ mu napisać i uruchomić testy. Nie będzie ci przeszkadzał i będzie przyczyniał się do projektu
Mawg,

Odpowiedzi:

24

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.

Nik
źródło
Dodanie Unittestów do starego kodu i naprawienie błędów to kilka pomysłów, co nowy programista mógłby zrobić - oczywiście dzięki wsparciu i recenzjom kodu przez innych. Może potrzebny jest automatyczny test interfejsu użytkownika? Jest to również coś, co nowy deweloper może zrobić i dowiedzieć się wiele o aplikacji.
Hans-Peter Störr,
18

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.

dasblinkenlight
źródło
5
To zależy, jak daleko są za nimi. Konsultant będzie kosztował więcej i zabierze ze sobą wiedzę, kiedy odejdzie. Znalezienie każdego, kto wymagałby prawie zerowego czasu rozruchu, jest prawdopodobnie pobożnym życzeniem.
Nik
1
@Nik Zgadzam się, wyższy koszt jest zdecydowanie kompromisem; podobnie wiedza odpływa z projektu. Znalezienie osoby rozpoczynającej działalność prawie zerową jest trudne, szczególnie w krótkim czasie, ale widziałem to w kilku krytycznych projektach. Koszty ich wynajmu były jednak dość wysokie.
dasblinkenlight
Zrobię trochę badań, ale doświadczony konsultant może być trudny do znalezienia w mojej okolicy. Czy uważasz, że można by współpracować z kimś z innego miasta? A może odległość dalej spowolniłaby ten proces?
lortabac
3
Wydaje mi się, że prawo Brook dotyczy również doświadczonego konsultanta, więc nie sądzę, że będzie to realne rozwiązanie problemu.
Doc Brown
@lortabac Zdalne dodanie kogoś do pracy z tobą prawdopodobnie spowolni. Jak elastyczni są sponsorzy w przycinaniu wymagań dotyczących dodatkowego modułu? Możesz poprosić ich o posortowanie nowych funkcji w kolejności ich ważności i zdecydowanie, jakie jest absolutne minimum wymagań, które musisz wdrożyć, aby wydarzenie miało sens. Jeśli nie możesz dostać „strażaka” lokalnie, zmniejszenie zakresu może być dobrym planem awaryjnym.
dasblinkenlight,
14

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).

Buhb
źródło
4
+1. Mimo wszystkich dobrze przemyślanych, wyżej głosowanych innych sugestii, myślę, że to prawdopodobnie jedyna rzecz, która naprawdę zadziała w takiej sytuacji.
Doc Brown,
Zgadzam się z całego serca. Jeśli masz jeszcze dwa miesiące i myślisz o zatrudnieniu kogoś teraz, niewiele zyskasz na nowym zatrudnieniu. O ile nie masz fantastycznego szczęścia lub myślisz już o kimś kompetentnym, albo zmarnujesz dwa miesiące na szukanie (i obniżanie własnej wydajności), albo na zatrudnienie kogoś, kto tylko pogorszy sytuację. Nie spiesz się z zatrudnieniem.
jmk,
10

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).

DeveloperDon
źródło
Ta książka jest trochę droga, ale zamierzam ją sprawdzić.
Green
Możesz znaleźć fragmenty książek, o których wspominałem online, być może za pośrednictwem książek Google. Pożyczyłem zarówno książki Brooks, jak i Coplien za pośrednictwem lokalnej biblioteki uniwersyteckiej.
DeveloperDon
6

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.
Zielony
źródło
być może określ obszary, które wymagają pracy, i pozwól nowej osobie rozpocząć od napisania testów dla istniejącego kodu, aby pomóc w zrozumieniu systemu, zanim zaczniesz go zmieniać / dodawać do niego.
StevenV
@StevenV to doskonały, doskonały pomysł. Pisanie testów dla nieznanych komponentów pozwoli ci bardzo szybko się z nimi zapoznać. A system jest bardziej testowalny, kiedy skończysz. :)
Zielony,
5

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ół.

Ralff
źródło
3

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.

HLGEM
źródło
3

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;)

Marc Paradise
źródło
Kilka dni po opublikowaniu tego pytania opuściłem firmę. Jak słusznie zauważyły ​​niektóre komentarze na temat Ars Technica, istniały głębsze problemy, o których nie wspomniałem w pytaniu. Chciałem tylko uzyskać opinię na ten temat.
lortabac,
2

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ą.

JB King
źródło
2

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.

David Barton
źródło