В четверг на встрече HR-клуба «Как делать» по кросс-функциональным командам, были сформулированы проблемные фокуса внимания, которые надо удерживать при формировании кросс-функциональной команды, выполняющей сложный междисциплинарный проект. В принципе, они известны, но я хочу для себя записать их списком вместе с собственными размышлениями. И, думаю, этот список будет интересен не только мне. Отмечу, что по каждому фокусу есть свой набор инструментов и свои компетенции, которые должны быть в команде.
Предварить этот список я хочу вот каким замечанием. Есть холиварная тема, чем отличается команда от группы. И рассуждения о том, что для многих работ команды не нужны, достаточно группы. Не углубляясь в обсуждении, отмечу, что с моей точки зрения команда начинается там, где в совместной работе начинает проявляться синергетический эффект, команда становится больше, чем сумма участников, и способна синтезировать решения и совместно выполнять работу, которую никто из участников в отдельности не сделает, то есть появляются идеи, дела и решения, про которые нельзя сказать, кто конкретно их придумал или сделал. И многие проекты требуют именно такой команды.
Итак, фокусы поддержки.
- Эффективная коммуникация в группе. Умение слышать и слушать друг друга, во-время убирать эмоции. Здесь работают различные техники фасилитации, и, в целом, эти практики достаточно проработаны. Хотя распространенность их далеко не такая хорошая, как хотелось бы и эффективность совещаний во многих компаниях оставляет желать лучшего. При этом одного фасилитатора недостаточно, компетенция должна быть у большинства участников команды.
- Умение действовать командой, продвигаясь к общей цели. Здесь работают техники тимбилдинга и командообразования, проведения команды по пути от группы до команды. Здесь модели и практики тоже проработаны. Но в современных условиях есть несколько «но».
- Большинство подходов рассчитаны на то, что команду притирают достаточно долго, месяц-другой, а потом она долго и эффективно работает. И раньше было все хорошо — были длинные проекты. А теперь все больше коротких проектах, на пару месяцев, а то и на пару недель. При этом команда над ними должна работать совместно, желательно как команда, а не группа, с синергетическим эффектом от совместного творческого решения задач.
- А еще подходы рассчитаны на стабильную команду. А даже в проектах, которые идут год и более, состав команды часто меняется. Не кардинально, но кто-то приходит, кто-то уходит, это — рабочий процесс. В теории после этого команда вываливается в storming, а на практике это не допустимо, потому что время performing становится слишком маленьким.
- В современных командах появляются люди с неполной занятостью, которые, тем не менее, несут необходимые компетенции. И чем дальше, тех их будет, по-видимому, больше — а во всех теориях этот фактор выступает как крайне нежелательный.
- Достаточный набор компетенций в группе. Это как раз вопрос формирования состава команды, и хотя в теории это вообще не является проблемой: выпиши нужные компетенции, и привлеки людей, практически тут далеко не так просто.
- Если собирать людей для того, чтобы покрыть всю функциональную область сложного междисциплинарного проекта, быстро оказывается, что нужно очень много людей, нарушается предел эффективных коммуникаций в 7-9 человек. А еще надо ведь обеспечить кроссфункциональность команды, то есть работоспособность ее в ситуации, когда кто-то из участников заболел или ушел в отпуск. Теоретический выход — включайте только ключевых — не слишком реализуем на практике. Практический подход — сложно структурировать команду проекта, выделять ядро и ассоциированных участников, и по-разному организовывать взаимодействие, учитывать это в командообразовании.
- Надо проверять не только функциональную полноту компетенций, но и использовать другие ролевые модели, например, модель Белбина, фиксируя провисающие или конфликтные фокусы, ослабляющие команду и предпринимая действия для их компенсации. При этом использовать критерии хорошей команды по Белбину в условиях дефицита квалифицированных сотрудников, скорее всего, не получится, надо именно предусматривать компенсирующие механизмы.
- Парадоксальный вывод из дефицита квалифицированных сотрудников: большинство проектов будет выполняться некомпетентными командами. Компетентные люди могут быть — но они, с большой вероятностью, предпочтут знакомым задачам другие проекты, которые несут для них вызов. В лучшем случае они доступны частично, как эксперты. Такая вот ситуация. Отмечу, что Agile-подходы это могут обеспечить, потому что формировались именно в таких условиях: с появлением персоналок резко выросла потребность в разработчиках софта, а подготовка специалистов не увеличилась, и разработку пришлось вести некомпетентным командами. С этим Scrum справился. Это — на Западе, в России в это время куча народа из разваливающейся оборонки пришли в IT, и это компенсировало ситуацию
- Совместное мышление, обсуждение и выработка решений в условиях, когда различные участники команды имеют собственные онтологии и картины мира. Здесь речь идет не о коммуникативных навыках, а об умении быстро строить онтологии и участников коммуникации и «переводить с русского на русский». Фасилитации тут недостаточно, необходимо разбираться в содержании обсуждаемых вопросов, потмоу что каждый говорит из своего профессионального контекста. Типичный пример — коммуникация между менеджером, отстраивающим процессы исполнения заказов, и маркетингом, озабоченным удовлетворенностью клиентов и репутацией компании — они говорят на разных языках. Если к ним добавить еще юристов, бухгалтеров и службу безопасности, то можно представить себе спектр различий в моделях мира. Профессиональные компетенции в этой области есть у IT-аналитиков, и есть даже подход Domain Driven Design, в котором как обязательная часть предполагается построение единого языка проекта, с сопряжением его с другими понятийными системами и онтологиями. Есть также современные подходы у философов-рационалистов или в системном мышлении. И в команде должна присутствовать эта компетенция, желательно у нескольких участников.
На этом все. Сама встреча была интересная. Сообщество очень живое, профессиональное и хорошего уровня, а встречи проходят в неформальной обстановке, с активным общением участников и работе в группах. Меня позвали как эксперта, но формат предполагает не монологи экспертов, а активное включение их в работу групп. Для себя, помимо общего знакомства с сообществом и многих мыслей я вынес ссылку на книгу Six Simple Rules о работе со сложностью и модель хорошей команды, на краткое описание которой обещали позднее прислать ссылку с авторством :) Я попробовал ее быстро найти по запомненному контексту, не получилось, зато наткнулся на сайт, где командообразование достаточно систематично изложено и характеристики команды похожи на те, что рассказывали (но их сильно больше, и это снижает ценность).
Так что спасибо организаторам за приглашение.
[ Хронологический вид ]Комментарии
Войдите, чтобы комментировать.
Да, про модель - в материалах встречи были подробности. Это модель team performance model (TPM) Дрекслера - Сиббета. Информации много, по-русски и по-английски.
Отзыв о встрече на FB