Как платформа управления знаниями упрощает онбординг — TEAMLY

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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