Сегодня поговорим о разработке обучающих материалов и тренингов в софтверных компаниях. И на своем опыте, и опыте коллег из других компаний я вижу, что далеко не всегда этот процесс полностью налажен, а иногда и не налажен вовсе (например, обучающими материалами занимается инженер или сотрудник технической поддержки, да и то по остаточному принципу).
В этой статье ответим на следующие вопросы:
Сразу уточню, что речь пойдет об обучающих материалах для относительно сложных в установке и использовании программных продуктов, к которым можно отнести решения enterprise-класса — от ERP-систем, до облачных платформ для сервис-провайдеров, примером которой может быть Odin Service Automation). Обычно разработкой таких решений занимаются команды 50-150 человек, а пользуются продуктом разные категории пользователей:
Создание тренингов для менее комплексных продуктов, таких как веб- или мобильное приложение для конечного пользователя — тема отдельной статьи.
Изначально наш отдел обучения существовал в виде двух отдельных департаментов, и вот почему:
Со временем стало ясно, что будет оптимально, если отдел образования будет один — и их объединили.
Совет компаниям, которые только задумываются об образовании как отдельном направлении: в большинстве случаев внутренние и внешние тренинги довольно сильно пересекаются по темам, поэтому лучше, если этим будет заниматься одна команда. Ниже я хочу привести несколько примеров, о чем могут быть ваши тренинги:
В данный момент у нас в отделе образования работают 10 человек, каждый из которых обладает экспертизой по одному или нескольким продуктам, а суммарно мы покрываем запросы по созданию материалов для всех продуктов компании.
Сотрудник отдела обучения должен обладать двумя ключевыми навыками, а именно: обладать компетенцией в самом продукте (на уровне инженера) и уметь представлять эти знания в удобном для обучения виде. Также стоит уточнить, что у нас действует четкое разграничение между сотрудниками, которые создают тренинг, и тренерами, которые этот тренинг читают. Это две разных специальности, которые можно сравнить с изучением английского языка: есть методисты, которые составляют учебники и материалы, а есть учителя, которые учат, пользуясь этими учебниками.
На сегодняшний день в Odin (прим.Odin — новый бренд Parallels, который объединяет ПО для хостинга и сервис-провайдеров) разработаны тренинги по всем продуктам, и в среднем читается от одного до трех тренингов в неделю (один тренинг занимает два-три рабочих дня). Планирование расписания идет на несколько месяцев вперед.
Прежде чем описывать процессы и давать советы, я хочу уточнить, почему все-таки тренинги важны? Ведь есть документация, где можно узнать технические спецификации по ПО, есть служба поддержки, где можно задать вопросы.
Использование обучающих программ помогает сотрудникам клиента максимально быстро и комфортно познакомиться с продуктами и начать с ними работать. Даже если стоимость тренинга довольно высока для клиента, все равно ему это будет выгодно, так как займет всего несколько дней вместо нескольких недель самостоятельного изучения.
Кроме того, в сложных случаях компания-партнер может вообще отказаться от использования даже очень качественного комплексного продукта, если вы не предлагаете тренинги по причине отсутствия такой команды у вас в штате или по другим соображениям.
Совет: Предлагайте клиенту или разрабатывайте разные методы обучения. От этого зависит процесс усваивания информации Обучение с помощью качественных материалов и тренера-эксперта гораздо эффективнее, чем самостоятельное чтение документации, с точки зрения потраченного времени/результата.
Мы создали следующие уровни тренингов:
Этих уровней хватает, чтобы покрыть большинство запросов клиентов.
С чего начинается создание тренинга? Предположим, что у нас уже есть запрос на конкретный тренинг по конкретному продукту. В таком случае, нам нужно определить следующие параметры:
Когда требования к тренингу становятся ясны, можно переходить к формированию содержания тренинга – описывать, какие сценарии будут включены в тренинг, а какие включать не нужно. Здесь я хочу остановиться на слове «сценарий». Нас интересует не «фича» продукта в чистом виде, а при каком сценарии она будет использоваться.
Совет: рассмотрите типовые случаи использования вашего продукта и опирайтесь на них в первую очередь во время создания тренинга.
Чтобы понять эти сценарии, нужно получить информацию о них от клиентов, проще всего через коллег, которые с ними связаны. Так кто внутри вашей компании будет вашими руками и ушами о сценариях клиентов?:
Далеко не всегда сотрудники других отделов имеют возможность/желание участвовать в серии интервью. Тут нужно проявлять инициативу, объяснять, как именно тренинги помогут им:
Интервьюирование сотрудников – не единственный источник анализа входящей информации. Также можно проанализировать заявки от клиентов в службе поддержки (обычно нас интересуют how to вопросы, по которым мы составляем best practices, и проблемы клиентов, по которым мы составляем обучение troubleshooting навыкам). А еще мы можем поговорить с клиентами на конференции, понять тренды развития индустрии из тематических новостей и т.д. В общем, при подборе материалов мы не ограничены какими-либо конкретными источниками.
Когда все эти данные собраны, у нас появляется возможность создать outline (техническое задание для разработчика тренинга), по которому мы будем разрабатывать обучающие материалы. Важно заметить, что в outline мы указываем не только информацию о том, какие технические темы будут освещаться, но и как они будут освещаться (лекция, лабораторная работа, групповое обсуждение, чтение документации и т.д.)
На всех этапах разработки тренингов у нас присутствует процесс оценки. С его помощью мы можем устранить как технические недочеты (например, ошибки в синтаксисе кода примеров), так и получить полезную информацию по улучшению тренинга (например, в определенных темах выгоднее использовать практические примеры, нежели теорию и т.д.) Обычно оцека проходит в несколько этапов:
В зависимости от разных обстоятельств процесс может немного меняться: например, чаще всего разработчик может разрабатывать несколько модулей одновременно. То есть разрабатывать новые модули, пока предыдущие находятся на ревью. Или вообще разрабатывать тренинг не одному, а нескольким специалистам сразу.
Совет: Понимайте и продвигайте важность создания тренингов, для этого нужно получить союзников в компании из нескольких отделов (менеджмент, инжиниринг и т.д.)
Резюмирую: все эти данные (целевая аудитория, техническая информация, методы предоставления обучения, временной объем конкретный модулей и т.д.) чрезвычайно важны на начальном этапе. Как известно, чем лучше архитекторы спроектируют приложение, тем меньше будет проблем на этапе разработки. Точно так же это работает и для создания обучающих материалов – составление подробного outline гарантирует нам создание полного и качественного тренинга.
Исходя из наработанного опыта, чаще всего тренинг нужно синхронизировать с релизом продукта (если мы не говорим об экспертном уровне, где информация собирается уже по наработанным кейсам, после выхода продукта). Обычно мы планируем разработку тренингов на год вперед таким образом, чтобы они были доступны сразу после релиза.
Если с выпуском тренинга все понятно, то как рассчитать примерное время работы? Мы исходим из того, что на один час тренинга приходится 35 часов разработки. На первый взгляд кажется, что это очень долго, но это не так. Рассмотрев набор материалов тренинга ниже, легко увидеть, что времени на создание тратится не так уж и много.
Существует много информации по публичным выступлениям (как проводить эти выступления, как учить взрослых людей), поэтому я не буду раскрывать эту тему здесь. Хочу лишь остановиться на тех моментах, которые считаю важными:
Вся информация, описанная выше, касается только ILT тренингов (тренинг ведет инструктор), в данный момент мы также внедряем электронное (самостоятельное) обучение. Если вам интересна эта тема, дайте мне знать, и я расскажу про это в следующей статье.
С информацией о наших конкретных тренингах и датах проведения вы можете ознакомиться здесь.
Также мы ищем еще одного разработчика тренингов, если вам интересна такая позиция, подробнее вы сможете ознакомиться с ней по ссылке.
Если у вас есть какой-либо опыт, связанный с обучением в вашей компании – просьба поделиться им в комментариях.
В этой статье ответим на следующие вопросы:
- Планирование разработки обучающих материалов (сколько времени понадобится на разработку?)
- Анализ данных, которые должны попасть в тренинг: с кем проводить интервью? Как понять нужды клиентов?
- Тренинги внутри компании и тренинги для клиентов. В чем разница?
- Специфика проведения тренинга: оффлайн или вебинар?
- Какие обучающие материалы предоставляются и в чем их польза?
Сразу уточню, что речь пойдет об обучающих материалах для относительно сложных в установке и использовании программных продуктов, к которым можно отнести решения enterprise-класса — от ERP-систем, до облачных платформ для сервис-провайдеров, примером которой может быть Odin Service Automation). Обычно разработкой таких решений занимаются команды 50-150 человек, а пользуются продуктом разные категории пользователей:
- системные администраторы
- сотрудники техподдержки
- реселлеры
- конечные пользователи
- бухгалтеры
- маркетинг и специалисты по продажам
Создание тренингов для менее комплексных продуктов, таких как веб- или мобильное приложение для конечного пользователя — тема отдельной статьи.
Как это работает в нашей компании?
Изначально наш отдел обучения существовал в виде двух отдельных департаментов, и вот почему:
- В определенный момент в связи с очень большим кадровым расширением в новосибирском офисе нам понадобилось обучить множество новых инженеров поддержки за год. Было очевидно, что невыгодно проводить обучение с помощью уже состоявшихся инженеров, так как это надолго отключает их от основной работы. Пришли к выводу, что нужен отдельный человек, который будет обучать новичков full time. В итоге, этот отдел расширился до нескольких человек, чтобы обеспечивать оперативное обучение по всем продуктам внутри компании.
- В это же время в московском офисе стал зарождаться тренинговый отдел для клиентов. Причина проста: со сложным информационным продуктом им было нелегко разбираться самостоятельно. Тогда было принято решение посылать к клиентам ключевых сотрудников разработки. В этом решении были плюсы и минусы: с одной стороны, программисты обучали ИТ-администраторов или точно таких же инженеров, отвечающих за эксплуатацию нашего ПО на стороне клиента, а, стало быть, делали жизнь клиента легче. С другой — далеко не всегда было возможно выделить разработчика (а ему еще нужно было время, чтобы создать тренинг). Чаще всего разработчики любят программировать и не любят учить.
Со временем стало ясно, что будет оптимально, если отдел образования будет один — и их объединили.
Совет компаниям, которые только задумываются об образовании как отдельном направлении: в большинстве случаев внутренние и внешние тренинги довольно сильно пересекаются по темам, поэтому лучше, если этим будет заниматься одна команда. Ниже я хочу привести несколько примеров, о чем могут быть ваши тренинги:
- Базовое функционирование продукта – будут интересны новым клиентам, начинающим инженерам и разработчикам компании (сложно работать с продуктом, не представляя его базовой функциональности)
- Решение проблем – сотрудникам техподдержки и некоторым специалистам в организации клиентов (системным администраторам, сетевым инженерам и т.д.)
- Внутренние компоненты продуктов (интеграция со сторонними сервисами) – тренинг нужен и для системных интеграторов, и внутри компании.
В данный момент у нас в отделе образования работают 10 человек, каждый из которых обладает экспертизой по одному или нескольким продуктам, а суммарно мы покрываем запросы по созданию материалов для всех продуктов компании.
Сотрудник отдела обучения должен обладать двумя ключевыми навыками, а именно: обладать компетенцией в самом продукте (на уровне инженера) и уметь представлять эти знания в удобном для обучения виде. Также стоит уточнить, что у нас действует четкое разграничение между сотрудниками, которые создают тренинг, и тренерами, которые этот тренинг читают. Это две разных специальности, которые можно сравнить с изучением английского языка: есть методисты, которые составляют учебники и материалы, а есть учителя, которые учат, пользуясь этими учебниками.
На сегодняшний день в Odin (прим.Odin — новый бренд Parallels, который объединяет ПО для хостинга и сервис-провайдеров) разработаны тренинги по всем продуктам, и в среднем читается от одного до трех тренингов в неделю (один тренинг занимает два-три рабочих дня). Планирование расписания идет на несколько месяцев вперед.
Почему тренинги – это важно?
Прежде чем описывать процессы и давать советы, я хочу уточнить, почему все-таки тренинги важны? Ведь есть документация, где можно узнать технические спецификации по ПО, есть служба поддержки, где можно задать вопросы.
Использование обучающих программ помогает сотрудникам клиента максимально быстро и комфортно познакомиться с продуктами и начать с ними работать. Даже если стоимость тренинга довольно высока для клиента, все равно ему это будет выгодно, так как займет всего несколько дней вместо нескольких недель самостоятельного изучения.
Кроме того, в сложных случаях компания-партнер может вообще отказаться от использования даже очень качественного комплексного продукта, если вы не предлагаете тренинги по причине отсутствия такой команды у вас в штате или по другим соображениям.
Совет: Предлагайте клиенту или разрабатывайте разные методы обучения. От этого зависит процесс усваивания информации Обучение с помощью качественных материалов и тренера-эксперта гораздо эффективнее, чем самостоятельное чтение документации, с точки зрения потраченного времени/результата.
Виды тренингов
Мы создали следующие уровни тренингов:
- Associate – вводный тренинг, рассказывающий о продукте
- Professional – базовое использование продукта
- Expert – продвинутое использование (присутствует секция troubleshooting — решение проблем самостоятельно)
Этих уровней хватает, чтобы покрыть большинство запросов клиентов.
Составление структуры тренинга. Разработка материалов
С чего начинается создание тренинга? Предположим, что у нас уже есть запрос на конкретный тренинг по конкретному продукту. В таком случае, нам нужно определить следующие параметры:
- Главная цель тренинга – для чего пользователям нужно это обучение. Цель может звучать так: «после прохождения данного тренинга участники самостоятельно смогут установить продукт, выполнять базовые настройки и предоставлять сервис конечным пользователям». Обычно в цель попадают ответы на следующие вопросы:
- Чему будем учить?
- Кого будем учить?
- Что участники будут уметь после тренинга?
- Целевая аудитория – тренинг может быть предоставлен для разных специальностей: системных администраторов, архитекторов или сотрудников техподдержки
- Методы предоставления тренинга: оффлайн, онлайн. Обычно, если эта работа по большей части в UI, то пользователям комфортнее онлайн-посещение (но при онлайн-формате практика не предусмотрена, и участникам придется доучиваться самостоятельно). Оффлайн-тренинг будет предпочтительнее для обучения, в ходе которого пользователи решают много кейсов, причем разными путями (особенно это касается курсов, где мы учим инженеров программировать приложения под нашу платформу Odin Service Automation).
- Продолжительность тренинга – обычно это 16 часов для Professional уровня и 24 часа для Expert. В разумных пределах продолжительность может варьироваться, но она будет кратна дням (это делается для удобства студентов и тренера)
Когда требования к тренингу становятся ясны, можно переходить к формированию содержания тренинга – описывать, какие сценарии будут включены в тренинг, а какие включать не нужно. Здесь я хочу остановиться на слове «сценарий». Нас интересует не «фича» продукта в чистом виде, а при каком сценарии она будет использоваться.
Совет: рассмотрите типовые случаи использования вашего продукта и опирайтесь на них в первую очередь во время создания тренинга.
Чтобы понять эти сценарии, нужно получить информацию о них от клиентов, проще всего через коллег, которые с ними связаны. Так кто внутри вашей компании будет вашими руками и ушами о сценариях клиентов?:
- SME (Subject Matter Expert) Эксперт по продукту, им может быть продакт-менеджер, евангелист, или любой другой сотрудник, занимающий одну из ключевых ролей для продукта. Например, продакт-менеджер в продукте контейнерной виртуализации может рассказать не только почему конкретная функция важна, но и в каких случаях ее используют клиенты, и что в ней революционного.
- Sales-инженеры – коллеги, занимающиеся продажей наших решений. Так как они активно участвуют в подготовке требований и в продаже продукта, то понимают, каких знаний не хватает клиентам (какие вопросы они задают). Наиболее полезной эта информация будет для associate-тренинга.
- TAM (Technical Account Manager) – технические специалисты, которые «ведут» клиентов и находятся с ними в наиболее близких отношениях во время использования продукта. Они знают, насколько популярна конкретная функциональность продукта у клиентов и есть ли у них какие-либо проблемы с ее использованием (это может быть любая заявленная функция, например, «клиенты не умеют настраивать магазин в Odin Service Automation»).
Далеко не всегда сотрудники других отделов имеют возможность/желание участвовать в серии интервью. Тут нужно проявлять инициативу, объяснять, как именно тренинги помогут им:
- Sales могут продавать эти тренинги и получать от них прибыль
- Support и TAM очень любят подкованных в техническом плане клиентов – не будет простых запросов, и можно разговаривать на одном языке
- Разработчики могут быть уверены, что функциональность, которую они создали, будет понятна и использована по назначению.
Интервьюирование сотрудников – не единственный источник анализа входящей информации. Также можно проанализировать заявки от клиентов в службе поддержки (обычно нас интересуют how to вопросы, по которым мы составляем best practices, и проблемы клиентов, по которым мы составляем обучение troubleshooting навыкам). А еще мы можем поговорить с клиентами на конференции, понять тренды развития индустрии из тематических новостей и т.д. В общем, при подборе материалов мы не ограничены какими-либо конкретными источниками.
Когда все эти данные собраны, у нас появляется возможность создать outline (техническое задание для разработчика тренинга), по которому мы будем разрабатывать обучающие материалы. Важно заметить, что в outline мы указываем не только информацию о том, какие технические темы будут освещаться, но и как они будут освещаться (лекция, лабораторная работа, групповое обсуждение, чтение документации и т.д.)
На всех этапах разработки тренингов у нас присутствует процесс оценки. С его помощью мы можем устранить как технические недочеты (например, ошибки в синтаксисе кода примеров), так и получить полезную информацию по улучшению тренинга (например, в определенных темах выгоднее использовать практические примеры, нежели теорию и т.д.) Обычно оцека проходит в несколько этапов:
- Сотрудник разрабатывает конкретный модуль тренинга и отсылает его на внутреннее ревью (коллеге из своего отдела, такому же разработчику тренингов)
- Материалы дорабатываются с учетом полученных отзывов и посылаются на оценку эксперту продукта (SME)
- Полученные комментарии по модулю также применяются к тренингу, и можно начинать разработку следующего модуля.
В зависимости от разных обстоятельств процесс может немного меняться: например, чаще всего разработчик может разрабатывать несколько модулей одновременно. То есть разрабатывать новые модули, пока предыдущие находятся на ревью. Или вообще разрабатывать тренинг не одному, а нескольким специалистам сразу.
Совет: Понимайте и продвигайте важность создания тренингов, для этого нужно получить союзников в компании из нескольких отделов (менеджмент, инжиниринг и т.д.)
Резюмирую: все эти данные (целевая аудитория, техническая информация, методы предоставления обучения, временной объем конкретный модулей и т.д.) чрезвычайно важны на начальном этапе. Как известно, чем лучше архитекторы спроектируют приложение, тем меньше будет проблем на этапе разработки. Точно так же это работает и для создания обучающих материалов – составление подробного outline гарантирует нам создание полного и качественного тренинга.
Когда начинать создание тренинга? Как планировать время на создание?
Исходя из наработанного опыта, чаще всего тренинг нужно синхронизировать с релизом продукта (если мы не говорим об экспертном уровне, где информация собирается уже по наработанным кейсам, после выхода продукта). Обычно мы планируем разработку тренингов на год вперед таким образом, чтобы они были доступны сразу после релиза.
Если с выпуском тренинга все понятно, то как рассчитать примерное время работы? Мы исходим из того, что на один час тренинга приходится 35 часов разработки. На первый взгляд кажется, что это очень долго, но это не так. Рассмотрев набор материалов тренинга ниже, легко увидеть, что времени на создание тратится не так уж и много.
Основные компоненты тренинга
- Student guide – неотъемлемая часть тренинга. Этот документ содержит информацию о продукте (есть сходство с документацией, но здесь она представлена в логическом порядке с точки зрения эффективного обучения и скомпонована, опять же, с помощью реальных сценариев), а также теоретические и практические задания, например, создание и миграция подписки в Odin Service Automaition. Эта информация будет полезна для изучения студентами как во время, так и после тренинга, участник сможет освежить свои знания с помощью этого документа (вспомнить best practices). В зависимости от тренинга, объем гайда может занимать около 100 – 200 страниц
- PPT – Файлы презентаций. Нужны исключительно для тренера во время тренинга (вся информация из них содержится в Student Guide) Обычно там показаны диаграммы, интеграция компонентов, которые используются для визуализации сложно объясняемых материалов
- Instructor guide – Отдельный документ для тренера, который содержит информацию, как читать этот тренинг (сколько времени тратить на конкретные топики, как проводить практические упражнения, когда перерывы, на чем надо сделать акцент). Тренеры-«новички», которые читают этот тренинг в первый раз, высоко ценят этот гайд (или когда этот тренинг проходит редко и нужно освежить эти знания)
- Sandbox– каждый участник тренинга должен иметь свою рабочую инфраструктуру продукта (в случае с Odin Service Automation это будет 8 виртуальных машин, где у каждой будет своя роль). Проводить тренинги на инсталляции клиента получается далеко не всегда (хотя учиться работать в своей среде все же лучше). Поэтому мы разработали систему предоставления сэндбоксов, которая автоматически поднимает такие «песочницы»
- Assessment – 10 технических вопросов по продукту, на которые участники отвечают до и после тренинга. Таким образом можно измерить, насколько эффективным был тренинг.
- Certification – для каждого тренинга составляются вопросы на сертификацию (студенту нужно ответить на 20 вопросов в течение определенного времени). Если участник успешно отвечает на вопросы, то получает сертификат по конкретному продукту.
Во время тренинга:
Существует много информации по публичным выступлениям (как проводить эти выступления, как учить взрослых людей), поэтому я не буду раскрывать эту тему здесь. Хочу лишь остановиться на тех моментах, которые считаю важными:
- Комбинируйте теоретическую и практическую часть, так студенты больше вовлечены в процесс. Раньше мы работали по следующей системе: один день практики, один день теории, но пришли к выводу, что комбинирование гораздо лучше. Например, наш тренинг по виртуализации, который читался в виде: два дня теории, два дня практики, претерпел изменения и сейчас в течение каждого дня у нас есть несколько переключений в день между лабораторными работами и лекцией.
- Позаботьтесь о том, чтобы всем участникам тренинга было комфортно, раскрепостите их (расскажите историю из своей практики, попросите их рассказать о своем опыте, ожиданиях от тренинга и т.д.)
- Вовлекайте всех студентов в процесс, старайтесь завязать дискуссию. Например, студент задает какой-либо вопрос, а вы его переадресовываете аудитории и спрашиваете их мнение. Обычно в аудитории всегда есть senior специалисты, которые любят быть экспертами, когда их об этом просят.
- Используйте правило десяти секунд – если вы задали вопрос и никто не отвечает, просто молча посчитайте до десяти, и обязательно найдется тот, кто не выдержит и захочет ответить.
- Позаботьтесь, чтобы на тренинг попали только сотрудники из соответствующей целевой аудитории. Пример: не стоит приглашать бухгалтеров на сложный технический тренинг для инженеров (а такие случаи были).
- Бывают случаи, когда студенты задают вопрос, на который вы не можете ответить сразу (даже являясь экспертом в этой области). Такие ситуации неизбежны. Просто получите вопрос, пообещайте, что проясните его и обсудите его на следующий день тренинга или по почте.
- Клиенты могут жаловаться на конкретные технические проблемы, с которыми они сталкиваются в работе. В данном случае нужно перенаправлять такие запросы к аккаунт менеджеру, если вы не можете ответить сразу. Отсылка к аккаунт менеджеру — это частный случай, но нужно знать правильные пути направления клиента в конкретной ситуации.
- Размер рекомендуемой аудитории для оффлайн-тренинга: 7 человек (если больше – становится тяжелее контролировать, что все усваивают материал). Для онлайн размер может быть неограничен.
- Обязательно собирайте отзывы после тренинга, в дальнейшем он поможет улучшить материалы. Мы это делаем с помощью специальной формы, которая дается в последнюю минуту тренинга (если вы вышлете анкету на почту, не рассчитывайте что получите много ответов).
Заключение
Вся информация, описанная выше, касается только ILT тренингов (тренинг ведет инструктор), в данный момент мы также внедряем электронное (самостоятельное) обучение. Если вам интересна эта тема, дайте мне знать, и я расскажу про это в следующей статье.
С информацией о наших конкретных тренингах и датах проведения вы можете ознакомиться здесь.
Также мы ищем еще одного разработчика тренингов, если вам интересна такая позиция, подробнее вы сможете ознакомиться с ней по ссылке.
Если у вас есть какой-либо опыт, связанный с обучением в вашей компании – просьба поделиться им в комментариях.