Является ли чередование разных команд хорошей идеей?

Упомянутые вами недостатки могут быть легко применены к проектным командам, если вы продолжите разделять разные группы.

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

Одним из ключевых параметров может быть вопрос: «Какой уровень межфункционального общения необходим нашим командам для достижения успеха, и достигаем ли мы этого в текущей системе?» Я делаю вывод из вашего вопроса, что ответ вашего начальника НЕТ, вы не получаете уровень межфункционального общения, который вам нужен, и пытаетесь решить эту проблему, разрушая бункеры, созданные функциональными подразделениями. И отличный способ сделать это — разместить ваши проектные команды в одном месте.

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

Цель «сидения вместе» как практики

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

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

Держите свою точку зрения

Хотя «вниз по коридору» может быть неудобно для осмотического обмена информацией, вряд ли это проблема, такая же, как координация с географически рассредоточенными командами или офшорными моделями разработки. Честно говоря, если проблема не настолько велика, чтобы пройти 20 или 100 футов, она, вероятно, не является реальной или неотложной проблемой.

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

Коммуникационная культура

Команды, которые не сидят вместе, все еще могут хорошо работать вместе. Все дело в общении. Если у вас есть команда, которая рассредоточена по коридору или за океаном, 21 век изобилует продуктивными методами коммуникации.

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

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

Что тут делать правильно?

спросите у своих сотрудников.

Если вам действительно небезразлична их производительность — спросите у них , каким образом они будут продуктивнее. И когда вы спрашиваете — обязательно слушайте, что они говорят (я видел босса, который «спрашивал» так: « У нас будут такие-то и такие-то изменения, хорошо? »)

Я согласен со Стивом и Дугом в том, что это зависит от нескольких вещей. Первый зависит от того, как ваша организация функционировала в прошлом, и могут ли ваши команды легко адаптироваться к изменениям. Чтобы перейти от традиционной функциональной командной среды к более абстрактной проектной среде команды maxtrix, нужно приложить немало усилий, чтобы все прошло гладко. Многое из этого связано с обучением и подготовкой новых «команд» к возможностям развития команды (формирование, штурм и т. д.). Наш офис работает полностью в матричной среде, где члены команды занимаются более чем 6-10 проектами каждый. К этому нужно привыкнуть, но если ваша корпоративная культура способствует простоте общения, это может быть очень эффективной методологией.

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

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