Я был «консультантом» (сотрудником отдела кадров, призванного помочь, и работал с ними).
Во-первых, каждый раз, когда меняется расположение «команды», появляются растрепанные перья. Есть четыре этапа развития команды;
- «Формирование» - команда сначала узнает друг друга по имени, устанавливает основные правила совместной работы, начинает проникать в окружающую среду. Обычно занимает около недели.
- «Штурм» - команда сталкивается с разногласиями, личностями, эго и т. Д. Это начнет происходить почти сразу и пересекается с фазой «нормирования», когда личные конфликты возникают и разрешаются или преодолеваются.
- «Норминг» - команда работает через эти различия. Руководство может выявлять кадровые проблемы в команде и предпринимать соответствующие действия, но в большинстве случаев это просто люди, привыкшие работать друг с другом. Это может занять недели или даже месяцы, но, как правило, попытка слишком сильно вмешаться в процесс будет мешать «нормированию».
- «Выполнение» - «устойчивое состояние», когда команда в значительной степени знает, как работать вместе, а не как группа людей. Здесь вы начинаете видеть модное слово «синергия», где команда работает лучше, чем сумма ее частей, потому что они взаимодействуют без какого-либо возмездия или личных амбиций, кроме как помочь команде. Только постепенные изменения должны быть сделаны в составе такой команды, чтобы заменить истощение или увеличить команду; большие увеличения, уменьшения или слияния команд расстроят химию, и процесс начнется заново.
Вы должны пройти все четыре этапа, чтобы команда работала на полную мощность. Попытка протолкнуть фазы «штурма» и «нормирования» просто приводит к недовольству команды, эго и общему недовольству других членов; это в конечном итоге взорвется в лицо команды, и тем временем команда, не доверяя друг другу, не будет выступать так хорошо, как могла бы.
Теперь, как говорится, формирование единой команды, состоящей из консультантов и внутренних разработчиков, является особенно боевым. Он все еще следует тем же этапам, что и выше, но две команды, объединяющиеся в одну, происходят из разных корпоративных культур и отчитываются перед разными людьми, которые мало что могут сказать о поведении других людей. Внутренняя команда, скорее всего, примет стереотипное мнение о том, что консультанты приходят с 6-значным окладом, чтобы полностью отменить всю свою тяжелую работу, что подрывает их профессиональный статус и репутацию в глазах их руководителей. На самом деле, «консультанты» могут заключать контракты, не получая никаких преимуществ, мало гарантируя свою работу, и им приказывают выполнять работу, которая на первый взгляд кажется непреодолимой.
В этом случае, IMO, как правило, лучше держать две команды как можно более раздельно. Две команды могут работать над одним проектом при правильном управлении. Консультации между командами должны проводиться на уровне старшего менеджера или менеджера проекта, в зависимости от того, насколько менеджеры проекта находятся в кругу конкретных проектных решений и проблем. Следует избегать дублирования работы, выполняемой каждой командой одновременно; поразить движущуюся цель труднее, поэтому команда 1 не должна зависеть от того, что команда 2 в настоящее время разрабатывает или проводит рефакторинг, и наоборот.
Это ситуация, в которой Agile является очень эффективной методологией управления проектами. Разделите работу на управляемые куски, назначьте независимые куски для каждой команды и дайте каждой команде понять, как наилучшим образом удовлетворить требования. Убедитесь, что соблюдаются правила оформления; когда команда 2 сталкивается с зависимостью от кода команды 1, она растрепает перья с обеих сторон, если потребуется слишком много рефакторинга.