Czy rotacja programistów w projekcie jest dobrym czy złym pomysłem?

Pracuję w małym zespole, który rozpocznie pracę nad dużym nowym projektem z innym małym zespołem. Drugi zespół pracuje obecnie nad starszym systemem, nad którym pracują od lat.

Menedżer postanowił, że programiści z mojego zespołu będą się zmieniać co kilka miesięcy, zastępując programistów pracujących nad starszym systemem. W ten sposób drugi zespół będzie miał szansę pracować nad nowym projektem i lepiej zrozumieć nowy system.

Chcę poznać zalety i wady (jeśli w ogóle) rotowania programistów z projektu co 2-3 miesiące.

Wiem, że jest to podobne pytanie do „Czy obracanie głównego programisty to dobry czy zły pomysł?” , ale to pytanie dotyczy wiodącego programisty. To pytanie dotyczy włączania i wyłączania całego zespołu w projekcie (kierownik techniczny nowego projektu może, ale nie musi, zostać obrócony - jeszcze nie wiem).

Dziwi mnie, że wszyscy myślą, że to dobra rzecz. Autorzy Peopleware (która, IMO, wciąż jest jedną z niewielu cennych książek na temat zarządzania projektami oprogramowania, które naprawdę warto przeczytać), zdecydowanie się nie zgadzają. Prawie cała część IV książki poświęcona jest właśnie temu zagadnieniu.

Oprogramowanie zespół jest niezwykle ważna jednostka funkcjonalna. Zespoły muszą jellować, aby stać się naprawdę produktywnym. Członkowie zespołu potrzebują czasu ( dużo czasu), aby zdobyć wzajemny szacunek, poznać nawyki i dziwactwa, mocne i słabe strony.

Oczywiście z własnego doświadczenia mogę powiedzieć, że po roku pracy z niektórymi ludźmi nauczyłem się śmiać z pewnych rzeczy, które mnie wkurzały, moje szacunki jako kierownika zespołu są znacznie lepsze i nie jest to zbyt trudne rozłóż pracę tak, aby wszyscy byli zadowoleni. Na początku tak nie było.

Teraz możesz powiedzieć: „Och, ale nie dzielimy całego zespołu, po prostu przenosimy kilka osób”. Ale zastanów się (a) jak ślepo bezproduktywne będą ich zastępstwa na początku i (b) ile razy znajdziesz siebie lub inne zespoły, które nawet nie zastanawiają się „Naprawdę lubię X” lub „To by było było łatwiej, gdy Y wciąż był w pobliżu ” , subtelnie i nieświadomie obrażając nowych członków i tworząc schizmy w istniejącym zespole, a nawet siejąc niezadowolenie wśród„ starych ”członków.

Oczywiście ludzie nie robią tego celowo , ale dzieje się tak prawie za każdym razem. Ludzie robią to bez zastanowienia. A jeśli zmuszą się, by tego nie robić, ostatecznie skupią się na tym problemie i są sfrustrowani wymuszoną ciszą. Zespoły, a nawet podgrupy będą tworzyć synergie, które gubią się, gdy przekręcasz się przy konstrukcji. W Peopleware autorzy nazywają to forma „teamicide”.

To powiedziawszy, mimo że rotacja członków zespołu jest okropną praktyką, same rotacje drużyn są w porządku. Chociaż dobrze zarządzane firmy programistyczne powinny mieć pojęcie o własności produktu, przeniesienie całego zespołu do innego projektu nie jest tak uciążliwe, o ile zespół faktycznie ukończy stary projekt lub przynajmniej doprowadzi go do końca poziom, z którego są zadowoleni.

Poprzez zespołu przejazdów zamiast deweloperskich przejazdów, można uzyskać wszystkie te same korzyści, jakie można uzyskać z obrotowymi deweloperom (dokumentacja, „zapylanie krzyżowe”, etc.) bez żadnych nieprzyjemnych skutków ubocznych w każdej drużynie jako jednostki. Dla tych, którzy tak naprawdę nie rozumieją zarządzania, może to wydawać się mniej produktywne, ale bądźcie pewni, że wydajność utracona przez podział zespołu całkowicie przewyższa wydajność utraconą przez przeniesienie tego zespołu do innego projektu.

