Почему рушатся образовательные проекты. Кросс-функциональная команда
Автор статьи:
Эксперт в области мотивации и построения клиентоцентричных команд, бизнес-тренер, корпоративный антрополог BTG Consult
Почему даже сильные тренеры и качественные программы не всегда решают бизнес-задачи? Успех корпоративного обучения зависит не только от экспертизы, но и от того, как выстроена совместная работа заказчика и провайдера. Разбираем, как создать сильную кросс-функциональную команду, избежать типичных ошибок и превратить обучение в инструмент изменения поведения сотрудников.
Для успешного проекта недостаточно просто собрать сильных специалистов. Даже хорошие тренеры, методологи или дизайнеры по отдельности не гарантируют результат, который действительно решит бизнес-задачу заказчика. Чтобы образовательный продукт получился качественным и эффективным, нужна сильная кросс-функциональная команда.
Кросс-функциональная команда — это совместная рабочая группа со стороны заказчика и исполнителя, в которую входят специалисты из разных функций и направлений, объединенные общей целью проекта и ответственностью за результат.
Главная ошибка во взаимодействии заказчика и провайдера
В корпоративном обучении встречается частая ситуация, когда отдел обучения/HR формулирует запрос, например:
Провести обучение по переговорам / тайм-менеджменту / тимбилдингу (иногда, кстати, просят это все в одном флаконе), внешний провайдер делает программу, все вежливо согласовывают… а на выходе получается: «Спасибо, все было хорошо, но не про наш бизнес-запрос и, наверное, больше с вами работать не будем».
Проблема почти всегда не в экспертизе. Она в том, как устроена команда.
Кросс-функциональная команда «заказчик + провайдер» — это не формальное соблюдение условий юридического договора. Это построенная рабочая система. И если ее не настроить, проект быстро превращается в классическую модель. То, что мы в BTG Consult называем: «дайте-нате» или «мы заказали — вы сделали».
При этом такой формат отношений предполагает работу по вертикали, где заказчик хочет получить результат без лишних вопросов, замечаний и не обращая внимания на «лишние комментарии» поставщика услуг.
На наш взгляд, такой подход почти всегда обречен на провал, особенно если мы говорим про кастомный проект.
Кастомные проекты
И да, спойлер: почти любой проект в сфере обучения и развития людей — это кастом. Почему?
Потому что везде есть свой особый контекст: со стороны заказчика — корпоративная культура, отношения стейкхолдеров внутри компании, бизнес-цели, стандарты и процессы и т.п.
А со стороны провайдера — опыт реализации десятков (а где-то и сотен) проектов, понимание трендов, «граблей и фишек», с которыми точно столкнется проект.
И чтобы получить сильное решение, все эти нюансы нужно обсуждать, работать в формате co-creation — сотрудничества двух сторон.
Построение кросс-функциональной команды
Чтобы такая модель сотрудничества сложилась, на мой взгляд, важно учитывать следующие аспекты:
Начинаем обсуждение проекта с целевого поведения, а не с формата
Фраза «нужен тренинг по переговорам» — это не цель. Цель — это всегда изменение поведения в конкретной рабочей ситуации.
Хороший вопрос на старте:
«Что люди должны начать делать по-другому на работе?»
Пример: не «разработать курс», а «увеличить конверсию сложных переговоров с ключевыми клиентами».
И важно: провайдер должен участвовать в формулировке этой цели, а не получать ее как ТЗ. Потому что, возможно, то что вы как клиент хотите получить от образовательного решения, вы просто не получите. Тренинги и другие обучающие продукты — не волшебная палочка. Продажи не вырастут автоматически после того, как участники пройдут обучение. А вот что реально может измениться, вам точно расскажет опытный провайдер. Таким образом, уже на старте вы сможете понять, стоит ли вам идти в этот проект или лучше инвестировать бюджет организации во что-то другое.
Кейс:
Несколько лет назад я вел диалог с крупным банком, представители которого хотели наладить кросс-функциональное взаимодействие региональной сети. Когда мы дошли до образа результата и я стал уточнять, верно ли я понимаю, что по итогу мероприятия участники должны научиться договариваться самостоятельно между собой, не перегружая головной офис своими запросами, к моему удивлению, клиент сообщил: «Вовсе нет. Если они смогут договариваться без нас, зачем же мы тогда нужны. Нет, просто сделайте мероприятие, которое поднимет мотивацию и поможет людям выполнить план продаж».
Так на старте мы смогли понять, что нужен другой формат, отличающийся от изначального. Если бы данного уточнения целевого поведения мы не произвели, то пошли бы абсолютно не туда.
Когда образ результата сформирован, собираем реальную команду
Минимально жизнеспособная команда
Со стороны заказчика:
- L&D/HR менеджер (владелец проекта);
- бизнес-заказчик (задачу которого мы решаем);
- эксперт (представитель ЦА);
- для крупных проектов также рекомендую сразу подключать менеджера по внутренней коммуникации/PR.
- методолог;
- проектный менеджер;
- тренер / контент-эксперт.
Распределяем роли
Большинство конфликтов в проектах заключается в пересечении ответственности и зон влияния.
Рабочая логика здесь такая:
- заказчик отвечает за бизнес-контекст и результат;
- провайдер — за методологию и дизайн решения;
- решения принимаются совместно.
Если это не проговорить, начинается борьба «кто главнее», а не работа над продуктом.
Формируем общий язык
Часто стороны говорят об одном и том же разными словами:
- заказчик: «нам нужна программа»;
- провайдер: «нам нужен learning journey».
Решение — короткая установочная встреча:
- разобрать 1–2 примера;
- согласовать принципы (например: «без практики ничего не запускаем»);
- синхронизировать ожидания.
Это экономит недели переделок.
Без прототипа не идем в масштабирование
Документы не создают понимания. Прототипы создают.
Что работает лучше всего:
- черновые сценарии;
- примеры заданий;
- фрагменты тренинга или курса.
Когда команда обсуждает не описание, а «живой кусок продукта», качество решений резко возрастает.
«Спим в одной постели с клиентом»
Особенно на первых этапах реализации проекта, пока вы не понимаете оптимальный ритм коммуникации, количество возможных правок, держите короткий цикл взаимодействия.
Если коммуникация редкая, команда распадается на две стороны (Они — Мы) и становится намного сложнее достигать единых целей.
Минимум:
- еженедельные синки;
- быстрые демонстрации;
- обсуждение сомнений, а не только статуса.
Важно: чем раньше появляется обратная связь, тем дешевле будут исправления.
Кейс:
Этот совет я прочувствовал болью, кровью и слезами своей команды. Пару лет назад мы выиграли тендер на проведение обучения руководителей в крупной российской компании. Вся команда испытывала восторг и была в предвкушении классного и интересного проекта. Эйфория улетучилась на первой же встрече с заказчиком. Нам сухо, очень бюрократично пояснили, как мы будем работать: встречи 1 раз в месяц, коммуникация только по почте, никаких драфтов, материалы сразу в чистовом формате.
В итоге команда быстро утонула в переписке, а обратную связь приходилось ждать неделями. Уже через месяц стало ясно: с таким подходом проект не выдержит ни сроков, ни нагрузки. Еще месяц ушел на то, чтобы донести суть нашего предложения до клиента: сократить циклы обратной связи, согласовывать сначала прототипы и только потом финальные версии.
До того, как мы выработали правильный ритм в проекте, команда из 12 человек работала практически на пределе: горы магния, литры ромашкового чая и прочие антидепрессанты. Троих человек я вытаскивал из фазы почти полного выгорания.
«Не заметайте проблемы под ковер»
Мой бенгальский кот, если нахулиганит, всегда пытается прикрыть «улики» другими вещами и сделать невинный вид. В бизнесе тоже часто пытаются спрятать ошибки, но запах нерешенных проблем все равно выдаст их и отравит атмосферу. Не избегайте конфликтов. Лучше сразу устранить причину и проветрить, чем делать вид, что ничего не произошло.
В сложных проектах конфликт — это нормально:
- бизнес хочет быстрее, проще и дешевле;
- провайдер: глубже и системнее, часто выходит дороже 🙂
Сильная команда не избегает споров, а привязывает их к вопросу:
«Как это влияет на результат?»
На старте определяем, что такое «хорошо» и что такое «плохо»
Иначе в конце проекта у всех будет разное понимание успеха.
Полезные вопросы
- Как выглядит готовый продукт?
- Как мы поймем, что обучение сработало?
- Какие метрики используем?
Без этого финальное согласование превращается в субъективную дискуссию.
Вывод
Сильная команда — это правильно выстроенная система взаимодействия.
Если коротко:
Если выпадает хотя бы один элемент, проект почти неизбежно скатывается в формат для галочки: «сделали программу, но не изменили поведение».
Один из частых вопросов
Как понять, что команда работает правильно?
Есть несколько критериев: сформированные метрики эффективности проекта достигаются, конфликты связаны исключительно с выбором лучшего способа решения рабочих задач (участники способы отделять «человека от проблемы»), люди общаются не только на рабочие темы с удовольствием, проводят время вместе вне работы и команда приносит пользу бизнесу.
Заключение
Чем сложнее бизнес-задача, тем важнее перестать мыслить категориями «купить обучение». Настоящие изменения появляются там, где заказчик и провайдер работают как единая команда, а не как стороны из договора.
Корпоративное обучение — это совместная работа, в которой важны открытый диалог, единое понимание целей, готовность обсуждать сложные вопросы и вместе искать решения.
Именно поэтому в BTG Consult мы строим проекты не вокруг отдельного обучающего решения, а вокруг совместной работы команды заказчика и провайдера — от диагностики и проектирования решения до внедрения изменений в рабочее поведение и достижения бизнес-результата.
Начать диалог
