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.