PS W przypisie wspominasz, że lider technologiczny może być jedyną osobą, której nie można obrócić. Jest to prawie pewne, że zepsuje obie drużyny. Kierownik techniczny jest liderem, a nie menedżerem, on lub ona musi zdobywać szacunek zespołu i nie jest po prostu upoważniony przez wyższe poziomy zarządzania. Objęcie całego zespołu kierownictwem nowego lidera, z którym nigdy nie współpracowali i który prawdopodobnie będzie miał różne pomysły na takie tematy jak architektura, użyteczność, organizacja kodu, szacowanie ... no cóż, będzie to stresujące jak diabli dla lidera, który stara się budować wiarygodność i jest bardzo nieproduktywny dla członków zespołu, którzy zaczynają tracić spójność w przypadku braku starej linii. Czasami firmy majązrobić to, tj. jeśli lead zrezygnuje lub zostanie awansowany, ale robienie tego z wyboru brzmi szalenie.

Sam nie widzę tu wiele wad. Rotacja zapewnia:

• Zapylenie krzyżowe instytucjonalnej wiedzy - wszyscy będą znali dotychczasowy projekt i nowy, przynajmniej teoretycznie.
• Szkolenie krzyżowe - różne projekty często wymagają różnych rzeczy. Rosniesz znacznie bardziej jako programista pracujący w brzydkich, starszych projektach niż w ładnych, czystych projektach typu greenfield.
• Fundamentalnie lepsze projekty - niczym więcej niż przyjęcie nowego zespołu, który sprawi, że dokończysz dokumentację i oczyścisz brzydkie procesy, z którymi jesteś gotów żyć, ale nie przyznajesz się do nich publicznie.
• Lepszy kod - więcej głów jest lepszych w większości przypadków.
• Prawdopodobne polepszenie morale - różnorodność jest przyprawą życia. I kto chce utknąć na stałe w trybie naprawiania błędów / tapingu kanałów projektu. Pamiętaj też, że w pewnym momencie twój „nowy” projekt stanie się dziedzictwem, czy chcesz utknąć w nim na zawsze?

Prawdopodobnie jedynym minusem jest spadek produktywności wynikający z zamiany miejsc, ale to powinno tylko zaszkodzić przy pierwszym okrążeniu. Następnie obie strony będą miały trochę czasu w obu miejscach, a brzydkie części przekazania zostaną prawdopodobnie lepiej zrozumiane i być może rozwiązane.

Co ciekawe, z mojego doświadczenia często zaczynaliśmy nasze projekty z taką samą intencją. W dalszej kolejności często nie działaliśmy zgodnie z tym celem ze względu na ograniczenia w nowym projekcie i przekonanie, że szkolenie krzyżowe jest zbyt drogie.

Zawsze jednak żałuję, że nam się nie udało, ponieważ uważam, że jest to korzystne dla wszystkich stron - zespołu, firmy, klienta i oprogramowania. 2/3 miesięcy wydaje się wystarczająco długim okresem, że ryzyko wystąpienia poważnego negatywnego wpływu jest ograniczone, nie ma możliwości zmiany kontekstu dla zaangażowanych deweloperów, z wyjątkiem momentu przejścia na zmianę, w którym mogą poświęcić się projektowi alternatywnemu.

Kilka możliwych korzyści, o których nie wspomniano:

