Три основных проблемы в онбординге

«Первый месяц новичка — как первая глава книги. Если она скучная или слишком сложная, книгу откладывают».

— Народная мудрость в KM-сообществе

Привет! Меня зовут Екатерина Софронова, и я управляю знаниями в компании ISPsystem.

 «Управление знаниями» звучит, как что-то супергеройское, вроде управления погодой из фильма Макото Синкая. На деле, мои обязанности вполне земные. Я пишу стандарты, регламенты и пользовательские инструкции; слежу за актуальностью материалов; участвую в процессах онбординга и обучения; продвигаю культуру шаринга знаний в клиентском сервисе и не только. Тянет на суперспособности? Возможно, со временем я вырасту до Wonderwoman клиентского сервиса, а пока что моя цель проста: повысить качество сервиса и скорость адаптации новых сотрудников через актуальные и понятные материалы. А моя миссия — превращать разрозненные знания в чёткие инструкции и стандарты, чтобы помочь командам работать эффективнее, а клиентам — быстрее и проще находить ответы. 

Пишу эту статью, потому что в прошлом она бы мне очень пригодилась. В компаниях с технологически сложными продуктами полный цикл онбординга может занимать до 9 месяцев. Это значит, что зачастую полноценной боевой единицей специалист становится уже после прохождения испытательного срока (ИС). 9 месяцев — это, хоть и очень символичный срок для рождения классного инженера, но невообразимо долгий и дорогой. К тому же, такой длинный период онбординга несёт риск ошибочого найма из-за невозможности полноценно оценить новичка за время формального испытательного срока. Поэтому очевидно желание владельцев процесса и руководителей сократить сроки адаптации новичков.

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

Три кита

Хорошая новость: базовых проблем, которые чаще всего тормозят онбординг, всего три. 

Ниже я представила три проблемы в классическом онбординге в виде трёх китов. Это коррелирует с понятием устаревшей (плоской) модели.

Три проблемы, которые блокируют эффективность онбординга:

1. Информационная перегрузка. Новичок получает 100500 ссылок и инструкций и доступ к 100 системам в первые дни работы. Угадайте, что из полученного он усвоит?

2. «Инфобункер». Информация разбросана между чатами, почтами, системами и головами коллег (что хуже и опаснее всего), список можно продолжать долго. Инфобункер усложняет поиск информации, появляется риск дублирования решений.

3. Зависимость от ментора. Если ментор в отпуске, процесс встаёт. Ментор занят, процесс встаёт. Ментор уволился, … В общем, да. Без ментора никак не идёт процесс. 

Информационная перегрузка

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

— Элвин Тоффлер (Alvin Toffler), американский философ, социолог и футуролог

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

• 100 ссылок на документацию;

• 5 систем-инструментов (Ютрек, Омнидеск, Confluence);

• 15 аббревиатур и сложных терминов, значение которых он не может вообразить;

• 250 особенностей продуктов.

iPobrecito! ( с исп. «бедняга», «бедненький») И всё это в тот период адаптации, когда новый сотрудник ещё не вполне понимает, чем занимается компания и чем полезны её продукты.

В итоге получаем нерадостные последствия:

• 60% информации забывается через 48 часов. Это эффект Эббингауза. Про него есть много информации в открытых источниках. Например, статьи 5 Ways to Challenge the Forgetting Curve и статья на Хабре Кривая Эббингауза: как хакнуть свою память и запоминать до 95% информации;

• сотрудник изучает не то и не там;

• сотрудник теряет мотивацию, потому что думает: «я никогда это не освою (см. про это ниже)»;

• медленная адаптация 🐌;

• низкая эффективность сотрудника.

📝 Про «я никогда это не освою»

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

Кажется, теперь я поняла, почему бесконечно откладываю чтение «Бесконечной шутки» Дэвида Фостера Уоллеса (Infinite Jest, David Foster Wallace) 🙂. Попробую сменить концепт и прочитать по методу разбивки на микро-блоки.

