Первый день на новой работе похож на первый день в университете:

• кругом незнакомые лица

• ничего не понятно

• какие-то новые дисциплины и правила (технологии и процессы)

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

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

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

Личный опыт онбординга

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

Компания 1

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

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

Компания 2

После увольнения из “Компании 1” у меня всё ещё присутствуют фантомные боли от онбординга (от его отсутствия). К счастью, в первый рабочий день в “Компании 2” всё выглядит гораздо лучше. Мне пообещали:

• Прислать руководство пользователя, которое поможет ознакомиться с продуктом

• Дать доступы к тасктрекеру и исходному коду

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

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

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

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

• Я понятия не имел, к кому обращаться за помощью и ревью моего кода, поэтому я словно на маленькой лодке с вёслами греб изо всех сил в бушующем океане, стараясь не утонуть

• Стендапов так и не было

• Но руководство пользователя и доступы я всё-таки получил в первые пару дней!

Ко всему прочему проект оказался абсолютно неинтересным (от слова совсем), и в скором времени я нашёл новую работу.

Тут стоит отметить, что команда команде — рознь, во многих других командах всё было совершенно иначе:

• Велись базы знаний

• Стендапы

• Демо

Компания 3

Тут я попадаю в стартап и, в принципе, всё напоминает предыдущий опыт, с небольшими изменениями:

• Доступы дают относительно быстро

• Из документации — исходный код и знания, находящиеся в головах у людей

• Сразу боевые задачи

• Но теперь у меня есть тимлид, который сидит со мной в одном офисе, ревьюит мои изменения, обсуждает требования и во всём мне помогает

Бонусный пример — Проект «Феникс»

Если вы читали бизнес роман Проект «Феникс», то вам наверняка знакомо имя Брента. Брент — незаменимый специалист для компании, лишь он может решить самые сложные проблемы и сбои, происходящие в IT-команде. Он — очевидное бутылочное горлышко, которое существуют во многих компаниях.

Все попытки нанять новых сотрудников, чтобы разгрузить Брента и задействовать его на критически важных проектах для бизнеса, проваливаются одна за другой, бОльшую часть проблем всё равно решает Брент. Другие сотрудники не знают, как работают все системы, и постоянно обращаются к Бренту.

Когда у Брента спрашивают как он решил задачу, он отвечает: «Не знаю, просто взял и сделал», что также затрудняет передачу знаний другим сотрудникам.

Те, кто читал книгу могут догадаться — всему виной плохой онбординг новых сотрудников! Как можно разгрузить Брента, если только он знает, как работают определённые системы?

И только спустя какое-то время проблему удается решить. С помощью чего? Правильно! С помощью документации, которая будет доступна для новых сотрудников. Были предприняты следующие решения:

• Создана группа людей, которые занимаются проблемами вместо Брента

• Если им нужна его помощь — Брент должен объяснять сотрудникам как решить проблему, а они в свою очередь должны задокументировать решение. Самостоятельно решать проблемы Бренту запрещено. В дальнейшем по аналогичным задачам к Бренту также обращаться запрещено.

Помимо этого важно упомянуть, что Брент был не единственной проблемой. В компании был недостаток IT-специалистов. В то же время пройдёт от полугода до года, пока сотрудник обучится и начнёт приносить пользу. Эту проблему также можно было бы решить с помощью хорошего онбординга, который бы ускорил этот процесс и сотрудники быстрее бы начали приносить пользу.

Выводы

Я думаю вы уже поняли, что плохой онбординг – это достаточно распространённая проблема, многие часто не понимают зачем “тратить на него время” — дали доступы, поставили задачи и вперед, вот и получается, что “спасение утопающих — дело рук самих топающих”.

Из этих всех примеров можно выделить следующие проблемы плохого онбординга:

• Сотрудник долго выходит на требуемую производительность

• Компания получает меньше пользы от сотрудника

• Сотрудник находится в стрессовой ситуации и компания рискует потерять его ещё на страте

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

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

• С чем-то разобрался сам

• Обсудили что-то с коллегой у кулера

• Что-то увидел на демо презентации

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

• Удалил странный код, из-за чего легли все интеграционные тесты — но зато теперь ты знаешь как работает та или иная часть системы

Теперь, когда мы рассмотрели примеры, у вас должно сложиться представление о плохом онбординге и о том, как делать не нужно.

Правильный онбординг

Скорее всего вы уже сделали выводы и понимаете почему онбординг важен, но всё же давайте выделим основные моменты:

• Онбординг — это первое с чем сталкивается новый сотрудник, поэтому его оценка компании напрямую зависит от онбординга

• При плохом онбординге сотрудник долго выходит на желаемую производительность

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

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

Хороший онбординг выгоден всем:

• Сотрудник быстрее приносит реальную пользу компании, тратит меньше времени, сил и нервов

• Бизнес тратит меньше денег на выход специалиста на нужную производительность

• Работники меньше тратят времени на онбординг и занимаются решением бизнес задач

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

• Документация/Система управления знаниями

• Ментор

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

• Система онбординга комфорт-класса — доклад с Teamlead conf