• Lepsze zarządzanie projektem. Jeśli kierownicy projektu dla obu projektów są na pokładzie, w ich najlepszym interesie jest ciężka praca, aby okresy przejściowe nie były bolesne dla żadnego projektu. Ta kolej (w zależności od konfiguracji) może doprowadzić do ściślejszej współpracy między kierownikami projektów i zespołami programistycznymi.
• Lepsza (proaktywna) dokumentacja. Jeśli wiesz, że włączasz się i wyłączasz z projektu, leży to nie tylko w najlepszym interesie projektu, w najlepszym interesie firm, ogólnie w najlepszych praktykach, ale teraz w interesie każdego dewelopera jest ułatwienie życia podczas odbijania się na około.
• Morale to wielka sprawa, jeśli twoi programiści nie mieli dość utknięcia w starszym projekcie, mogą nie być programistami, których chcesz! Jeśli tak, przełączanie ich i zachęcanie innych programistów do pracy nad nimi sprawi, że poczują miłość do Twojej firmy - mogą po prostu uporządkować fragmenty kodu, których, jak sądzili, nikt jeszcze nie zobaczy. Starsze systemy są często postrzegane jako projekty drugiej kategorii, co często jest na ich niekorzyść, być może w ten sposób pomożesz zmienić to postrzeganie.

Rotacja to dobra rzecz dla firmy i może być również dobra dla programistów.

Istnieje wiele dobrych powodów i Wyatt wspomniał o wielu z nich w swojej odpowiedzi.

Biorąc to pod uwagę, w twojej sytuacji może się okazać, że wprowadzając to, programiści, którzy przenoszą nowy projekt do starszego projektu, mogą nie być zadowoleni, więc musi być bardzo jasna komunikacja, dlaczego tak się dzieje i jak długo to trwa jest za, a plan idzie naprzód.

Dobrze jest pomyśleć o tym, aby nie zamieniać zespołów hurtowo na start i obracać 1 lub 2 programistami na początek, chociaż może to wydawać się wyróżniać ludzi dla degradacji (co niektórzy mogą to zobaczyć).

Zgadzam się z Aaronaught, że bardzo dziwnie jest widzieć, ilu ludzi po prostu nie widzi wad. Niewiele złych myśli, że można bardzo szybko wskazać - kod nie ma właściciela, a gdy wszyscy są odpowiedzialni za wszystko, nie jest tak dobre dla jakości . Deweloperzy nie są zasobami (nawet tak często nazywani przez menedżerów), są ludźmi i dla zespołu bardzo ważne jest, aby się poznawać, rotacja powoduje tam chaos. Jeśli pracujesz dla jakiegoś projektu przez dłuższy czas, staniesz się ekspertem (nie tylko w dziedzinie, ale w tym projekcie), będziesz wiedział, skąd pochodzi najwięcej problemów, kto udzieli ci najlepszych odpowiedzi, a może bardziej konkretnej wiedzy na temat domeny itp. Jeśli jesteś nowy, musisz nauczyć się wszystkich tych myśli, aby spowolnić postęp. Ale oczywiście dobrze jest też znać inne praktyki w swojej organizacji, jak budują i organizują inne zespoły. Jest to szczególnie dobre, jeśli twoje projekty są w jakiś sposób powiązane, na przykład jeden projekt jest wkładany do drugiego (niekoniecznie bezpośrednio), dzięki czemu lepiej zrozumiesz ogólny obraz. Oczywiście rozpowszechnianie wiedzy specjalistycznej jest dobre (jeśli zdobędziesz czas na zdobycie tej wiedzy).

Zgadzam się z najlepszą odpowiedzią Aaronaught i mam kilka dodatków.

• Ludzie nie lubią być popychani.
• W hierarchicznym otoczeniu biznesowym ludziom mogą zostać przypisane obowiązki, które później zostają im odebrane. To może być tylko część pracy. Jednak im częściej tak się dzieje, tym mniej prawdopodobne jest, że osoby te poczują się odpowiedzialne za wszystko, co zostanie im przypisane.
• Pierwszy punkt dotyczy również prac konserwacyjnych nad rzeczami, których sami ludzie nie stworzyli. Sprzątanie bałaganu innych ludzi (lub bardziej neutralnie sformułowane: niedokończona praca) nie jest szczególnie motywujące dla większości tworzących jednostek.
• Filozofia „programista jest programistą jest programistą, są anonimowymi wtyczkami, które można wstawiać do projektów w razie potrzeby”, nie sprawia, że ​​programiści czują się doceniani lub bardziej troszczą się o przydzielone mu zadania.