Вариантов решений несколько. Можно комбинировать или выбрать что-то одно.  

Микрообучение

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

Суть микрообучения схожа с базовым принципом тайм менеджмента. Разбиваем слона на маленьких слонят и едим по кускам (я за защиту животных, ни один слон не пострадал и не был съеден).

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

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

Минусы у подхода есть. Не всем удобно видео, есть вопрос хранения материалов, выбор стилистики. Но главный вопрос один: кто будет делать видео?

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

Что делать:

• начните с оптимизации одной статьи или большой задачи ИС;

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

• откажитесь от перфекционизма. Не стремитесь сделать профессиональные видео. Сделайте их максимально полезными;

• не забывайте, что видео должны быть короткими, до десяти минут;

• пусть формат видео позволяет смотреть его без звука. Если требуется, добавьте субтитры;

• отдайте пробный ролик на «затест» коллеге из другого отдела. Будет ли видео понятно ему?

Ну, а дальше (это главное 🎶), включите обучающие видео в план онбординга или создайте из них мини обучающие курсы. 

Не заменяйте видео-материалами текст. Видео дополняют, но не заменяют инструкции. 

Инструментами для микрообучения можно выбрать платформы LMS, такие, как Moodle, Knomary.

В целом, видео — не обязательный элемент. Главное в микрообучении — разбивка большого блока информации на маленькие. Замените одну большую лекцию группой мини-курсов. Если у этих блоков будет комбинированный формат, вы получите ускорение восприятия. Например, в одной лекции совместите текст, видео и мини-тест.

Поделюсь опытом собственнного онбординга. В первые дни адаптации на меня свалилась именно она, снежная лавина информации. Кроме бизнес-процессов, было много технически сложной информации. И у меня были мысли о том, что я «никогда это не освою». Справиться с информационной перегрузкой мне помогла мотивация к работе. Я просто очень, ну очень хотела попасть в компанию ISPsystem! Была готова выучить всё, что требуется и работать овертайм до тех пор, пока не научусь. Я постоянно сомневалась в себе, жутко стрессовала и боялась задать лишний вопрос ментору (хотя ментор мне попался замечательный, Ольга, привет!). В итоге у меня всё получилось. Но иногда я вспоминаю свой онбординг и думаю, как было бы круто, если бы мне тогда преподнесли информацию дозированно, то есть по методу микрообучения.

«Дорожная карта» для новичка

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

• видит все этапы своего обучения с высоты «птичьего полёта», на карте;

• чётко понимает цели; 

• не зависит от ментора. Способен самостоятельно приступить к следующему этапу.

Алгоритм изготовления карты:

• Создайте поэтапный план на первые 30 дней ИС с чёткими целями:

  • День 1: Научиться работать с документацией и БЗ.

  • День 5: Изучить логику работы продукта.

  • Неделя 1: Решать тикеты самостоятельно в продакшне. 

• Опишите ожидаемый результат длинных дистанций. Например, месяц 1: сотрудник знает первое, умеет второе.

• Аналогично составьте план для оставшегося периода ИС.

Хак 💡

Визуализируйте роадмап стажёра. Используйте инструменты визуализации, такие, как Miro или платформы LMS, TMS.

Например, мы для изготовления карты ИС использовали TMS Knomary. В ней есть возможность разделить активности на «команду» и «сотрудника» и составить план не только для новичка, но для бадди или ментора. В каждую активность можно зайти и увидеть подробные шаги выполнения.

Тестовые среды

У Андре Моруа были фиалки по средам, а романтика инженера куда прозаичнее 🙂

«Фиалки по средам» (1953 г.) — сборник новелл Андре Моруа, прославивший писателя ещё при жизни.

