Привет, Хабр!
Меня зовут Екатерина, я тимлид команды Биллинга сервиса МойСклад.
Примерно два с половиной года назад команда разработки МоегоСклада состояла из 20 человек. За это время мы выросли в три раза, только с начала 2019 года у нас появилось три новых команды. На фоне быстрого роста нам пришлось менять модель обучения «тимлид всё расскажет и покажет лично» на более масштабируемую.
Если вы тоже столкнулись с такой проблемой и хотите узнать, как ее решили мы, — добро пожаловать под кат!
Как было раньше
Когда я пришла в МойСклад два с половиной года назад, мое обучение было теплым и ламповым, но не особо продуктивным. Тимлид подкатывал на стуле к моему столу и рассказывал: как настроить рабочее окружение, какие компоненты есть в проекте, как они взаимодействуют, как это работает на проде, тестируется и разрабатывается.
Когда новый разработчик в команде появляется раз в полгода, такой подход работает хорошо — новый сотрудник много коммуницирует с тимлидом и старшими разработчиками и быстро знакомится с командой. Но на ввод в работу новичка уходило много времени тимлида и старших разработчиков, хотя на деле каждому пересказывали одно и то же.
С какого-то момента новички стали приходить не по одному в полгода, а по два-три человека в месяц. Времени на онбординг стало уходить больше, и в итоге мы написали первую статью для новичков — рассказали, как настраивать рабочее окружение. До этой статьи на разворачивание dev-окружения и знакомство с проектом требовалось до трех дней, сейчас хватает двух часов.
0 день в компании
Еще перед выходом нового сотрудника на работу мы решаем несколько важных вопросов:
Команда. Как правило, стараемся еще до собеседования решить, в какой команде будет работать человек. Если одному из тимлидов понравился кандидат, проводить собеседование и рассматривать человека с прицелом на свою команду будет он. Конечно, мы учитываем потребности команд, способности, пожелания нового сотрудника — кому-то больше интересен бэкенд, кто-то обожает UI.
Рабочее место. Ноутбук и всё необходимое для работы новый сотрудник должен увидеть на своем столе сразу. Он не должен шататься по админам и выбивать технику через тикеты и бумажки. В МоемСкладе в день выхода на работу для новичка уже подготовлено рабочее место с ноутбуком, монитором и мышкой, фирменным блокнотом с ручкой и классной кружкой. Так сотрудник может сразу приступить к настройке рабочего окружения.
Доступы к корпоративным ресурсам. Сразу же обеспечиваем доступами к почте, Слаку, Гитлабу, Конфлюенсу и прочим.
Переходите на сторону МоегоСклада — у нас есть классные кружки и вкусняшки
1 день в компании
Цель первого рабочего дня — ознакомиться с оргструктурой компании и получить ответы на организационные вопросы. Большая часть необходимой информации у нас хранится в Конфлюенсе. К концу дня новый сотрудник должен иметь настроенное рабочее окружение и начать знакомиться со структурой проекта.
На практике мы делаем так. В начале дня эйчар присылает новому сотруднику статью с полезной информацией: как корректно заполнить профиль в Слаке; к кому бежать, если у тебя сломался монитор, кончился блокнот, ты потерялся, запутался и не знаешь, что делать. Спойлер: к тимлиду и тому же эйчару.
Дополнительно выдаем ссылки на статьи с общими организационными вещами. С ними рекомендуем ознакомиться в первый день и обращаться к ним по мере работе в компании.
Вот как выглядит структура информации, с которой мы знакомим нового разработчика в первый день. Этой структурой можно воспользоваться, если вы захотите создать подобную документацию для вашей компании или команды.
Новому сотруднику:
- Основные инструменты для работы. Даем ссылки на корпоративную почту, Слак, календари, Джиру.
- Правила заполнения профиля в Слаке.
- Правила заполнения подписи в почте (по желанию).
- Оргструктура компании и план рассадки офиса. Чтобы новичок всегда был в курсе, к кому, по каким вопросам и в какую сторону бежать.
Общие:
- Зарплата. График начисления, правила деления на зарплату и аванс.
- Больничные. Как оплачиваются и как поступать с больничными листами.
- Отпуск. Все необходимые инструкции и образец заявления.
- Компенсация обучения. Как, сколько и к кому идти, если вдруг захотелось на конференцию или курсы.
- ДМС. Когда, как, что доступно, кого спросить.
- Прочие плюшки. Тут про график работы, возможность работать удаленно, компенсацию обедов и вообще про всё, что вы еще захотите рассказать новому сотруднику.
Все оргстатьи максимально сжаты и структурированы. В них мы собрали только самое необходимое, что требуется для адекватной жизни в офисе. На более-менее внимательное прочтение уходит около часа.
К этому моменту новичок уже ориентируется в офисе и понимает, к кому идти с той или иной проблемой. Если закончились печеньки, он не будет искать их у админов.
Затем тимлид выдает новому сотруднику инструкции:
Общую для всех команд по настройке рабочего места. В ней написано, как выгрузить проект, скачать необходимые компоненты и кто может помочь запустить проект локально на ноутбуке и проверить его работоспособность. Эти шаги сопровождаются ссылками на репозитории.
Отдельную для конкретной команды. В нем содержатся специфичные требованиям по работе над тикетами, проведению ревью и передаче тикета на тестирование. Например, у нас в Джире стоят кастомные статусы и типы тикетов. Они могут смутить даже человека, который ранее работал с Джирой. Поэтому мы собрали в одном месте требования, которым должны отвечать все созданные в багтрекере тикеты.
Эти действия у меня оформлены в виде небольшого чек-листа:
В ссылках приведены статьи с описанием специфичных для нашей компании или конкретной команды вещей
На ознакомление с техническими статьями и запуск приложения локально уходит в среднем три-четыре часа. В итоге новичок имеет полностью настроенную dev-среду и готов приступить к разработке первого тикета. Но перед этим в конце дня я организую небольшой митинг с новым сотрудником: проговариваю голосом основные направления работы команды, отвечаю на вопросы по поводу изученного в течении дня материала.
1 неделя в компании
На первой неделе в компании новый разработчик знакомится с основной функциональностью приложения и делает первые тикеты.
Для знакомства с функциональностью проекта у меня есть отдельный небольшой чек-лист:
С ним разработчик начинает понимать основные моменты работы приложения, расположение в коде главных точек входа, может ориентироваться в коде самостоятельно.
Затем новичку выдается в разработку его первый тикет. Тикеты для новых разработчиков я отбираю заранее и формирую из них в Конфлюенсе небольшой список. Это важно, и вот почему.
В каждом тикете я проверяю, что все описания были понятными. Не должно быть специфичных для продукта определений; если они есть, то должны сопровождаться ссылками на документацию. Сформированный список тикетов позволяет новому разработчику брать себе задачи самостоятельно, не спрашивая коллег — все задачи в этом списке готовы к работе. И главное — так сразу виден план развития по задачам на ближайший месяц.
В процессе работы над тикетом новый разработчик может сверяться с ранее полученными статьями, передавать тикет на ревью и на тестирование. С таким подходом уже в первую неделю готовая задача попадает на прод, а разработчик получает фидбэк от сделанного им решения.
1 месяц в компании и далее
Если вам показалось, что наша система с чек-листами и тикетами выкидывает человека в одиночное плавание, это не так. С первого дня тимлид приглядывает за новичком, подсказывает по компонентами продукта, делится статьями из базы знаний, которые помогут решить задачу.
Если разработчик тянет, в первый месяц мы уже можем доверить крупную архитектурную задачу.
Во время испытательного срока мы проводим несколько очных встреч: в конце первой недели работы, в конце первого месяца и в конце испытательного. На них мы обмениваемся фидбэком, делимся планами по задачам и корректируем то, что могло пойти не так. А частенько просто говорим: «Отлично, работаем дальше!»
Результаты
С помощью документации по продукту и компании, чек-листов для онбординга и инструкций по настройке рабочего окружения мы сильно сократили период времени, который проходит до разработки первого тикета. Теперь выпуск первого небольшого тикета происходит уже в первые дни работы, а до внедрения онбординга на это уходило где-то две недели.
Внедрение промежуточных встреч во время испытательного срока тоже очень помогло. Теперь мы корректируем возникающие проблемы сразу, а не дожидаемся окончания испытательного срока. Нам стало легче подводить промежуточные и окончательные итоги, а новичкам — вливаться в работу.
Тимлиды стали тратить меньше времени на устный рассказ о базовых вещах — мы зафиксировали их в статьях. Теперь нужно только приглядывать, чтобы новички применяли информацию правильно. Еще нам удалось масштабировать найм — команда разработки увеличилась за два с половиной года в три раза.
