Предыдущие статьи серии:
→ Фантастические таланты: Эпизод I – Призрачный найм
Часть 1: Перед рубежом новых вызовов
Воскресенье. Два разных человека, два разных взгляда на предстоящий день:
Специалист: «Завтра начинается новый этап в моей карьере. Как будет выглядеть мой первый день в новом проекте? Это будет быстрое погружение или дадут время раскачаться ? Какие задачи меня ждут на испытательном сроке?»
Руководитель: «Завтра в мою команду приходит новый сотрудник. Что ему поручить? Возьму-ка часть простых задач из текущего пула и дам новичку, пусть показывает себя».
Привет!
Cегодня я хочу поделиться своим опытом по онбордингу новых сотрудников в IT-команды. Чтобы глубже понять предложенные решения, давайте сначала окунемся в проблемы и боль — это необходимо, чтобы понять контекст.
Несколько лет назад я руководил проектом X в компании Y. В нашей команде было два бекендера, два фронтендера и один тестировщик. Бизнес решил значительно увеличить объем функционала продукта. В таких ситуациях обычно функционал продумывается, из него выделяется MVP-версия, которая затем декомпозируется на задачи для технической оценки и планирования ресурсов. В нашем случае мы столкнулись с тремя крупными фичами, каждая из которых требовала примерно по три человеко-месяца работы (бекенд и фронтенд поровну).
Варианты решения проблемы:
Заимствование ресурсов
В больших компаниях можно попытаться заимствовать ресурсы из других команд или спецназ-групп, если такие имеются.Поиск на рынке
Это часто утопичный вариант, так как найти нужное число квалифицированных специалистов за очень короткий срок бывает сложно.
К тому же команде нужно время, чтобы сработаться.Аутстаффинг
В случае крупных аутстафф-компаний, где уже сформированы команды, это вполне может быть эффективным решением.
Мы выбрали сочетание аутстаффинга и расширения штата.
Часть 2: Аутстаффинг: реальность и вызовы
Для полноты картины немного погрузимся в аутстаффинг.
Аутстаффинг в IT — это когда компания предоставляет своих разработчиков в аренду для участия в различных проектах. Этот подход часто выбирают, когда нужны специалисты на короткий срок, например, для стартапов или доработки продуктов.
Основная особенность таких проектов — относительно низкая техническая сложность и небольшие нагрузки. Прокачать знания вглубь в таких проектах довольно сложно.
Отсюда следует несколько важных нюансов:
Широкие, но неглубокие знания
Многие специалисты в аутстаффе обладают широким спектром знаний, но не углубляются в детали. Они часто переключаются с проекта на проект, а это не способствует глубокому погружению в конкретные технологии или продукты.Отсутствие долгосрочного интереса
Для многих разработчиков в аутстаффе ваш проект — это лишь один из многих. Сегодня они работают с вами, завтра могут перейти к другому заказчику. Это создает определенные трудности в построении долгосрочных отношений и вовлеченности в проект.
Несмотря на общую тенденцию, в аутстаффе можно встретить высокомотивированных специалистов с глубокими знаниями и идеями. И я таких знаю. Но такие случаи довольно редки.
Если у вас высокие требования к команде и нет проверенной компании-аутстаффа, подготовьтесь к тому, что вам придется перебирать людей/команды/компании.
Часть 3: Ломай меня полностью!
Боль — хороший мотиватор к изменениям с последующей трансформацией в кайф.
Итак, наша команда расширяется. Как интегрировать новичков в уникальный мир нашего проекта и компании? Классический подход: «Вот твой рабочий комп, вот репозиторий, вот задачи в Jira. Дерзай!» Будто мы говорим: «Добро пожаловать в джунгли, найди свой путь!»
Когда я впервые столкнулся с этим, мой подход был прост, — встреча, знакомство с командой, доступы, краткий экскурс по проекту. Но вот загвоздка: многие большие проекты, и мой в том числе – это не прогулка по парку, а, скорее, поход через Гималаи. Технически сложные, с множеством интеграций и нюансов. Иногда сотрудник, работая над одним набором фич, даже не подозревает о существовании других. Как только он сталкивается с новым, начинается либо изучение, либо... Ну, вы знаете, изобретение велосипеда.
И вот мы берем первую команду аутстаффа. Последовательно подключаются Петя, Вася, Коля... И вот, когда кажется, что все налажено, появляются новые Петя, Вася и Коля. И ты снова и снова рассказываешь одно и то же, отвечаешь на одни и те же вопросы.
А если в команду вливается 2–5 человек одновременно, начинаешь чувствовать себя как в «Дне сурка»: кто что знает? кто что слышал? кто еще ждет доступов?!
В один прекрасный момент ты задумываешься: «А точно ли я занимаюсь правильным делом? А я точно эффективно работаю? Может быть, меня заменить видео-роликом?»
И тут приходит озарение: а почему бы и нет? Создаем краткую вводную инструкцию, снимаем часть нагрузки и делаем процесс более систематизированным. Звучит как план.
Итак, проблемы, с которыми мы столкнулись:
«Вечный понедельник»: каждую неделю одно и то же повторение о компании и продукте. Ответы на одни и те же вопросы.
Сложности с запоминанием: кто что знает, кто кому что рассказал.
Непрозрачность заявок при подключении новых людей: каждый раз как в первый.
Долгий процесс онбординга, особенно на сложных проектах.
Все страдают: лид, коллеги, новичок. Вопросы летят, как из пулемета.
Часть 4: Путеводитель мне запили!
Теперь давайте займемся созданием нашего собственного «Справочника по выживанию в джунглях проекта» или, если говорить официально, wiki-страницы под кодовым названием «Добавление разработчика».
Страница будет состоять из трех блоков:
Вступительный
Для руководителя
Для разработчика
Давайте разберем каждый из них.
Вступительный блок выглядит так:
Теперь детальнее.
Первое, что надо сделать, — правильно позиционировать эту страницу в глазах нашего нового коллеги. Здесь важно показать, что это не просто еще одна страница документации, а личный роадмап новичка, ключ к ответам на большинство его вопросов.
Второе — ограничить сроки.
Чтение не должно затягиваться вечно. Начните с оценки времени, которое, по вашему мнению, потребуется мидлу/джуну/сеньору для освоения материала, и установите этот срок.
Нет смысла специально уменьшать сроки и делать их слабо достижимыми. Наша цель — не загнать коллегу, а помочь ему комфортно внедриться в проект и команду. Нет смысла завышать время, так как по закону Паркинсона - Работа занимает все отведенное на нее время.
Третье - подача информации.
Подача информации – это искусство, и здесь важно найти золотую середину. Мы не ставим сроки как непреложный ультиматум, а предлагаем их как дружеское напоминание. Вместо «Ты должен за три дня» мы говорим: «В среднем, на его прохождение требуется» или даже «Обычно коллеги укладываются в три дня». Это не только делает срок кажущимся более выполнимым, но и добавляет элемент здорового соперничества: «Если они смогли, почему бы и мне не попробовать?»
Такой подход помогает сфокусировать внимание на роадмапе, а не на бесконечном изучении всей вики компании. «Есть срок, есть задача – действуем!»
Также подсвечиваем, что первая задача – это не просто пункт в списке, а ваша отправная точка. Особенно это важно для тех, кто предпочитает действие словам. Вы знаете этих ребят: вместо того, чтобы читать инструкции, они сразу же погружаются в работу, создают новые ветки в Git и берут задачи из Jira, исследуя все на ходу.
Для них мы особо подчеркиваем:
это первая задача
максимально самостоятельно
пройти полностью
Четвертое — границы!
В больших компаниях легко потеряться среди множества разделов вики и документации. Наша задача – установить четкие рамки, чтобы новички знали, на чем сосредоточиться. Мы хотим помочь новичку, а не перегрузить его информацией.
Укажите, какие разделы/спейсы/каталоги можно смотреть. Или, может быть, ограничить статьи для изучения коллегой тегом?
И последнее, но не менее важное — актуализация документации.
Новички – это не только ученики, но и учителя. Их свежий взгляд помогает выявить устаревшие, неправильные или недостающие моменты в документации. Поэтому мы приучаем их с первых дней не только читать, но и активно участвовать в процессе обновления и улучшения информации. Это не только помогает им понять систему, но и вносит свежий взгляд в нашу документацию.
Блок руководителя
Выход нового сотрудника в компанию — это как запуск ракеты. Множество систем должны сработать безупречно и вовремя. В идеальном мире добавление нового разработчика в команду происходит нажатием одной волшебной кнопки, которая запускает целую цепочку автоматизированных действий: создает аккаунты во всех необходимых системах, настраивает доступы, информирует команду... Как в космическом центре управления полетами!
Но этот космический центр вначале надо построить, что может быть непростой задачей. И пока мы его строим, часть работы выполняется в ручном режиме или через заявки в другие отделы.
В моем случае это выглядит примерно так:
Это далеко не полный список, но вы наверняка уже дополнили его особенностями своей компании или проекта.
Этот блок на странице роадмапа свернут, потому что основной читатель страницы — новый сотрудник, которому не нужно знать все закулисные тайны с первых минут. Однако он должен иметь возможность заглянуть туда и увидеть, сколько работы уже было проделано руководителем. Это как заглянуть за занавес перед большим спектаклем: важно знать, что все готово к вашему выходу на сцену.
Для меня как руководителя несложно время от времени раскрывать этот блок, чтобы убедиться, что все идет по плану. Это как заглядывать в книгу рецептов во время приготовления сложного блюда: всегда полезно свериться с инструкцией!
Блок разработчика выглядит так:
Давайте тоже рассмотрим детальнее.
Чек-лист как навигатор, который поможет не заблудиться в IT-джунглях. Каждый пункт — это шаг на пути к освоению проекта. Здесь нет ловушек, только четкие указания!
Каждый пункт чек-листа сформулирован как конкретная задача со ссылкой на ресурс, где можно получить необходимые сведения.
Разделение знаний на блоки помогает визуально упростить восприятие информации. Вместо того, чтобы смотреть на одну гигантскую колонку из сотни пунктов, вы видите структурированный план, разбитый на логические разделы. Это как разделение большой задачи на маленькие шаги — кажется гораздо более выполнимым и менее стрессовым.
Часть 5: Магия видео-инструкций
Чек листы у нас есть, но каждый пункт требует ответов, а, значит, нужна эффективная документация. И тут на сцену выходят видео-инструкции.
Видео-инструкции — это не просто удобство, а ключ к эффективному обучению. Многие не осознают его силу, пока не попробуют. А потом? Отказаться невозможно.
Не верите? Давайте разберемся!
Примеры в действии:
«Флоу задач в Jira»: вы включаете запись, открываете доску Jira и в течение 5–10 минут демонстрируете весь процесс жизни задачи. От правильного создания, через разработку и тестирование, к успешной приемке. Это не просто инструкция, а путешествие по вашему рабочему процессу.
«Структура проекта в репозитории»: Запускаете IDE, начинаете запись и ведете зрителя по лабиринтам вашего кода, объясняя, где что находится и как все работает.
Видео-инструкции: почему они работают?
Лучше один раз увидеть, чем 100 раз услышать
Видео передает контекст и нюансы, которые трудно описать словами, — многое мы упускаем в виду кажущейся простоты и понятности. Новичок видит реальные процессы и интерфейсы, что ускоряет его понимание.
Простой пример. Вы можете текстом написать: «Зайди на сервер Х и выполни команду Y». Казалось бы, понятно и просто.
Но на видео мы сможем показать и пользователя, под которым выполняется команда, и директорию, даже оболочку, от которой тоже многое может зависеть, и результат выполнения, который может отличаться от результата новичка.
Эффективность времени
Записать видео на 5–10 минут гораздо быстрее, чем писать тексты с такой же информационной емкостью.
Плюс, это навык, который развивается и улучшается со временем. Через какое-то время видео можно будет записывать почти без подготовки и с первого дубля.
Легкость восприятия
Видео легче воспринимается, чем аналогичный текст. Особенно если ваша речь четкая и информативная.
Ускоренный просмотр
В отличие от живых встреч, видео можно смотреть в ускоренном режиме, перематывать, пересматривать.
Дополнительные советы по видео
Создайте отдельную страницу с видео-инструкциями для удобства доступа. У меня она называется «Видео-инструкции для новичка».
Чтобы видео попадало в текстовый поиск, указывайте под роликом теги и краткое описание с ключевыми словами. Вуаля! Теперь его легко найти.
Искусство создания видео-материалов
Искусство разметки видео-материала
Представьте себя режиссером своего обучающего шоу. В основе видео — сценарий, каждый кадр должен быть продуман. Начните с простого: бумага и ручка. Запишите кратко основные моменты, которые хотите рассказать. Со временем вы научитесь строить такие сценарии в уме, словно профессиональный режиссер, который видит фильм еще до съемки.
Принцип «одна тема — одно видео»
Помните о золотом правиле: не перегружайте зрителя. Лучше создать серию коротких, но емких видео, чем одно длинное, где зритель потеряется. Каждое видео — это отдельная глава книги, полная информации, но легкая для восприятия.
Дикция и чистота речи
Избавьтесь от слов-паразитов, тренируйте четкость и уверенность. Записывайте себя, просматривайте материал сразу после записи. Обычно это помогает найти изъяны, — пересмотрите ролик, например, через 1-2 часа. Анализируйте и улучшайте. Это не только повысит качество ваших видео, но и сделает вас звездой любых презентаций и встреч.
Тренировка, тренировка и еще раз тренировка!
Без паники, это просто видео
Не бойтесь ошибок. Видео всегда можно отредактировать или перезаписать. Это ваша тренировочная площадка, где вы можете усовершенствовать навыки.
Технические тонкости создания видео: звук, изображение и формат
Помните, что звук в ваших видео — это не просто фон, а основа вашего сообщения. Если звук шипити в нем присутствует фоновый шум, то даже самое захватывающее содержание потеряет свою ценность. Ваши зрители должны слышать вас четко и без помех, как если бы вы говорили с ними лично. Инвестиции в хороший микрофон — инвестиции в качество вашего общения.
В мире, где экраны варьируются от 5K до Full HD, важно помнить о том, что не вся ваша аудитория будет смотреть видео в высоком разрешении. Снимая в 5K, вы рискуете создать контент, который будет трудно воспроизводить на менее мощных устройствах или из-за сжатия сильно потеряет в четкости. Снимайте в Full HD, чтобы обеспечить оптимальное качество и доступность вашего видео для всех зрителей, независимо от их оборудования.
В эпоху высокоскоростного интернета легко забыть о том, что не каждый может быстро загрузить большой файл. Особенно если таких файлов много. Сжатие видео — это не только сокращение времени загрузки, но и уважение, экономия времени вашей аудитории. Уменьшая размер файла, вы делаете свой контент доступнее и удобнее для просмотра, что, в свою очередь, увеличивает шансы на то, что ваше сообщение увидят и услышат.
Часть 6: А что же дальше?
Это был подход базового онбординга.
Каждый раз, когда на работу выходит новый разработчик, вы копируете эту страницу саму в себя и называете «Добавление разработчика — Иван Иванов».
И вот у вас есть раздел «Добавление разработчика», где внутри раздела — такие же страницы, только персонализированные, под каждого разработчика.
Этот подход решает множество задач:
Устранение рутины: теперь коллеги погружаются в работу самостоятельно, без необходимости вашего постоянного вмешательства.
Глубокое и широкое погружение: вы обеспечиваете коллегу всей необходимой информацией для эффективного старта работы.
Снижение нагрузки на команду: команда больше не тратит время на ответы на одни и те же вопросы.
Четкость для руководителя: вы всегда знаете, что уже сделано и что еще предстоит сделать для каждого нового сотрудника.
Понятность для сотрудника: каждый новичок точно знает, что ему нужно изучить.
Прозрачность процесса: весь процесс онбординга становится прозрачным и понятным для всех участников.
Но и это еще не все.
Следующий шаг — углубление и расширение этого процесса, чтобы сделать онбординг еще более эффективным и целенаправленным.
Часть 7: Улучшаемся. Продвижение и развитие в онбординге
После применения онбординга на более чем 30 новых сотрудниках, я выявил несколько ключевых моментов для улучшения:
Честное чтение
Некоторые разработчики могут лениться или считать, что они уже знают все, если видят знакомые термины вроде Symfony, Composer, Gin, Git. Однако это недооценка важности глубокого понимания конкретного материала в контексте вашего проекта.Онбординг на 3 дня
Хорошо, но работа продолжается гораздо дольше. Задача каждого руководителя — развивать своих сотрудников постоянно, чтобы они становились лучше.Забывание информации
Это естественный процесс, и его нужно учитывать.
А потому делаем доработки.
Разбиваем чек-лист на этапы
Пример:
первые Х дней в проекте - что нужно знать, чтобы приступать к задаче эффективно.
первые Х недель - что надо еще узнать о проекте, чтоб знания выросли в глубину.
первые Х месяцев - какие скилы (хард/софт) и технологические знания надо прокачать.
Таким образом, страница онбординга превращается в личный план развития сотрудника, который можно планировать на год вперед.
Если вы пойдете по этому пути, то еще немного рекомендаций:
сделайте явную и заметную отсечку испытательного срока. Чтобы сотрудник, заходя в проект, понимал, где та линия успешности, когда он прошел входной экзамен в вашу команду и стал ее полноценной частью;
сделайте разбивку на уровни, чтобы обучение и закрытие чекбоксов отражались на грейде/уровне/записи в трудовой/ачивке в профиле. Должно быть позитивное закрепление, что обучение — это не просто так, а повышение ценности сотрудника в глазах компании.
Экзамены.
Каждый этап должен сопровождаться экспресс-экзаменом. К примеру, личный созвон с сотрудником минут на 30, где в свободной форме вы общаетесь по пройденному этапу. Это мотивирует ваших коллег не хитрить и не пропускать важные моменты.
Периодичность
Внедрение новой системы онбординга в вашей компании — это не только шанс для новых сотрудников быстро влиться в коллектив, но и уникальная возможность для «перезагрузки» уже работающего персонала. Представьте, что это не просто обучение, а, скорее, переосмысление и обновление знаний, которые могли устареть или потерять актуальность.
Когда вы решите внедрить новую практику, начните с тех, кто уже давно с вами. Это не только позволит им освежить свои знания, но и даст вам ценную обратную связь о том, насколько эффективна новая система. Это как взгляд изнутри на то, что вы строите, и возможность улучшить его до того, как новички начнут свой путь.
Важно понимать, что компания — живой организм, который постоянно развивается и меняется. То, что казалось важным год или два назад, сегодня может потерять актуальность. Поэтому регулярное обновление знаний даже у опытных сотрудников — это не просто хорошая практика, а необходимость.
Подходите к этому процессу как к экспресс-режиму обучения. Большинство ваших старых сотрудников уже знакомы с основами, поэтому они могут быстро просмотреть материалы, освежить в памяти то, что забыли, и узнать новое. Это не только поможет им оставаться на одной волне с современными трендами и изменениями в компании, но и сделает их более гибкими и адаптивными к нововведениям.
Таким образом, ваша система онбординга становится не просто инструментом для новичков, но и мощным каналом постоянного обучения и развития для всей команды. Это создает культуру непрерывного обучения, где каждый сотрудник, независимо от его опыта и стажа в компании, постоянно растет и развивается вместе с вашим бизнесом.
Часть 8: Несколько ценных советов для эффективного онбординга
Создание безопасного канала общения
Представьте себя на месте нового разработчика. Вы изучили все материалы, посмотрели все видео, но у вас возникли вопросы. Кому и где вы можете их задать, не боясь показаться глупым? В нашем случае я создаю специальные чаты для каждой команды, там нет менеджеров. Это место, где каждый может свободно высказываться, даже если вопрос кажется простым или очевидным. Такой формат коммуникации укрепляет дух команды и поддерживает открытый диалог.
Командность или курирование
Здесь многое зависит от специфики вашего продукта и команды. В некоторых случаях эффективен подход с назначением куратора для новичка, который ведет его и помогает ему. В других — лучше работает командный подход, где все помогают друг другу и обеспечивает поддержку. Выбор подхода должен базироваться на культуре вашей команды и специфике работы.
Информирование команды о новых сотрудниках
Перед тем, как новый сотрудник присоединится к команде, важно проинформировать всех о его приходе. Это помогает избежать недопонимания и стресса, а также способствует лучшей интеграции новичка в коллектив. Каждый должен знать, кто присоединяется к команде, каковы его роль и область ответственности.
Автоматизация процессов
Автоматизация рутинных задач — ключ к эффективности. В нашем случае мы разработали внутреннюю платформу, которая позволяет частично автоматизировать процесс добавления новых сотрудников. С помощью небольшой формы мы можем завести разработчика в наше пространство, указать его специфику (бэкенд/фронтенд), вес его голоса на код-ревью. Далее автоматика уже поставит нужные задачи в правильные отделы и даже оповестит команду о его скором присоединении. Это несколько упрощает процесс и позволяет сосредоточиться на более важных аспектах работы.
А как внедрение происходит у вас?