Чем сложнее продукт, тем больше разных специалистов требуется для его создания. И сейчас в IT распространено кросс-функциональное взаимодействие, когда в продуктовую команду набирают работников разных специальностей.
Кросс-функциональная команда – это команда, которая состоит из специалистов разных направлений: например, программиста, тестировщика, дизайнера, продуктового менеджера, бизнес-аналитика и так далее. Благодаря «миксу» из разных спецов, такая команда способна самостоятельно улучшать небольшой MVP, стартап или микросервис большого продукта.
Радиоактивные люди
Далее в статье:
- почему такой подход стал популярным и когда он оправдан;
- что представляет из себя кросс-функциональная команда;
- преимущества кросс-функциональной команды;
- недостатки кросс-функциональной команды;
- матричная структура управления: микс кросс-функциональной и линейно-функциональной структуры;
- как создать эффективную кросс-функциональную команду.
Если вашему бизнесу необходимо внедрение современных управленческих практик – обратитесь за бесплатной консультацией в Neogenda. На нашем счету работа с такими компаниями как Тинькофф, Сбер, Яндекс, Точка и X5 Group. Мы оказываем более 100 различных услуг: от обучения вашего персонала до реорганизации вашего бизнеса.
Читайте также: «Управление командой проекта: стратегии и методы для успешного выполнения проектов»
Почему в IT решили прийти к созданию кросс-функциональных команд и когда они нужны
Исторически сложилось, что большие компании состоят из разных отделов: отдела продаж, отдела маркетинга, юридического отдела и так далее. Так же и с IT-отделом, в который входят все специалисты, что работают над цифровым продуктом компании. Вроде бы все логично: сотрудники находятся на своем месте, обмениваясь друг с другом экспертизой и получая задания от своего руководства.
Поскольку у большой компании много работы, ей нужно много сотрудников: например, над цифровыми продуктами какого-нибудь банка могут работать сотни или тысячи айтишников. Соответственно, IT-отдел компании будет делиться на подразделения: разработчиков, тестировщиков и так далее.
И из-за этого между отделами условной компании появляется некая «пропасть». Скажем, разработчики пишут код, занимаясь «хаяньем» дизайнеров: те по их мнению добавляют в дизайн какие-то бесполезные функции, которые не стоят погружения в дебри легаси-кода. Или менее айтишный пример: вечные недопонимания и войны в организациях между отделом продаж и отделом маркетинга. А вот пример, который вы точно ощутите на себе: вспомните, как в школе ваш класс не любил параллельный класс, было же такое?
Мем, взятый из интернета
И вот: из-за недопонимания между отделами ухудшается качество работы. Негативно настроенные департаменты плохо кооперируются: не делятся полной информацией и нехотя выполняют взаимные просьбы.
А от плохой кооперации сильно замедляется время выполнения задач, требующих вовлечения специалистов из разных отделов. Даже если отношения между отделами нормальные, на согласование работ уходит слишком много времени. При этом оперативное реагирование на изменения во внешней среде – одно из ключевых конкурентных преимуществ. Особенно в мире цифровых продуктов.
Вспомните те же соцсети, которые постоянно обрастают новыми функциями. Лучшие идеи они заимствуют друг у друга. А если дело касается технической поддержки платформы, на которой работает сервис, оперативное реагирование вообще становится жизненно необходимым.
Но полбеды – что-то обсудить. Ситуация еще хуже, если один отдел передает другому задачу в работу. Скорее всего, у другого отдела итак будет много своих забот. Из-за этого задача может подвиснуть: нужно оценить загрузку специалистов, выбрать самого свободного, оценить трудозатраты и перестроить планы. Это не говоря о времени, которое уйдет на выполнение самой задачи.
Поэтому айтишники через какое-то время поняли: работа над проектами или микросервисами продукта шла бы куда быстрее, если бы участники рабочей группы лучше скооперировались между собой. Так и возникли кросс-функциональные команды.
Лирическое отступление: кросс-функциональные команды имеет смысл создавать только тогда, когда для выполнения работ нужны специалисты из разных областей. Если задача касается одного вида деятельности, то собирать такую команду не нужно. Например, если нужно написать какой-нибудь код, для этого будет достаточно только разработчиков.
И еще: кросс-функциональные команды не нужны для выполнения отдельных задач или небольших проектов. Тратить время на подбор специалистов и их организацию выгодно, только когда работы длительные.
А для такой задачи понадобится кросс-функциональная команда «Навуходоносора»
Итак, мы узнали, как возникли кросс-функциональные команды и когда в их создании есть реальная необходимость. Но как выглядит такая команда? Сейчас расскажем.
Читайте также: «Матрица RACI: руководство по распределению ролей и ответственности в проекте»
Что представляет из себя кросс-функциональная команда
В интернете можно встретить статьи, в которых пишут, что в кросс-функциональную команду входят участники абсолютно всех процессов, связанных с продуктом. Например, туда входят не только спецы, которые поставляют обновления продукта, но и маркетологи, которые его продвигают.
Это ошибочное суждение: кросс-функциональные команды редко состоят более, чем из 10 человек. Иначе сильно пострадают коммуникации. Об этом написано в том же скрам-гайде, который отчасти популяризировал термин «кросс-функциональная команда».
Пример: приложение большого банка. Над его микросервисами могут работать десятки, если не сотни продуктовых команд. Они доставляют пользователям дополнительную ценность приложения, устраняя его старые недоработки и добавляя новые функции.
У каждой из таких команд будет своя зона ответственности. Например, одна из продуктовых команд банка может может отвечать за оптимизацию чата поддержки. Она может улучшать ИИ-автоответчик, выявлять устранять баги чата, править легаси-код, тестировать новые функции чата и так далее.
А продвижение приложения и его субпродуктов – отдельный процесс, за который чаще всего отвечают совершенно другие команды. По этой логике, если упоминать всех специалистов, которые работают над продуктом, состав кросс-функциональной команды можно растянуть до кадрового состава всей компании. Там будут и юристы, и топ-менеджеры, и сейлзы, и так далее.
С другой стороны, в больших продуктах кросс-функциональные команды часто объединяют в большие департаменты. Они могут относиться к тому или иному направлению продукта. Например, команда чата поддержки может входить в департамент работы с клиентским сервисом. Но такие объединения все равно не назовешь кросс-функциональной командой.
Несмотря на то, что мы рассказали о потребности в возникновении кросс-функциональных команд, те обладают не только преимуществами, но и недостатками. Расскажем и о хорошем, и о плохом.
Читайте также: «Фреймворк SCRUM: что это и как его использовать для управления проектами»
Преимущества кросс-функциональной команды
- Самостоятельность.
Кросс-функциональная команда включает в себя всех участников, которые будут сами развивать и оптимизировать продукт. Например, такая команда может сама поставить задачи на обновление микросервиса, за который отвечает, выполнить эти задачи и выкатить обновленную версию.
- Погруженность в контекст.
Главная фишка кросс-функциональной команды в том, что она работает над одним и тем же на протяжении долгого времени. Соответственно, ее участникам не нужна документация или созвоны, чтобы быть посвященными в условия какой-нибудь задачи. Это сильно упрощает и ускоряет процесс работы.
- Быстрые коммуникации между специалистами разных областей.
Ранее мы уже рассказали, какой волокитой может обернуться обсуждение какого-нибудь процесса даже между двумя отделами. А если в обсуждении задействовано сразу несколько разных сторон, то коммуникации растянутся на еще более долгий период времени.
Создание кросс-функциональной команды способствует более быстрому продвижению проекта. Очевидно, что у участников команды будет общий чат, где все смогут перекинуться мыслями по тем или иным деталям работы. Более того, формирование отдельной команды чаще всего подразумевает, что ее участники могут ни с кем не согласовывать свои действия и не тратить время на лишние бюрократические процессы.
- Коллективные решения.
Если процессы в команде выстроены хорошо, ее участники совещаются между собой, чтобы найти лучшее решение для той или иной задачи. Разные навыки и знания у участников помогают найти более элегантные выходы из разных ситуаций.
Например, бизнес-аналитик выявил узкое горлышко в воронке продаж, которое было связано с интерфейсом приложения. Он предложил запустить A/B-тест, чтобы путем теста оптимизировать интерфейс. Но еще в команде был UX/UI-дизайнер, коллеги которого работали над схожим продуктом. Он знал, что та продуктовая команда проводила UX-исследование по схожей задаче и запросил у ее участников результаты исследования, чтобы сразу предложить более удачное решение по оптимизации интерфейса.
Читайте также: «Управление портфелем проектов: как устранить неразбериху в проектах вашего бизнеса»
Недостатки кросс-функциональной команды
- Накопление опыта только внутри команды.
Когда рабочая группа долго работает над чем-то одним, она все лучше погружается в контекст и оптимизирует рабочий подход. Но смежные команды могут решать схожие задачи и не знать о более удачных практиках, которые уже есть у другой команды. Если над задачами работают специалисты из разных отделов, они с большей вероятностью будут делиться между собой опытом.
- Ограниченность взгляда на контекст.
Из-за того, что в кросс-функциональной команде есть эксперты разных областей, ее участники могут ни к кому не обращаться за помощью – это хорошо. Но если над задачей работают внутри того или иного отдела, специалист с большей вероятностью может обсудить задачу с кем-нибудь еще и услышать разные мнения внутри коллектива. А еще специалиста в отделе будет контролировать более опытный руководитель, который может предложить более удачное решение задачи. Также на некоторые ситуации иногда нужен «незамыленный» взгляд со стороны, которого не будет внутри кросс-функциональной команды.
Но есть способ взять только лучшее от деления штата сотрудников на кросс-функциональные команды. Этого можно достичь за счет внедрения матричной структуры управления.
Читайте также: «Agile, Scrum, Kanban и Waterfall – что выбрать вашему бизнесу»
Матричная структура управления: микс кросс-функциональной и линейно-функциональной структуры
Матричная структура управления – это структура, в которой сотрудники относятся как к рабочей группе, так и к своему функциональному отделу. То есть, в организации может быть несколько кросс-функциональных команд, где сотрудники одной специальности будут подчинены общему руководителю. Скажем, в каждой команде может быть по программисту, над которыми будет стоять один руководитель отдела разработки.
В целом, большинство продуктовых компаний сейчас и используют матричную структуру, потому что это самое оптимальное решение по организации кадров.
Что дает внедрение матричной структуры:
- Сохранение высокой вовлеченности и глубокой экспертизы специалистов, которые работают над зоной ответственности их команды.
- Возможность оперативной замены сотрудника в одной команде или подключения к работе дополнительного специалиста из отдела.
- Возможность специалисту обратиться за советом к более опытному сотруднику, будь то руководитель или какой-нибудь сеньор.
- Возможность организации работы всего штата сотрудников по единым стандартам, что делает продукт более целостным. Например, если все разработчики придерживаются единого стиля написания кода, который задал им руководитель, в нем накапливается меньше технического долга. А это минимизирует риск форс-мажоров, когда какой-нибудь разработчик ушел в отпуск или уволился, а микросервис, над которым он работал, дал сбой и никто не может его быстро починить – нужно сначала разобраться в коде.
А теперь перейдем к самой прикладной части статьи: расскажем, как собрать добротную кросс-функциональную команду у себя.
Как собрать эффективную кросс-функциональную команду
Кросс-функциональная команда связана более тесными узами, если сравнивать ее с проектной группой. Участники команды отправляются в совместное долгое плавание, поэтому важно учитывать не только хард-скиллы отдельных специалистов, но и их софт-скиллы. Более того, «мягкие навыки» сотрудников лучше комбинировать так же тщательно, как и технические. Но обо всем по порядку.
Хард-скиллы
В первую очередь, в команде должны быть все специалисты, нужные для того, чтобы команда могла самостоятельно работать над продуктом: поддерживать его работоспособность и выпускать обновления.
Конкретный состав команды будет сильно зависеть от продукта. Например, для поддержки какой-то платформы в серверной части приложения команда может состоять исключительно из технарей: скажем, разработчика, тестировщика, сисадмина, техлида и продуктового менеджера. А если команда занимается разработкой молодого веб-сервиса, в ней скорее всего будет веб-дизайнер, а может даже и маркетолог.
Понятие «кросс-функциональность» касается не только команды, но и отдельных специалистов. Есть термины, которыми можно охарактеризовать набор навыков того или иного участника команды:
- I-shaped специалист. Так называют участников команды, которые обладают экспертизой в одной сфере деятельности. Например, таким спецом может быть бэкенд-разработчик, который работает только в этом направлении. Знать что-то одно – вовсе не плохо. Хорошо, если ваш разработчик или тестировщик – I-shaped специалист, который поднимает квалификацию именно в своей сфере деятельности.
- T-shaped специалист. Это мультискиллоыве спецы, которые хорошо разбираются в чем-то одном, но поверхностно разбираются еще в ряде дисциплин. T-shaped специалистами должны быть руководители – если они немного разбираются в деятельности других участников команды, им проще ей управлять. Также T-shaped специалист может подхватить зону ответственности другого участника команды в нужную минуту: если коллега, скажем, заболел.
- «Расческа»-shaped специалист. Сюда относятся спецы, которые являются экспертами в двух или более сферах деятельности. Таких мало, потому что нужно потратить годы, а то и десятилетия кропотливой работы, чтобы в совершенстве постичь несколько дисциплин. Скажем, это может быть какой-нибудь фулстек-разработчик. Зачастую навыки таких спецов избыточны, потому что чаще всего спецы в команде занимаются каким-то одним видом деятельности.
Он потратил десятки лет на работу
Скорость выполнения задач участников команды должна соответствовать нагрузке. Скажем, если в команде слишком много нагрузки на разработчика и из-за него стопорится процесс, в команду нужно привлечь еще одного разработчика. В одной кросс-функциональной команде такое выявить легко, но проблема часто встречается в сложных организационных структурах. Выявить ее помогает измерение пропускной способности – метрики, используемой в Канбан Методе. Про то, как ее измерить и улучшить у нас есть отдельная статья в блоге: «Пропускная способность (Throughput): что это, как и зачем улучшать».
Софт-скиллы
Чтобы команда достигала лучших результатов, ее участники должны уравновешивать друг друга не только по хард-, но и по софт-скиллам.
Для того, чтобы классифицировать характеры всех участников команды, можно использовать модель командных ролей Рэймонда Белбина – ученого, имеющего докторскую степень по психологии.
Модель гласит, что участники команды должны обладать разными особенностями поведения, с которыми они будут дополнять друг друга. Каждому участнику присуща та или иная роль, которая выражается в его мышлении и поведении наиболее ярко. У каждой роли есть свои преимущества и недостатки.
Всего в модели выделяется 8 разных ролей:
- Душа команды. Это идейный вдохновитель команды, который способен устранять конфликты и мотивировать ее участников работать. Такой человек не сдастся перед препятствием. Минус таких людей в том ,что они легко поддаются чужому мнению и «душнят», фокусируясь на достижении поставленных целей.
- Координатор. Так называют искусных управленцев, которые следят за рабочим процессом и делегируют задачи. Минус: излишнее делегирование, из-за которого такие люди все же теряют контроль над некоторыми процессами.
- Генератор идей. Это креативные люди с хорошо развитой фантазией, которые фонтанируют гипотезами. Минус: могут витать в облаках и не видеть насущные проблемы.
- Собиратель идей. Это экстраверсивные аналитики, которые хорошо себя показывают в поиске новых возможностей. Минус: отсутствие интереса к каким-то устоявшимся процессам.
- Стратег-аналитик. Так зовут людей, которые могут разобрать любую идею на косточки и раскритиковать ее, если она недостаточно хороша. Минус: неумение заставить других людей действовать.
- Шейпер. Сюда относятся добросовестные сотрудники, которые следят за качеством выполнения работы. Минус: им тяжело делегировать работу, потому что они могут потерять контроль над ситуацией, а еще они могут быть излишне требовательными из-за своего перфекционизма.
- Педант. Так зовут экспертов в той или иной сфере. Их минус: фокус только на своей деятельности, но не на общей картине.
- Реализатор. Представителям этой роли свойственно воплощать в жизнь любые идеи, они берут и делают. Минус: они не смотрят по сторонам, из-за чего им тяжело адаптироваться к изменениям.
По мнению Рэймонда, всем людям присущи черты всех ролей, правда некоторые выражены более ярко. Каждый человек будет обладать 1-2 сильно выраженными ролями, 4-6 ролей будут выражены средне, а оставшиеся 1-2 роли – слабо.
Чтобы уравновесить команду, нужно выявить роли ее возможных участников, после чего постараться собрать у себя в команде равнозначное количество представителей всех ролей. Для визуализации состава команды удобно использовать матрицу – таблицу, в которой будут перечислены участники и их возможные роли.
Пример более-менее удачно укомплектованной команды
За счет использования модели, вы можете собрать более эффективные команды, если будете распределять сотрудников не только по требуемым навыкам, но и по их характеру.
Если вам нужна помощь в сборе продуктовых кросс-функциональных команд – обратитесь за бесплатной консультацией в Neogenda. Мы предоставляем разные услуги: от обучения ваших сотрудников лучшим управленческим практикам до полной реорганизации процессов вашего бизнеса.
