Является ли ротация разработчиков проекта хорошей или плохой идеей?

Я работаю в небольшой команде, которая начнет работать над большим новым проектом с другой небольшой командой. Другая команда в настоящее время работает над устаревшей системой, над которой они работают годами.

Менеджер решил, что разработчики из моей команды будут заменять разработчиков, работающих над устаревшей системой, каждые несколько месяцев. Таким образом, у другой команды будет возможность поработать над новым проектом и лучше понять новую систему.

Я хочу знать о преимуществах и недостатках (если таковые имеются) ротации разработчиков из проекта каждые 2-3 месяца.

Я знаю, что этот вопрос похож на вопрос "Является ли ротация ведущего разработчика хорошей или плохой идеей?" , но этот вопрос касается ведущего разработчика. Это вопрос о включении и выключении всей команды (технический руководитель для нового проекта может или не может быть повернут - пока не знаю).

Я удивлен, что все думают, что это такая хорошая вещь. Авторы Peopleware (которая, по мнению IMO, до сих пор является одной из немногих ценных книг по управлению программными проектами, которые стоит прочитать), категорически не согласны. Этой проблеме посвящена почти вся четвертая часть книги.

Программное обеспечение команда является невероятно важным функциональным блоком. Команды должны желе, чтобы стать действительно продуктивным. Членам команды требуется время ( много времени), чтобы заслужить уважение друг друга, выучить привычки, причуды и сильные и слабые стороны друг друга.

Конечно, по личному опыту я могу сказать, что после года работы с определенными людьми я научился смеяться над некоторыми вещами, которые меня раздражали, мои оценки как руководителя команды намного лучше, и это не так уж сложно распределите работу так, чтобы все были счастливы. Это было не так в начале.

Теперь вы можете сказать: «О, но мы не разбиваем всю команду, а просто перемещаем несколько человек». Но подумайте (а) о том, насколько слепо непродуктивными будут их замены в начале, и (б) сколько раз вы обнаружите, что вы или другие команды говорят, даже не задумываясь: «Мне действительно понравился Х» или «Это было легче с Y все еще вокруг " , тонко и неосознанно оскорбляя новых участников и создавая расколы в существующей команде, даже сея недовольство среди" старых "участников.

Конечно, люди делают это не специально , но это происходит почти каждый раз. Люди делают это, не задумываясь. И если они заставляют себя не делать этого, они в конечном итоге сосредотачиваются на проблеме еще больше и разочаровываются из-за вынужденного молчания. Команды и даже подгруппы будут развивать синергию, которая теряется, когда вы возитесь со структурой. Авторы Peopleware называют это формой «командного действия».

При этом, хотя ротация членов команды - ужасная практика, сами ротации команд - это прекрасно. Хотя хорошо разработанные компании-разработчики программного обеспечения должны иметь некоторую концепцию владения продуктом, для команды не так сложно подвести всю команду к другому проекту, если команда действительно заканчивает старый проект или, по крайней мере, доводит его до уровень, которым они довольны.

При наличии команды попадали вместо разработчика попадал, вы получите все то же преимущество , которые вы ожидаете получить с вращающимися разработчиками (документацию, «перекрестное опыление», и т.д.) без какого - либо неприятных побочных эффектов в каждой команде как единое целое. Для тех, кто не совсем понимает управление, это может показаться менее продуктивным, но будьте уверены, что потеря производительности при разделении команды полностью снижает производительность при переносе этой команды в другой проект.

PS В вашем примечании вы упоминаете , что технология свинец может быть только человек не должен вращаться. Это в значительной степени гарантированно испортит обе команды. Техническим лидером является лидер, а не менеджер, он или она должен заслужить уважение команды, а не просто получает авторитет от более высоких уровней управления. Помещение целой команды под руководством нового лидера, с которым они никогда не работали и который, скорее всего, будет иметь разные представления о таких вещах, как архитектура, удобство использования, организация кода, оценка ... ну, это будет чертовски напряженно за лидерство, пытающееся построить доверие и очень непродуктивное для членов команды, которые начинают терять сплоченность в отсутствие их старого лидерства. Иногда компании имеютсделать это, то есть, если лидерство уходит или продвигается, но делать это по выбору звучит безумно.

Я не вижу здесь большого недостатка. Вращение дает вам:

