Привет, Хабр!
Меня зовут Екатерина, я тимлид команды Биллинга сервиса МойСклад.

Примерно два с половиной года назад команда разработки МоегоСклада состояла из 20 человек. За это время мы выросли в три раза, только с начала 2019 года у нас появилось три новых команды. На фоне быстрого роста нам пришлось менять модель обучения «тимлид всё расскажет и покажет лично» на более масштабируемую.

Если вы тоже столкнулись с такой проблемой и хотите узнать, как ее решили мы, — добро пожаловать под кат!

Как было раньше

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

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

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

0 день в компании

Еще перед выходом нового сотрудника на работу мы решаем несколько важных вопросов:

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

Рабочее место. Ноутбук и всё необходимое для работы новый сотрудник должен увидеть на своем столе сразу. Он не должен шататься по админам и выбивать технику через тикеты и бумажки. В МоемСкладе в день выхода на работу для новичка уже подготовлено рабочее место с ноутбуком, монитором и мышкой, фирменным блокнотом с ручкой и классной кружкой. Так сотрудник может сразу приступить к настройке рабочего окружения.

Доступы к корпоративным ресурсам. Сразу же обеспечиваем доступами к почте, Слаку, Гитлабу, Конфлюенсу и прочим.

Переходите на сторону МоегоСклада — у нас есть классные кружки и вкусняшки

1 день в компании

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

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

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

Новому сотруднику:

• Основные инструменты для работы. Даем ссылки на корпоративную почту, Слак, календари, Джиру.
• Правила заполнения профиля в Слаке.
• Правила заполнения подписи в почте (по желанию).
• Оргструктура компании и план рассадки офиса. Чтобы новичок всегда был в курсе, к кому, по каким вопросам и в какую сторону бежать.

Общие:

• Зарплата. График начисления, правила деления на зарплату и аванс.
• Больничные. Как оплачиваются и как поступать с больничными листами.
• Отпуск. Все необходимые инструкции и образец заявления.
• Компенсация обучения. Как, сколько и к кому идти, если вдруг захотелось на конференцию или курсы.
• ДМС. Когда, как, что доступно, кого спросить.
• Прочие плюшки. Тут про график работы, возможность работать удаленно, компенсацию обедов и вообще про всё, что вы еще захотите рассказать новому сотруднику.

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

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

Затем тимлид выдает новому сотруднику инструкции:

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

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

Эти действия у меня оформлены в виде небольшого чек-листа:

В ссылках приведены статьи с описанием специфичных для нашей компании или конкретной команды вещей

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

1 неделя в компании

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

Для знакомства с функциональностью проекта у меня есть отдельный небольшой чек-лист:

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

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

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

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

1 месяц в компании и далее

Если вам показалось, что наша система с чек-листами и тикетами выкидывает человека в одиночное плавание, это не так. С первого дня тимлид приглядывает за новичком, подсказывает по компонентами продукта, делится статьями из базы знаний, которые помогут решить задачу.

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

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

Результаты

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

Внедрение промежуточных встреч во время испытательного срока тоже очень помогло. Теперь мы корректируем возникающие проблемы сразу, а не дожидаемся окончания испытательного срока. Нам стало легче подводить промежуточные и окончательные итоги, а новичкам — вливаться в работу.

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