Как проектировать обучение на основе данных

Запрос на обучение почти всегда начинается одинаково

«Нам нужен тренинг по коммуникации», «давайте обучать руководителей софт-скиллам», «сотрудники плохо взаимодействуют».

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

В результате обучение начинает работать с симптомами, а не с причинами. Так тренинг превращается в универсальный ответ — аккуратный и понятный, но без гарантии реального эффекта.

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

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

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

Поэтому первый и самый важный этап в работе с обучением — корректное снятие запроса.

Запрос, проблема и решение — не одно и то же

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

За формулировкой «нужен тренинг по коммуникации» могут скрываться разные проблемы:

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

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

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

Даже когда причина запроса в целом понятна, на этом этапе часто совершается еще одна типичная ошибка — аудиторию рассматривают как однородную.

Почему без сегментации обучение быстро «усредняется»

На практике под названиями «руководители», «сотрудники» или «новички» скрываются разные группы с разным опытом, контекстом и задачами.

Если сегментация не проведена, обучение неизбежно усредняется. Программа начинает решать сразу несколько разных задач одним форматом и в итоге оказывается «про все и ни о чем». Именно поэтому на этапе снятия запроса важно не только понять проблему, но и определить, для кого именно она актуальна и в каком контексте проявляется.

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

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

CustDev в обучении: продуктовый подход

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

У любого продукта есть понятные элементы:

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

Если эти элементы не зафиксированы, программа превращается в набор активностей — тренинги, модули, задания, которые сложно связать с реальными изменениями в работе. Формально обучение есть, но ответ на вопрос «что именно изменилось?» остается размытым.

Продуктовый подход требует начинать не с формата и не с тем, а с понимания пользователя и его контекста. Именно здесь происходит CustDev — качественный исследовательский метод, ориентированный на выявление реальных проблем и потребностей целевой аудитории через фокус-группы и интервью.

Он позволяет перейти от абстрактных формулировок к фактам. Вместо вопросов «чего вам не хватает» или «какой тренинг нужен» фокус смещается на реальный опыт:

• в каких ситуациях человек сталкивается со сложностями,
• какие решения он принимает,
• почему действует именно так,
• к каким последствиям это приводит.

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

Почему запрос — это всегда гипотеза

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

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

Когда интервью меняют решение о формате

Как это работает на практике, хорошо видно на одном из проектов.

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

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

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

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

Что важно понимать о CustDev

Важно понимать: CustDev не дает готовых ответов и не заменяет экспертное мышление. Он не подсказывает, «какой тренинг провести», и не гарантирует удобного решения.

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

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

Заключение

Все эти наблюдения приводят к одному простому, но неочевидному выводу. Запрос «нужен тренинг» — это не точка старта, а повод для разговора.

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