Предыдущие статьи серии:
→ Фантастические таланты: Эпизод 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: Несколько ценных советов для эффективного онбординга
Создание безопасного канала общения
Представьте себя на месте нового разработчика. Вы изучили все материалы, посмотрели все видео, но у вас возникли вопросы. Кому и где вы можете их задать, не боясь показаться глупым? В нашем случае я создаю специальные чаты для каждой команды, там нет менеджеров. Это место, где каждый может свободно высказываться, даже если вопрос кажется простым или очевидным. Такой формат коммуникации укрепляет дух команды и поддерживает открытый диалог.
Командность или курирование
Здесь многое зависит от специфики вашего продукта и команды. В некоторых случаях эффективен подход с назначением куратора для новичка, который ведет его и помогает ему. В других — лучше работает командный подход, где все помогают друг другу и обеспечивает поддержку. Выбор подхода должен базироваться на культуре вашей команды и специфике работы.
Информирование команды о новых сотрудниках
Перед тем, как новый сотрудник присоединится к команде, важно проинформировать всех о его приходе. Это помогает избежать недопонимания и стресса, а также способствует лучшей интеграции новичка в коллектив. Каждый должен знать, кто присоединяется к команде, каковы его роль и область ответственности.
Автоматизация процессов
Автоматизация рутинных задач — ключ к эффективности. В нашем случае мы разработали внутреннюю платформу, которая позволяет частично автоматизировать процесс добавления новых сотрудников. С помощью небольшой формы мы можем завести разработчика в наше пространство, указать его специфику (бэкенд/фронтенд), вес его голоса на код-ревью. Далее автоматика уже поставит нужные задачи в правильные отделы и даже оповестит команду о его скором присоединении. Это несколько упрощает процесс и позволяет сосредоточиться на более важных аспектах работы.
А как внедрение происходит у вас?