• Перекрестное опыление институциональных знаний - каждый будет знать унаследованный и новый проекты, по крайней мере, в теории.
• Перекрестное обучение - разные проекты часто требуют разных вещей. Вы становитесь гораздо больше как разработчик, работающий в некрасивых, устаревших проектах, чем в хороших, чистых проектах с нуля.
• Фундаментально лучшие проекты - совсем не то, что приходит новая команда, которая заставит вас закончить документирование и убрать уродливые процессы, с которыми вы готовы жить, но не признаетесь публично.
• Чем лучше код, тем лучше головы в большинстве случаев.
• Скорее всего, улучшение морального состояния - разнообразие - это специя жизни. А кто хочет навсегда застрять в исправлении ошибок в старом проекте? Также имейте в виду, что ваш «новый» проект в какой-то момент станет наследием, вы хотите остаться там навсегда?

Вероятно, единственным недостатком является падение производительности, которое вы получаете от смены мест, но это должно только повредить с первого раза. После этого обе стороны будут иметь некоторое время для сидения в обоих местах, и уродливые части передачи обслуживания, вероятно, будут лучше поняты и, возможно, решены.

Интересно, что по моему опыту мы часто начинали наши проекты именно с этой целью. Внизу мы часто не могли действовать в этом направлении из-за ограничений нового проекта и убежденности в том, что перекрестное обучение слишком дорого.

Я всегда хотел бы, чтобы мы справились с этим, хотя в долгосрочной перспективе я считаю, что это выгодно всем сторонам - команде, компании, клиенту и программному обеспечению. 2/3 месяца звучат как достаточно продолжительный период, когда риск какого-либо серьезного негативного воздействия ограничен, для вовлеченных разработчиков не происходит переключения контекста, кроме как в момент перехода, когда они могут посвятить себя альтернативному проекту.

Пара возможных преимуществ, не упомянутых:

• Лучшее управление проектом. Если руководители обоих проектов находятся на борту, то в их интересах работать, чтобы переходные периоды не были болезненными для обоих проектов. Этот поворот (в зависимости от вашей настройки) может привести к более тесному сотрудничеству между руководителями и командами разработчиков.
• Лучшая (проактивная) документация. Если вы знаете, что вас вовлекают в проект и выходят из него, это не только отвечает интересам проекта, интересам компаний, наилучшей практике в целом, но теперь каждый разработчик заинтересован в том, чтобы облегчить жизнь, пока они подпрыгивают. около.
• Мораль очень важна: если вашим разработчикам не хватит застревать в унаследованном проекте, они могут оказаться не теми разработчиками, которых вы хотите! Если они это сделают, переключив их и заставив других разработчиков поработать над этим, они почувствуют любовь к вашей компании - они просто могут привести в порядок фрагменты кода, которые, как они думали, никто и никогда не увидит. Устаревшие системы часто рассматриваются как проекты второго сорта, что часто наносит им ущерб, может быть, таким образом вы поможете изменить это восприятие.

Ротация - это хорошая вещь для компании, и она может быть полезной и для разработчиков.

Есть много веских причин, и Уайетт упомянул многие из них в своем ответе.

Тем не менее, в вашей ситуации вы можете обнаружить, что, представляя эту идею, разработчики, которые переходят от более нового проекта к устаревшему проекту, могут быть недовольны, поэтому необходимо четко понимать, почему это происходит и как долго это происходит. для, и план идет вперед.

Возможно, было бы неплохо подумать о том, чтобы не менять местами команды для начала и вращать 1 или 2 разработчика для начала, хотя это может показаться выделением людей для понижения в должности (что некоторые люди могут увидеть).

Согласитесь с Aaronaught, что очень странно видеть, сколько людей просто не видят недостатков. Мало кто думает, что вы можете указать очень быстро - у кода нет владельца, и когда все отвечают за все, это не так хорошо для качества. , Разработчики - это не ресурсы (даже так их очень часто называют менеджеры), они люди, и для команды очень важно знать друг друга, ротация там создает хаос. Если вы работаете над каким-то проектом в течение более длительного времени, вы станете экспертом (не только в области, но и в этом проекте), вы будете знать, откуда возникло большинство проблем, кто даст вам лучшие ответы или, возможно, более конкретные знания в области и т. Д. Если вы новичок, вам нужно будет научиться всему этому мыслить, поэтому это замедлит прогресс. Но, конечно, также хорошо знать другие практики в вашей организации, как другие команды строят и организуют. Это особенно хорошо, если ваши проекты связаны каким-либо образом, например, один проект является входом для другого (не обязательно напрямую), так что вы получите лучшее понимание общей картины. И конечно, распространение знаний - это хорошо (если у вас будет время, чтобы получить эти знания).

