Harvard Business Review (HBR) - Менеджмент. Главные идеи

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

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

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

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

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

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

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

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

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

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

Вашей целью станет установить обмен знаниями как культурную норму, которая подразумевает, что все сотрудники осознают очевидные плюсы этого. Как и в случае любого культурного сдвига, важно подавать пример и вознаграждать тех, кто ему следует. Но сказать – еще не значит сделать. Чтобы упростить процесс, выделите преимущества обмена опытом и предоставьте ритуалы и технологии, содействующие ему, такие как общие обеды и онлайн-форумы. Одна технологическая компания, с которой мы работали, стала отмечать прорывы в проектах, перенимающих передовой опыт. Другой пример: команда исследователей и разработчиков в производственной компании месяцами получала благодарности от сотрудников, которые приобрели новые знания с помощью их совместных проектов. В обоих случаях наша цель состояла в том, чтобы прояснить преимущества обмена знаниями и уменьшить то давление, которое люди испытывают, с головой погружаясь в неотложные задачи.

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

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