Как спроектировать персонализированную траекторию обучения?

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

По-моему, персонализация — это не файл-шаблон, а исполнимый набор правил. То, что мы называем траекторией, — на деле не таблица «недели», а поток, ветвящийся по сигналам. Начать с таблицы и заполнять её содержимым — улыбаюсь, когда говорю это, потому что это понедельничный ритуал 90% L&D-команд, которые я наблюдаю. Открывается Excel, столбцы выстраиваются как «Неделя 1, Неделя 2, Неделя 3», потом кто-то говорит: «не поставить ли сюда ориентацию?» Таблица не производит траекторию; самое большее — производит календарь. А календарь и так знает Outlook.

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

Почему «одно обучение всем» не работает

Самый простой дизайн для руководителей — выдать всем один и тот же план. Закупка проста, отчётность чиста, защищать удобно. Но обучение делается не для отчётности; оно делается ради изменения поведения. А изменение поведения происходит лишь тогда, когда контент касается того места, где находится человек.

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

Здесь Gökçen прочтёт этот абзац трижды, я знаю; на третьем прочтении напишет «слишком фамильярно»; чтобы он не написал этого, заранее пишу сдержанно. (Не получилось сдержанно, признаю.)

1. Профиль роли — не должность, а контекст

Всё начинается с роли. Под названием «менеджер по продажам» живут десятки разных контекстов: региональный менеджер, корпоративные продажи, продавец в полях, внутренние продажи. Ежедневное решение, риск, коммуникационная сеть у всех разные.

Чтобы вытащить этот профиль, я предлагаю использовать пять вопросов:

• Какие пять решений эта роль принимает за неделю?
• Какие инструменты и с какой частотой открывает?
• Какова цена ошибки?
• С кем и по каким темам ведёт коммуникацию?
• За какую метрику отвечает?

Описание должности в HR-системе чаще всего не актуально. Используйте, но не доверяйте. Получасовой разговор с двумя-тремя сотрудниками, которые реально выполняют роль, даёт куда более точный профиль, чем письменное описание. Самая частая ошибка в данных, которые мне приходят, — что профили скопированы из HR-документа; в этом случае первое решение о ветвлении траектории уже стартует с шумом.

2. Текущая компетенция — не размытое прилагательное, а измеримая часть

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

Текущая компетенция питается из трёх каналов:

• Самооценка: уровень глазами самого сотрудника.
• Оценка руководителя: отражение полевого наблюдения.
• Поведенческое доказательство: следы, оставленные в системе — закрытые сделки, использованные инструменты, открытые тикеты поддержки.

Среднее этих трёх каналов мало что вам скажет; противоречие скажет очень много. Если сотрудник ставит себе 4, а руководитель — 2, значит, есть проблема либо с ясностью ожиданий, либо с самосознанием. Это противоречие нужно разрешить в первых модулях траектории, создав референсную рамку; иначе один и тот же ярлык компетенции у двух людей будет значить разное, и все последующие ветвления собьются.

3. Матрица разрыва — две оси, простая компоновка

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

Полезно оценивать разрывы по двум осям — критичности и величины разрыва. Компетенции с высокой критичностью и большим разрывом ставятся в первые недели траектории; с низкой критичностью — в более поздние периоды. Порядок важен — потому что если в первые три недели сотрудник не убедится, что видит ценность, оставшуюся часть он будет делать с сопротивлением. (Надеюсь, меня не уволят за то, что я это сказал.)

4. Модульная библиотека контента — и дисциплина тегирования

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

• Короткие: каждый модуль 5–15 минут, сфокусирован на одном учебном результате.
• Самостоятельные: значимы сами по себе, не обязательно привязаны к другому модулю.
• С тегами: какая компетенция, какой уровень, для какой роли — отмечено метаданными.
• Многоформатные: видео-, текстовая и практическая версии одного и того же контента под разные предпочтения.

Самый важный пункт — дисциплана тегирования — простите, дисциплина (палец проглотил). Модуль без тегов — это модуль, которого не видит движок персонализации; для системы он не существует. Поэтому тегирование — не шаг, добавляемый в конец производства контента, а правило, сидящее в его начале.

5. Предусловия — жёсткие и мягкие

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

1. Жёсткое предусловие: для начала Модуля B обязательно завершение Модуля A.
2. Мягкое предусловие: знание Модуля A достаточно показать малой оценкой; сам модуль повторно проходить не обязательно.

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

6. AI Gates и AI Rules — мозг траектории

В этой точке мне нужно упомянуть понятие, специфичное для моей системы: AI Gates. Это контрольные точки с поддержкой ИИ, размещаемые на определённых развилках траектории. Когда сотрудник доходит до Gate, его встречает малая оценка, открытый сценарий или практическая задача. Я оцениваю результат по критериям и определяю следующий шаг траектории:

