Я здивований, що всі думають, що це така гарна річ. Автори Peopleware (який, IMO, як і раніше є однією з найцінніших книг управління проектами програмного забезпечення, які насправді варто прочитати) категорично не погоджуються. Майже вся частина IV книги присвячена саме цій проблемі.
Програмне забезпечення команда є неймовірно важливим функціональним блоком. Командам потрібно заграти, щоб стати справді продуктивними. Потрібен час ( багато часу), щоб члени команди заслужили повагу один одного, вивчили звички та примхи один одного, сильні та слабкі сторони.
Звичайно, з особистого досвіду можу сказати, що після року роботи з певними людьми я навчився сміятися з певних речей, які звикли мене змушувати, мої оцінки керівництва команди набагато кращі, і це не дуже складно розподіліть роботу так, щоб зробити всіх щасливими. На початку це було не так.
Тепер ви можете сказати: "О, але ми не розбиваємо всю команду, просто переїжджаємо кілька людей". Але подумайте (а) про те, наскільки сліпо непродуктивними будуть їх заміни на початку, і (б) скільки разів ви виявите себе чи інші команди, говорячи, навіть не замислюючись: "Мені дуже сподобався X" або "Це було б було легше з Y все ще навколо " , тонко і несвідомо ображаючи нових членів і створюючи розколи в межах існуючої команди, навіть сіяючи невдоволення серед" старих "членів.
Люди не роблять цього навмисне , звичайно, але це трапляється майже кожен раз. Люди роблять це, не замислюючись. І якщо вони змушують себе цього не робити, вони в кінцевому підсумку зосереджуються на цьому питанні ще більше і розчаровуються вимушеною тишею. Команди і навіть підгрупи розробитимуть синергію, яка втрачається, коли ви обертаєтесь структурою. У Кадрових авторів називають його формою «teamicide».
Незважаючи на те, що навіть ротація членів команди є жахливою практикою, обертання самих команд - це прекрасно. Хоча добре керовані компанії з програмного забезпечення повинні мати певну концепцію права власності на продукт, команда не є такою руйнівною для того, щоб перенести всю команду на інший проект, доки команда насправді має змогу закінчити старий проект або принаймні довести його до рівень, яким вони задоволені.
Маючи команду, замість стику розробника , ви отримуєте всі ті ж переваги, які ви б очікували отримати від розробників, що обертаються (документація, «перехресне запилення» тощо) без будь-яких негативних побічних ефектів для кожної команди як підрозділу. Тим, хто насправді не розуміє менеджмент, це може здатися менш продуктивним, але будьте впевнені, що продуктивність, втрачена в результаті розколу команди, повністю придушує продуктивність, втрачену при переміщенні команди на інший проект.
PS У своїй примітці ви згадуєте, що технічний провід може бути єдиною людиною, яку не слід повертати. Це майже гарантовано зіпсує обидві команди. Технічний керівник - це лідер, а не менеджер, він або вона мусить заслужити повагу колективу, і не просто надається повноваження вищими рівнями управління. Поставити цілу команду під керівництвом нового керівника, з яким вони ніколи не працювали, і який, швидше за все, матиме різні ідеї щодо таких речей, як архітектура, зручність використання, організація коду, оцінка ... ну, це буде напружено, як пекло для керівника, який намагається створити авторитет і дуже непродуктивний для членів команди, які починають втрачати згуртованість за відсутності свого старого керівництва. Іноді компанії єробити це, тобто, якщо ведучий припиняє або отримує підвищення, але робити це за вибором звучить божевільно.