Я согласен с главным ответом Аарона, и у меня есть некоторые дополнения.

• Люди не любят, когда их толкают.
• В иерархической бизнес-среде людям могут быть назначены обязанности, которые впоследствии снова отнимаются у них. Это может быть просто частью работы. Однако чем чаще это происходит, тем меньше вероятность того, что эти люди будут чувствовать ответственность за все, что им поручено.
• Первый пункт также относится к работам по техническому обслуживанию вещей, которые сами люди не создавали. Устранение беспорядка других людей (или более нейтрально сформулированного: незаконченная работа) не особенно мотивирует большинство творящих людей.
• Философия «программист - это программист, это программист, они являются анонимными подключаемыми модулями, которые нужно вставлять в проекты по мере необходимости», не дает программисту чувства признательности и не заботится о поставленных перед ним задачах.

Идеальное время для переназначения кого-либо - это когда им становится скучно от того, что они делают. Больше нечего получить, все под контролем, работа выполнена. В этих случаях они, как правило, выходят вперед и сами просят о других возможностях.

Конечно, реальность упряма, и часто выбора нет, кому-то может понадобиться где-то еще по любой причине. Это не обязательно плохо, это также может заставить человека чувствовать себя важным, и если человек хочет решить какую-то большую проблему, это будет ему заслуженно.

Просто перетасовка людей вокруг для распространения знаний, вероятно, увеличит оборот. Таким образом, знания будут распространяться, но распространяться за пределы компании, что, вероятно, не является целью.

TL; DR Создайте одну команду, а затем одну команду, поддерживающую 2 проекта.

В заключение @Aaronaught Я думаю, что микширование может быть проблематичным, так как может потребоваться время, чтобы привыкнуть к новым практикам, процессам и т. Д. Если вы вращаете слишком много людей, чтобы быстро команда потеряет свою индивидуальность. Это приводит к большему количеству вопросов, путаницы и времени, потраченного на то, чтобы наверстать упущенное.

С другой стороны, если предпринимаются согласованные усилия для объединения двух команд в одну команду и поддержки одной команды для двух проектов, я думаю, что это прекрасно работает, если команда не слишком большая. Я был частью многочисленных команд, которые поддерживают несколько проектов. Чем ближе в технологии два проекта, тем легче переход. По моему опыту, более высокая стоимость перехода от одного проекта к другому возникает при пересечении языков, клиента / сервера (особенно GUI), отрасли (медицина, Интернет, игра) или других подобных линий. Хитрость заключается в том, чтобы заставить разных людей работать над проектом достаточно часто, чтобы получить выгоды, но не так часто, чтобы стоимость перехода превышала выгоды.

Тогда выгоды от привлечения большего количества людей к проекту довольно хорошо известны, равно как и затраты.

Вращение программистов - хорошая вещь с точки зрения компании и разработчика.

С точки зрения компании

1. Руководство узнает, сильные и слабые стороны конкретного разработчика, могут ли они справиться с многозадачностью или нет и могут ли они адаптироваться к изменениям.
2. Если какой-то разработчик по какой-либо причине покидает компанию, у компании уже есть резервная копия, готовая к будущему.
3. Это повысит производительность проекта, так как над ним будет работать много людей, то же самое проверяют все больше и больше разработчиков. (Тестирование потерь ресурсов сведено к минимуму)
4. Все члены команды работают в команде, и это повысит производительность проекта, и в будущем руководство узнает, какую команду нужно создать при реализации сложного модуля или задачи.

С точки зрения разработчика

1. Это сделает разработчика более позитивным, поскольку его уверенность возрастает.
2. Разработчики получают все лучшие и лучшие идеи из кода других товарищей по команде, и они могут использовать эту технику в будущих разработках.
3. От лучших идей и предложений от других членов команды производительность разработчика увеличивается.

Только одно главное, нужно помнить, что

Вращение программистов не должно происходить очень часто. после 60% - 70% развития, тогда только сдвиг будет выгоден.