Каковы последствия ротации профессионалов между разными проектами при разработке программного обеспечения?

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

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

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

Заранее очень благодарен за все ответы.

Перефразировать ротацию разработчиков, чтобы «расколоть успешные команды»?
это вопрос об управлении проектами? Будет ли это больше по теме на рабочем месте. SE

Ответы (2)

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

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

Причины:

  • У вас мало опыта в целом или мало опыта в проекте. Во всех случаях вы не являетесь ключевым участником, и ваш выход из проекта не повлияет на его статус.
  • Когда вы не очень опытны и молоды, вы больше стремитесь изучать новые технологии. Менеджер может перевести вас на исследовательский проект, иногда не очень важный проект для проверки какой-то идеи и технологии.
  • В модели Offshore Software Development Center (OSDC) клиенты могут выбирать для работы самых опытных членов, и они не хотят и не позволят заменить своих текущих разработчиков другими, особенно когда я не знаю об опыте новых людей. .

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

Вернемся к моей истории: первый шаг был, когда я перешел из команды Php в команду ios. На самом деле в команде был только 1 участник – я. Компания, которая преуспевала в веб-технологиях, теперь хочет поэкспериментировать в новой области — мобильных приложениях. Я был молод, энергичен и очень быстро осваивал новые технологии, поэтому меня перевели в этот проект. Я продержался 6 месяцев и закончил проект. Опыт был весьма положительным – я узнал о мобильных технологиях, о которых у меня никогда не было возможности узнать, и мне очень понравилось.

2-й ход не лучший. После 6-месячного проекта меня снова перевели в команду Java Web. Причина: компания почему-то не хотела приступать к созданию мобильной команды. У них были проекты на Java, которые были более прибыльными и менее рискованными. На данный момент у меня появилось ощущение нестабильности, неуверенности в том, что если я буду продолжать так часто менять, я не стану специалистом по (многим) технологиям. Так что это был негативный опыт для меня, поскольку я думал о смене компании.

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

В противном случае у вас будет много проблем:

  • Перепланирование текущих проектов из-за человеческих изменений
  • Чувство неуверенности и нестабильности, приводящее к снижению морального духа

Недостатки ротации в середине проекта:

  • Межличностное доверие может быть подорвано
  • Потеря предметной экспертизы (по сравнению с технической экспертизой).
  • Нарушение эмоционального интеллекта команды. Команда возвращается от выступления к штурму.
  • Создание чувства вины/сожаления выжившего
  • Коммуникационные возможности нарушены
  • Внешние заинтересованные стороны обеспокоены оборотом проекта

Преимущества:

  • Разрешить неразрешимый личностный конфликт
  • Сбалансировать наборы технических навыков в соответствии со стадией созревания проектов (заменить сетевого архитектора на информационного архитектора)
  • Замена менее эффективного персонала более эффективным персоналом
  • Сокращайте проект по мере снижения рабочей нагрузки к завершению проекта.
  • Освободите персонал для новых проектов
  • Замените старших сотрудников менее опытными сотрудниками теперь, когда результаты определены и находятся в стадии реализации