Idealnym momentem do zmiany przypisania jest moment, gdy znudzą się tym, co robią. Nie ma nic więcej do zyskania, wszystko jest pod kontrolą, praca jest wykonywana. W takich przypadkach zwykle zgłaszają się i proszą o inne możliwości.

Oczywiście rzeczywistość jest uparta i często nie ma wyboru, ktoś może być potrzebny gdzie indziej z jakiegokolwiek powodu. To niekoniecznie jest złe, może również sprawić, że dana osoba poczuje się ważna, a jeśli dana osoba rozwiąże jakiś duży problem, będzie za to zasługa.

Przerzucanie ludzi w celu rozpowszechniania wiedzy prawdopodobnie zwiększy obroty. W ten sposób wiedza zostanie rozpowszechniona, ale zostanie rozpowszechniona poza firmą, co prawdopodobnie nie jest intencją.

TL; DR Zrób z tego jeden zespół, a następnie jeden zespół wspierający 2 projekty.

Aby powtórzyć @Aaronaught, myślę, że mieszanie zespołów może być problematyczne, ponieważ może zająć trochę czasu, aby zaaklimatyzować się w nowych praktykach, procesach itp. Jeśli zmienisz zbyt wiele osób, aby szybko, zespół straci tożsamość. Prowadzi to do większej liczby pytań, zamieszania i czasu poświęconego na nadrobienie tej tożsamości.

Z drugiej strony, jeśli podejmowane są wspólne wysiłki, aby połączyć 2 zespoły w jeden zespół i mieć 1 zespół wspierający 2 projekty, myślę, że to działa świetnie, dopóki zespół nie jest zbyt duży. Należę do wielu zespołów, które wspierają wiele projektów. Im bliżej technologii są 2 projekty, tym łatwiejsze jest przejście. Z mojego doświadczenia wynika, że ​​wyższy koszt przejścia z jednego projektu do drugiego występuje podczas przechodzenia przez języki, klient / serwer (szczególnie GUI), przemysł (medyczny, internetowy, gry) lub inne podobne linie. Sztuczka polega na tym, aby inni ludzie pracowali nad projektem wystarczająco często, aby uzyskać korzyści, ale nie tak często, aby koszt przejścia przekraczał korzyści.

Zatem korzyści związane z pozyskaniem większej liczby osób przy projekcie są dość dobrze znane, podobnie jak koszty.

Rotacja programistów jest dobra z punktu widzenia firmy i dewelopera.

Z perspektywy firmy

1. Kierownictwo pozna siłę i słabość konkretnego dewelopera, czy poradzi sobie z wielozadaniowością, czy nie i dostosuje się do zmian.
2. Jeśli jakiś programista z jakiegoś powodu opuści firmę, firma już ma kopię zapasową gotową na przyszłość.
3. Zwiększy wydajność projektu, ponieważ wiele osób będzie nad nim pracować, to samo testuje coraz więcej programistów. (Testowanie zminimalizowania marnotrawstwa zasobów)
4. Wszyscy członkowie zespołu pracują w zespole, co zwiększy wydajność projektu, a w przyszłości zarządzanie dowie się, jaki zespół należy stworzyć podczas wdrażania trudnego modułu lub zadania.

Z perspektywy programisty

1. Sprawi, że deweloper będzie bardziej pozytywny wraz ze wzrostem jego zaufania.
2. Programiści otrzymują coraz lepsze pomysły od innych członków zespołu i mogą wykorzystać tę technikę w przyszłym rozwoju.
3. Lepsze pomysły i sugestie innych członków zespołu zwiększają produktywność programistów.

Tylko jedna główna rzecz, należy pamiętać, że

Rotacja programistów nie powinna zdarzać się zbyt często. po 60% - 70% opracowaniu, wtedy tylko zmiana będzie korzystna.