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

38

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

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

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

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

Кристиан П
источник
2
В ProjectManagement StackExchange есть вопрос по этому поводу. Знаете ли вы какие-либо компании, которые регулярно
Спойк
2
Я не хотел превращать это в субъективный / спорный вопрос, высказывая свое личное мнение по этому вопросу. У меня такое ощущение, что это не очень хорошая идея, но, может быть, есть кое-что, о чем я не знаю :)
Кристиан П
1
Какую причину дал менеджер, когда вы спросили его, почему? В интересах компании делиться знаниями о продукте на случай, если разработчики уйдут.
dcaswell
1
Это проблема. Если ваше руководство еще не совсем прозрачно по этому поводу, то это, вероятно, признак того, что они вообще не продумали это.
Аарона
1
Я хотел бы предложить, чтобы вы создали команду, которая запускает проект, состоящую из текущих разработчиков и некоторых новых разработчиков проекта. Держите их в курсе. В конце концов, разработчики lagacy поддерживают новый продукт, и новые разработчики присоединяются к другим разработчикам предыдущих версий для выполнения следующего проекта. Таким образом, команда работает над проектом (или основным выпуском), но унаследованные люди быстро понимают, что они будут поддерживать позже. Новые сотрудники, как правило, начинают работать по наследству, если у них нет специальных навыков, которых у вашей команды нет в проекте.
HLGEM

Ответы:

76

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

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

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

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

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

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

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

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

Aaronaught
источник
2
Не соглашайтесь полностью - однако это не без его недостатков - Команды могут и делают построенные империи, иногда эта рушащаяся Производительность не всегда является самой важной целью яслях, которые (если хорошо) смотрят больше на конечную игру, чем другой может быть.
Mattnz
4
@mattnz: Какая «конечная игра» существует для менеджера, кроме высокой производительности, удержания сотрудников и возможности доставки вовремя / в рамках бюджета? Разумеется, я говорю об этических менеджерах, которые искренне хотят делать то, что лучше для компании, и не используют команду или проект в качестве средства достижения своих личных карьерных целей. Программная организация хочет империи - империи стабильны и зарабатывают деньги - и да, империи могут падать, но вероятность их падения гораздо меньше, чем карточный домик.
Аарона
2
ротация лучше, чем люди, покидающие компанию полностью
Уоррен
4
@ Warren: Если эти два варианта являются вашими единственными, то последний почти неизбежен.
Аарона
3
Я серьезно не понимаю этот ответ вообще. Все в команде должны быть профессионалами и хорошо работать с другими, предполагая, что все члены команды действительно компетентны, что является другой проблемой. Чередование членов команды часто является единственным выбором для менеджера, который хронически недоукомплектован в обоих продуктах или когда истощение представляет серьезную угрозу. Часто очень трудно найти хороший талант. Вращение членов команды - это способ застраховаться от ухода разработчиков. Это также более справедливо для разработчиков, работающих над устаревшим программным обеспечением, когда они хотят узнать что-то новое.
maple_shaft
18

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

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

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

Уайетт Барнетт
источник
18
Я не вижу, как мой моральный дух улучшился бы, если бы меня «понизили в должности», чтобы работать в устаревшей системе.
Теластин
3
Несколько недостатков заключаются в том, что время начальной разработки возрастает, а конкретные задачи старой команды получают более низкие приоритеты.
Передано
16
@Telastyn Если бы моя старая компания перестала работать, я бы все равно работал там. Конечно, это отстой, когда его вращают, но еще больше отстой, чтобы знать, что вас никогда не свернут просто потому, что им нужен унаследованный разработчик.
БородатыйO
8
@Telastyn and Christian и другие: это ваша проблема, если вы считаете это понижение в должности. Работа над устаревшими системами сама по себе является проблемой, которая может дать вам невероятно бесценный опыт для использования в ваших интересах в разработке экологически чистых месторождений. У разработки Greenfield действительно должно быть гораздо меньше «доверия», чем у нее, поскольку это намного проще, чем пытаться создавать новые функции на существующей базе, даже если у нее нет большого технического долга. Разработка месторождения Браун - это место, где вы найдете настоящих мастеров и женщин. Да, вы найдете их и в других местах, но не на поле боя.
Марьян Венема
8
@MarjanVenema - Извините, некоторые работы по техническому обслуживанию в Коболе не улучшат мою карьеру. Конечно, работа, возможно, должна быть сделана, и это может быть даже ценный опыт - но если мой менеджер переведет меня на этот полный рабочий день, я получу свое резюме как можно скорее. Дело в том, что некоторые разработчики будут воспринимать это как понижение в должности, независимо от того, что он на самом деле. Сбалансировать это восприятие с желанием перекрестной пыльцы - это не моя проблема, это проблема менеджера; это их работа .
Теластин
6

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

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

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

  • Лучшее управление проектом. Если руководители обоих проектов находятся на борту, то в их интересах работать, чтобы переходные периоды не были болезненными для обоих проектов. Этот поворот (в зависимости от вашей настройки) может привести к более тесному сотрудничеству между руководителями и командами разработчиков.
  • Лучшая (проактивная) документация. Если вы знаете, что вас вовлекают в проект и выходят из него, это не только отвечает интересам проекта, интересам компаний, наилучшей практике в целом, но теперь каждый разработчик заинтересован в том, чтобы облегчить жизнь, пока они подпрыгивают. около.
  • Мораль очень важна: если вашим разработчикам не хватит застревать в унаследованном проекте, они могут оказаться не теми разработчиками, которых вы хотите! Если они это сделают, переключив их и заставив других разработчиков поработать над этим, они почувствуют любовь к вашей компании - они просто могут привести в порядок фрагменты кода, которые, как они думали, никто и никогда не увидит. Устаревшие системы часто рассматриваются как проекты второго сорта, что часто наносит им ущерб, может быть, таким образом вы поможете изменить это восприятие.