• Podlodka #302 — Онбординг

Документация

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

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

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

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

Выбор инструмента

Я думаю многие использовали Notion и Confluence для ведения документации. Но время сейчас неспокойное, как я уже упоминал в своей статье о Notion многие компании покидают Российский рынок, поэтому существует риск блокировок и потери всей ценной информации. Например, в марте прошлого года Notion заблокировал аккаунты некоторых Российских пользователей. Поддержка говорит это было сделано по ошибке, и в скором времени всё восстановили, но кто сказал, что это не произойдёт в будущем, если ситуация станет ещё хуже? Поэтому я решил посмотреть на Российские аналоги.

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

TEAMLY

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

ℹ️ То каким образом вести базу знаний можно растянуть на несколько больших статей, поэтому тут я расскажу только об основных особенностях системы. Но, если вам интересная тема управления знаниями и вы действительно хотите в неё погрузиться — можете начать с Прагматичного гайда по Управлению Знаниями.

Статьи

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

Редактор статей вполне удобный, я бы сказал, что он заключает в себе простоту Notion и возможности Google Docs, поэтому разобраться будет достаточно просто.

Для коллективной работы над знаниями:

• Вверху отображается список сотрудников, работающих в данный момент над статьей

• Есть возможность оставлять комментарии к тексту

• Есть чат для обсуждения статьи

Здесь перечислены все элементы, которые поддерживаются в редакторе.

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

Одна из вещей, которая зацепила в редакторе — макеты, позволяющие полноценно верстать:

• Два столбца

• Три столбца

• Правая боковая панель

• Левая боковая панель

• Три столбца с боковыми панелями

Пространства

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

• основные технологии

• архитектуру

• процессы

• и так далее

Почему не Google Docs?

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

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

К тому же, ваши документы будут просто пылиться. Чтобы приносить пользу — документация должна работать, сотрудники должны её читать. Для этого в тимли предусмотрены: курсы, тесты и опросы.

Курсы

Самая большая претензия к документации – её никто не читает. Для решения этой проблемы в тимли реализовы Курсы, которые можно создавать на основе ранее написанных статей. Например, вы можно создать курс для онбординга и отслеживать прогресс нового сотрудника.

Каждый курс состоит из уроков, в которых мы можем отдельно раскрыть интересующую нас тему.

Именно при создании уроков нам пригодится написанная нами документация.

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

Помимо этого мы можем добавлять текстовые блоки, если мы хотим добавить дополнительную информацию.

Если вы не хотите использовать статью для урока, вы просто можете составить весь урок из текстовых блоков.

Тесты и Опросы

Также в конце онбординга важно взять обратную связь и проверить знания нового сотрудника, для этого можно использовать “Тесты и Опросы”.

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

Также тесты и опросы можно использовать при создании курсов. Каждый урок состоит из двух частей:

• Материал

• Задание

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

Новостная лента

Новостная лента поможет не упустить новые статьи и обновления в базе знаний. Этой функции очень не хватало, когда мы использовали GitLab Wiki. Когда я открывал документацию, достаточно часто замечал, что кто-то из коллег добавил новую статью, но те, кто не любят читать документацию, конечно, этого не замечали.

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

Списки на ознакомление

Как дополнение курсам для онбординга нового сотрудника вы можете использовать “Списки на ознакомление”. Список на ознакомление — просто набор статей. Например, вы можете собрать основные статьи, которые не нужно запоминать новому сотруднику. Он может с ними “ознакомиться” и просто знать, что такая информация существует, в дальнейшем, если потребуется, он сможет вернуться к ней и ознакомиться подробнее. Например, список на ознакомление для новичка может выглядеть следующим образом:

• О компании

• Ценности

• Командировки

• ДМС

• Структура команды

• Матрица компетенций

• …

Мобильное приложение

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

• листать новостную ленту

• просматривать пространства

• читать статьи

• открывать файлы

• и проходить тесты и опросы

Миграция из Confluence

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

Дополнительные приёмы

Несмотря на то, что в статье в основном рассматривается система управления знаниями, я бы хотел перечислить и другие приёмы, которые будут полезны при онбординге

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

• Парное программирование — во время парного программирования с человеком, который уже погружен проект, новичок быстрее обучится и поймёт что к чему в проекте.

• Матрица скиллов — поможет оценить уровень новых сотрудников и определить их слабые места над которыми необходимо поработать. Кратко матрице скиллов я писал здесь. Чтобы разобраться — посмотрите эти видео:

  • Универсальная карта компетенций

  • Матрица компетенций как инструмент тимлида

• Онбординг может состоять из 2 частей:

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

    • Продажники должны знать, что они продают

    • Разработчики должна знать, что они разрабатывают

    • Тестировщики должны понимать, как тестировать продукт

  • Локальная часть — на уровне команды или проекта, ведь каждая команда (продажники, разработчики, тестировщики) уникальна и имеет свои собственные особенности и процессы

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

Напоследок

Было бы круто, если бы вы смогли поделиться примерами хорошего и плохого онбординга из вашего личного опыта в комментариях, а также какими платформами для управления знаниями пользуетесь вы?