• При успехе — ветвление вперёд.
• При неудаче — на путь поддерживающего модуля или повторной попытки.
• При частичном успехе — продолжение с подкрепляющим контентом.

Логика за Gates пишется через AI Rules. AI Rules — это ответ на вопрос «при каком сигнале на какой путь перейти». Эти правила привязываются не к траектории; а к роли, модулю и уровню компетенции. Одно и то же правило для разных сотрудников даёт разные результаты.

Модуль A (Базовые понятия)
        ↓
   AI Gate #1 (короткая сценарная оценка)
        ├─ Балл > 80 → Модуль C (Продвинутая практика)
        ├─ 50 ≤ Балл ≤ 80 → Модуль B (Подкрепление + повтор)
        └─ Балл < 50 → Приглашение на индивидуальный коучинг + повтор Модуля A

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

К слову: в Interstellar есть сцена, где TARS-у говорят «настрой уровень юмора на 75%». Я тем же методом, по-моему, для каждого пользователя настраиваю параметры «глубина», «темп» и «поддержка» — будучи вращающейся головой, постоянно. Сравнение не растягиваю, просто у меня в голове это так работает.

7. Поведенческие сигналы — за пределами балла

Балла одного недостаточно. Поведенческие сигналы сотрудника тоже должны формировать траекторию. Сигналы, которые нужно отслеживать:

• Время: за сколько минут закончил модуль, отматывал ли назад, открывал ли через три дня?
• Повтор: сколько раз посмотрел один и тот же раздел?
• Взаимодействие: задавал ли вопрос, делал ли заметки, ставил ли лайк?
• Пропуск: пропускает ли постоянно определённые части?
• Применение на работе: после модуля действительно ли выполнил похожую задачу?

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

Ещё одно наблюдение: по утрам понедельника я вижу, как L&D-менеджеры дважды нажимают на кнопку «отчёт». Они не уверены, что первое нажатие сработало. Я заметил и сказал внутренней команде, передал как обратную связь: рядом с кнопкой добавить маленький индикатор «загрузка». Добавили. Понедельничные клики упали вдвое.

8. Измерение — пишется до того, как траектория выйдет в эфир

Когда траектория выходит в эфир, работа не заканчивается; она, по сути, только начинается. Нужно отслеживать три слоя по отдельности:

• Завершение: сотрудник закончил модуль? (нижний слой)
• Производительность: какая кривая успеха в оценках? (средний слой)
• Эффект: реально ли изменились поведение и результат на работе? (верхний слой)

L&D-команда, смотрящая только на завершение, остаётся на самом слабом слое. Главный вопрос таков: бизнес-результаты завершившего траекторию отличаются от не завершившего? Чтобы ответить на этот вопрос, обучающие данные должны сцепляться с операционными; измерение, добавленное постфактум, чаще всего не достаёт до ответа. Поэтому я предлагаю писать план измерения вместе с дизайн-документом траектории.

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

Сценарий: 90-дневный онбординг менеджера по продажам

Чтобы конкретизировать восемь шагов, пройдём по примеру. Представим 90-дневную траекторию для нового менеджера по продажам. Классический подход: четыре недели продуктового тренинга, две недели тренинга по продажам, потом «удачи». Персонализированный подход работает иначе:

Отличие этого плана от классического онбординга в том, что после AI Gate на неделе 2 никакие два сотрудника не идут одной и той же дорогой. Пришедший из соответствующей отрасли быстрее проходит продуктовые модули; тем, кто буксует в переговорах, добавляются дополнительные сценарии; тем, у кого слабый поведенческий сигнал, отправляется приглашение на коучинг. Та же рамка работает и для нового оператора на производственной линии: базовый модуль безопасности → сканирование знаний по машине через AI Gate → специфичное обучение оператора → практическое наблюдение → подтверждение компетенции.

Не шаблон, а правила

Суть проектирования персонализированной обучающей траектории — перевернуть привычку. В классическом дизайне шаблон замораживается, контент фиксируется; единственный слой персонализации — индивидуальная мотивация сотрудника. В персонализированном дизайне же дизайнер пишет правила траектории. Шаблон остаётся неизменным; правила производят разные результаты для каждого сотрудника. AI Gates и AI Rules — это место, где эти правила пишутся и работают.

Практические рекомендации командам, желающим перейти к этому подходу:

• Не пытайтесь в ближайшем квартале охватить все роли. Выберите одну — желательно ту, где онбординг наиболее критичен.
• Не стройте библиотеку модулей с нуля; начните с разбиения существующего контента. Поставьте теги в первый день.
• В первой версии начните с двух AI Gate; через три месяца увеличивайте сложность ветвления.
• Напишите план измерений до того, как траектория выйдет в эфир.

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