JohnMark13
источник
Я думаю, что так оно и есть в большинстве компаний. Высокие цели, но требования быстрого оборота и минимального немедленного избежания затрат обычно исключают возможность перекрестного обучения и перекрестного развития из-за потери производительности при привлечении кого-то нового к скорости в проекте.
BBlake
2
@BBlake Да, к сожалению, это так. К сожалению, потому что это очень недальновидный и довольно высокий риск для компании «ограничить» знание важных систем меньшим числом людей.
Марьян Венема
1
К сожалению, большинство предприятий, в том числе крупнейший всемирный банк, который я недавно оставил работать в другом месте, больше заинтересованы в итоговых результатах этого проекта, недели или бюджетного цикла, чем в планировании расходов, которые возникнут, когда старший разработчик ( такой как я) уходит. Без бюджета на кросс-тренинг только по приложениям, с которыми я хорошо знал. Добавьте десятки рабочих часов, потраченных на отслеживание производственных проблем, которые я мог бы решить за пару часов, потому что я знал системы. Недальновидно, но это корпоративный путь.
BBlake
@Marjan: Я был бы готов поспорить, что затраты, связанные с необходимостью проводить кросс-тренинг на регулярной основе, будут намного, намного выше, чем затраты на обучение нового найма по мере необходимости, если кто-то уйдет. Теперь, если уйдет целая команда, тогда это другое дело.
Данк
1
@ Данк: я не знаю, что будет. Кросс-тренинг не должен идти так далеко, чтобы сделать кросс-тренинг экспертом в области, которая не является его собственной. Нужно лишь зайти так далеко, чтобы гарантировать, что бизнес не будет в разгаре и рискует потерять клиентов, когда выезжают полевые эксперты, что приводит к остановке разработки в этой области. Никто не незаменим, но бизнес «рискует, когда важные знания или навыки ограничены очень немногими людьми. И цена того, что этот риск станет реальностью, может быть очень, очень высокой.
Марьян Венема
4

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

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

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

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

Ozz
источник
Мне нравится идея замены всего 1-2 разработчиков для начала. Это поможет уменьшить первоначальное негативное влияние на производительность.
СуперМ
Вы имеете дело с разработчиками программного обеспечения, а не с нормальными людьми. Разработчики программного обеспечения, как правило, логичны. Им нельзя манипулировать так же легко, как и широкой публике, внедряя идеи, подобные приведенным выше. Другие уловки более эффективны на них (например, большие мониторы, более быстрые компьютеры), но не политический обман, как пытается эта идея. Это будет негативно для тех, кто в новой команде разработчиков, несмотря ни на что. Обещания вознаграждений (т.е. см. Выше) - это единственный способ скрыть дурной вкус. Конечно, это будет здорово (сначала) для парней из мэйнта, пока они не поймут, что они не готовы.
Данк
2

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

Дайниус
источник
этот пост довольно трудно читать (стена текста). Не могли бы вы изменить его в лучшую форму?
Комнат
2

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

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

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

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

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

Мартин Маат
источник
0

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

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

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

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

dietbuddha
источник
1
«Пока команда не слишком большая», я думаю, это ключевой момент. если в каждой команде по 10 человек, то команда из 20 человек, скорее всего, слишком большая. Кроме того, если есть какое-либо физическое разделение между командами (ОП не указывает), то оно не будет функционировать как одна команда и сделает вещи более дезорганизованными. Это, безусловно, может сработать, но это зависит от ситуации (могут ли команды быть эффективно объединены), а также от целей руководства (объединение более или менее постоянно, оно добавит больше ресурсов, но не достигнет тех же целей, что и проект вращение).
Аарона,
0

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

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

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

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

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

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

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

Прагнеш Кария
источник
3
Я вижу здесь много лысых утверждений. Некоторые из них почти не имеют ничего общего с ротацией («руководство узнает о силе и слабости конкретного разработчика»?), Другие либо неловко сформулированы, либо просто не имеют смысла («все члены команды работают в команде и это повысит производительность проекта "?). На чем основаны все эти пункты? У тебя есть источник? Это личный опыт? Если да, то какой опыт? Ваша «перспектива компании» основана на опыте менеджера или руководителя команды? Вы действительно видели, как что-то из этого работает на практике?
Aaronaught
1
Кажется, что большинство из этих предлагаемых преимуществ действительно связаны с тем, чтобы просто быть в команде, а не вращаться между командами ...
Aaronaught
Первый «Менеджмент узнает, сильные и слабые стороны конкретного разработчика». на самом деле наоборот, потому что гораздо легче скрыть свои слабости, когда вы перемещаетесь из одного места в другое, всегда есть больше людей / программного обеспечения, чтобы обвинить, почему это было поздно, глючит, не сделано.
Дайний,
Нельзя сказать, что на производительность проекта это не окажет негативного влияния. С какой стати вы верите, что эффективность проекта будет «улучшена»?
Данк