Суть стратегии тестовых сред — предоставить новичку неограниченный доступ к песочнице (тестовому стенду, фейковой тикетнице). То есть туда, где новичку можно и нужно ошибаться. Классно будет, если вы дополнительно подготовите серию практических заданий для отработки инцидентов на тестовых стендах.

Вот и вся стратегия. Дайте новичку простор для творчества и кейсы, имитирующие продакшн.

Бункер знаний

Silo — в знаниях

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

Бункер знаний (информационный бункер, силос знаний, Information Silo(s), knowledge silo(s)) — это ситуация, когда информация хранится изолированно в разных отделах, системах или у отдельных сотрудников, и это мешает её свободному движению, обмену и использованию.

Анализируя оригинальный термин “information silo(s)”, я пришла к выводу, что он может происходить из сельского хозяйства, где зерно хранят в отдельных силосных башнях (silos).

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

По аналогии с бункером, в компаниях, где есть изоляция информации, знания «заперты». Например:

• отдел разработки знает про баги, но не делится с поддержкой;

• сотрудники хранят свои знания, процессы, результаты работы в локальных excel-файлах;

• инженеры фиксируют ключевые решения в личных заметках;

• в базе знаний настолько сложная структура, что знания оказываются спрятаны глубоко в её «недрах». То есть ответы на вопросы есть, но до них не добраться. 

Скорее всего, вам что-то из перечисленного знакомо. Теперь вы ещё знаете для этого термин. Бункер знаний. 

Рекомендую изучить статью по теме: Think Information Silos Are Only Cross-Functional? Think Again. Подробно и практично раскрывает базовое понятие информационной изоляции. 

Проблема и решение

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

• тратят в разы больше времени на поиск ответов;

• дублируют работу: решают задачу, когда её уже решили коллеги. Решили, и немного эгоистично сохранили решение в «избранном» своего Телеграма. 😁

Чтобы решить проблему «бункера»:

1. Создайте источник истины в виде единственной и неповторимой базы знаний (неповторимой в прямом смысле, потому что дублей в БЗ следует избегать, а если есть — устранять), которая содержит информацию из всех разрозненных источников.

2. Внедрите культуру документирования. Это не просто норма, а новый тренд. Документируют все владельцы знаний! Правят БЗ (или предлагают правки) тоже все. Вот такой корпоративный стиль. Как внедрить? Например, введите правила: объяснил коллеге, зафиксируй в базе знаний. Решил инцидент — зафиксируй. И так далее. Попробуйте донести преимущества этого подхода (это не дополнительная работа, а, напротив, поможет снизить нагрузку в будущем) и поощрить сотрудников за шаги в направлении документирования.

3. Интегрируйте системы. Пусть всё работает в тандеме. Синхронизируйте системы, настройте связи с помощью плагинов или API.

💡Красота — в простоте

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

1. Ограничьте вложенность. Пусть в вашей структуре будет не более четырёх уровней вложенности. Например, вместо «Продукты → VMmanager 6 → Проблемы → ВМ → Не запускается → Логи → Как собрать логи → Для Astra Linux» создайте путь «Продукты → VMmanager 6 → Для Astra Linux» (три уровня).Или сделайте раздел «Для Astra Linux» частью другой статьи. Честно скажу, в нашей внутренней базе есть проблемы с уровнями вложенности, но мы уже на правильном пути 🙂. 

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

3. Объедините похожие статьи. Например, стоит объединить в одну статьи базы знаний «FAQ. DNSmanager 6» и «DNSmanager. Проблемы и решения».

4. Стандартизируйте названия. Например, если в вашей базе знаний присутствуют одновременно статьи с названием «Вопрос-ответ» и «FAQ», это усложнит процесс актуализации и поиск нужного.

5. Следите за актуальностью статей и периодически наводите порядок в пространстве. Своевременно переносите в архив неактуальные статьи или статьи без просмотров за год. Также можно назначить кураторов знаний. Это «хранители» знаний в каждом подразделении, ответственные за актуализацию. 

6. Переносите, а не удаляйте. Это важно. Да, в сети есть куча профессиональных шуток про архивы и их масштабы, но точно говорю: не удаляйте статьи. 🙂 У нас в компании неоднократно случалось, что удалённую информацию требовалось реанимировать. И с этим проблем не было, потому что ничего не было удалено. В нашей документации есть специальное пространство для архивных статей. И я переношу туда даже неактуальные отрывки из действующих статей, чтобы текст можно было найти через поиск, а не просто восстановить фрагмент через «откат» к старым версиям статьи. А для EOL-продуктов есть отдельный раздел в актуальной базе знаний.

Зависимость от ментора

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

Брюс Ли, актёр, философ, мастер боевых искусств

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

Проблема зависимости от ментора в разрезе:

1. Ментор перегружен задачами и не успевает уделять время новичку.

2. Новичок боится проявлять инициативу, задавать вопросы и пр.

3. Взаимодействие «наставник - стажер» происходит гораздо реже, чем нужно для быстрого погружения.

4. Если наставник уходит в отпуск или увольняется, процесс адаптации останавливается, серьёзно стагнирует или рушится. 

5. Скорость онбординга падает в разы.

6. Привет, выгорание! Это сейчас про менторов. Стажёрам на этапе онбординга рано выгорать, а вот риск потери интереса, мотивации и преждевременного увольнения имеется.
   

Решение состоит из трёх стратегий.

1. Распределение ролей. Пусть в онбординге участвует несколько менторов. Например, ментор 1 объясняет API, ментор 2 тренирует по ответам в тикетах. Такое разнообразие пойдёт на пользу. Эффективность онбординга возрастёт. Плюсы:

   — Если один ментор отсутствует, второй сможет подхватить обучение. 

   — Социализация. Новичку супер-важно общение с коллективом, а особенно, с разными экспертами. 

   — Разноплановое обучение. С одним ментором стажёр может получить однобокое представление о работе и не узнать разные техники и подходы к решению проблем. Наставник может быть экспертом в одной области и не практиковать или не любить другие. С несколькими менторами должностной пазл прекрасно сложится 🙂

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

2. Смена наставника. Один день в неделю стажёр работает в паре с другим коллегой. Так новичок узнáет что-то новое, получит возможность посмотреть на процесс с разных сторон, увидит несколько точек зрения. 

3. Самостоятельность. Создайте максимум условий для самостоятельности стажёра:

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

   — Подробный FAQ из топовых вопросов новичков.

   — Введите правило пятнадцати минут: стажёр тратит 15 минут на поиск информации, только если не нашёл, идёт к ментору. Время может увеличиться в зависимости от сложности задачи.

Резюме решений трёх проблем

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

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

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

• время адаптации новичка сократится в разы.

Предлагаю зафиксировать план-перехват современного онбординга:

1. Внедряем микрообучение, добавляем больше практики и практикуем регулярные повторения изученного.

2. Добавляем дорожные карты ИС. Карты визуализируем для наглядности.

3. Создаём единую БЗ, где интегрируем все источники. 

4. Отказываемся от единственного ментора. Подключаем других коллег для увеличения взаимодействий с новичком и диверсификации опыта.

В качестве резюме предоставляю решение трёх проблем в формате таблицы — легко запомнить, легко применить:

📝 Бутылочное горлышко — это ситуация, когда эффективность всей системы (процесса, команды или компании) ограничивается одним узким местом, которое тормозит работу остальных элементов.

Завершить статью хочу ещё одной цитатой Элвина Тоффлера:

«Безграмотными в 21 веке будут не те, кто не умеет читать и писать, а те, кто не умеет учиться, разучиваться и переучиваться».

— Элвин Тоффлер (Alvin Toffler), американский философ, социолог и футуролог

P.S. Буду рада, если поделитесь опытом. С какими проблемами в онбординге сталкивались вы? Какие ещё похожие темы хотелось бы изучить?