Привет, Хабр!
Меня зовут Екатерина, я тимлид команды Биллинга сервиса МойСклад.
Примерно два с половиной года назад команда разработки МоегоСклада состояла из 20 человек. За это время мы выросли в три раза, только с начала 2019 года у нас появилось три новых команды. На фоне быстрого роста нам пришлось менять модель обучения «тимлид всё расскажет и покажет лично» на более масштабируемую.
Если вы тоже столкнулись с такой проблемой и хотите узнать, как ее решили мы, — добро пожаловать под кат!
Как было раньше
Когда я пришла в МойСклад два с половиной года назад, мое обучение было теплым и ламповым, но не особо продуктивным. Тимлид подкатывал на стуле к моему столу и рассказывал: как настроить рабочее окружение, какие компоненты есть в проекте, как они взаимодействуют, как это работает на проде, тестируется и разрабатывается.
Когда новый разработчик в команде появляется раз в полгода, такой подход работает хорошо — новый сотрудник много коммуницирует с тимлидом и старшими разработчиками и быстро знакомится с командой. Но на ввод в работу новичка уходило много времени тимлида и старших разработчиков, хотя на деле каждому пересказывали одно и то же.
С какого-то момента новички стали приходить не по одному в полгода, а по два-три человека в месяц. Времени на онбординг стало уходить больше, и в итоге мы написали первую статью для новичков — рассказали, как настраивать рабочее окружение. До этой статьи на разворачивание dev-окружения и знакомство с проектом требовалось до трех дней, сейчас хватает двух часов.
0 день в компании
Еще перед выходом нового сотрудника на работу мы решаем несколько важных вопросов:
Команда. Как правило, стараемся еще до собеседования решить, в какой команде будет работать человек. Если одному из тимлидов понравился кандидат, проводить собеседование и рассматривать человека с прицелом на свою команду будет он. Конечно, мы учитываем потребности команд, способности, пожелания нового сотрудника — кому-то больше интересен бэкенд, кто-то обожает UI.
Рабочее место. Ноутбук и всё необходимое для работы новый сотрудник должен увидеть на своем столе сразу. Он не должен шататься по админам и выбивать технику через тикеты и бумажки. В МоемСкладе в день выхода на работу для новичка уже подготовлено рабочее место с ноутбуком, монитором и мышкой, фирменным блокнотом с ручкой и классной кружкой. Так сотрудник может сразу приступить к настройке рабочего окружения.
Доступы к корпоративным ресурсам. Сразу же обеспечиваем доступами к почте, Слаку, Гитлабу, Конфлюенсу и прочим.
Переходите на сторону МоегоСклада — у нас есть классные кружки и вкусняшки
1 день в компании
Цель первого рабочего дня — ознакомиться с оргструктурой компании и получить ответы на организационные вопросы. Большая часть необходимой информации у нас хранится в Конфлюенсе. К концу дня новый сотрудник должен иметь настроенное рабочее окружение и начать знакомиться со структурой проекта.
На практике мы делаем так. В начале дня эйчар присылает новому сотруднику статью с полезной информацией: как корректно заполнить профиль в Слаке; к кому бежать, если у тебя сломался монитор, кончился блокнот, ты потерялся, запутался и не знаешь, что делать. Спойлер: к тимлиду и тому же эйчару.
Дополнительно выдаем ссылки на статьи с общими организационными вещами. С ними рекомендуем ознакомиться в первый день и обращаться к ним по мере работе в компании.
Вот как выглядит структура информации, с которой мы знакомим нового разработчика в первый день. Этой структурой можно воспользоваться, если вы захотите создать подобную документацию для вашей компании или команды.
Новому сотруднику:
- Основные инструменты для работы. Даем ссылки на корпоративную почту, Слак, календари, Джиру.
- Правила заполнения профиля в Слаке.
- Правила заполнения подписи в почте (по желанию).
- Оргструктура компании и план рассадки офиса. Чтобы новичок всегда был в курсе, к кому, по каким вопросам и в какую сторону бежать.
Общие:
- Зарплата. График начисления, правила деления на зарплату и аванс.
- Больничные. Как оплачиваются и как поступать с больничными листами.
- Отпуск. Все необходимые инструкции и образец заявления.
- Компенсация обучения. Как, сколько и к кому идти, если вдруг захотелось на конференцию или курсы.
- ДМС. Когда, как, что доступно, кого спросить.
- Прочие плюшки. Тут про график работы, возможность работать удаленно, компенсацию обедов и вообще про всё, что вы еще захотите рассказать новому сотруднику.
Все оргстатьи максимально сжаты и структурированы. В них мы собрали только самое необходимое, что требуется для адекватной жизни в офисе. На более-менее внимательное прочтение уходит около часа.
К этому моменту новичок уже ориентируется в офисе и понимает, к кому идти с той или иной проблемой. Если закончились печеньки, он не будет искать их у админов.
Затем тимлид выдает новому сотруднику инструкции:
Общую для всех команд по настройке рабочего места. В ней написано, как выгрузить проект, скачать необходимые компоненты и кто может помочь запустить проект локально на ноутбуке и проверить его работоспособность. Эти шаги сопровождаются ссылками на репозитории.
Отдельную для конкретной команды. В нем содержатся специфичные требованиям по работе над тикетами, проведению ревью и передаче тикета на тестирование. Например, у нас в Джире стоят кастомные статусы и типы тикетов. Они могут смутить даже человека, который ранее работал с Джирой. Поэтому мы собрали в одном месте требования, которым должны отвечать все созданные в багтрекере тикеты.
Эти действия у меня оформлены в виде небольшого чек-листа:
В ссылках приведены статьи с описанием специфичных для нашей компании или конкретной команды вещей
На ознакомление с техническими статьями и запуск приложения локально уходит в среднем три-четыре часа. В итоге новичок имеет полностью настроенную dev-среду и готов приступить к разработке первого тикета. Но перед этим в конце дня я организую небольшой митинг с новым сотрудником: проговариваю голосом основные направления работы команды, отвечаю на вопросы по поводу изученного в течении дня материала.
1 неделя в компании
На первой неделе в компании новый разработчик знакомится с основной функциональностью приложения и делает первые тикеты.
Для знакомства с функциональностью проекта у меня есть отдельный небольшой чек-лист:
С ним разработчик начинает понимать основные моменты работы приложения, расположение в коде главных точек входа, может ориентироваться в коде самостоятельно.
Затем новичку выдается в разработку его первый тикет. Тикеты для новых разработчиков я отбираю заранее и формирую из них в Конфлюенсе небольшой список. Это важно, и вот почему.
В каждом тикете я проверяю, что все описания были понятными. Не должно быть специфичных для продукта определений; если они есть, то должны сопровождаться ссылками на документацию. Сформированный список тикетов позволяет новому разработчику брать себе задачи самостоятельно, не спрашивая коллег — все задачи в этом списке готовы к работе. И главное — так сразу виден план развития по задачам на ближайший месяц.
В процессе работы над тикетом новый разработчик может сверяться с ранее полученными статьями, передавать тикет на ревью и на тестирование. С таким подходом уже в первую неделю готовая задача попадает на прод, а разработчик получает фидбэк от сделанного им решения.
1 месяц в компании и далее
Если вам показалось, что наша система с чек-листами и тикетами выкидывает человека в одиночное плавание, это не так. С первого дня тимлид приглядывает за новичком, подсказывает по компонентами продукта, делится статьями из базы знаний, которые помогут решить задачу.
Если разработчик тянет, в первый месяц мы уже можем доверить крупную архитектурную задачу.
Во время испытательного срока мы проводим несколько очных встреч: в конце первой недели работы, в конце первого месяца и в конце испытательного. На них мы обмениваемся фидбэком, делимся планами по задачам и корректируем то, что могло пойти не так. А частенько просто говорим: «Отлично, работаем дальше!»
Результаты
С помощью документации по продукту и компании, чек-листов для онбординга и инструкций по настройке рабочего окружения мы сильно сократили период времени, который проходит до разработки первого тикета. Теперь выпуск первого небольшого тикета происходит уже в первые дни работы, а до внедрения онбординга на это уходило где-то две недели.
Внедрение промежуточных встреч во время испытательного срока тоже очень помогло. Теперь мы корректируем возникающие проблемы сразу, а не дожидаемся окончания испытательного срока. Нам стало легче подводить промежуточные и окончательные итоги, а новичкам — вливаться в работу.
Тимлиды стали тратить меньше времени на устный рассказ о базовых вещах — мы зафиксировали их в статьях. Теперь нужно только приглядывать, чтобы новички применяли информацию правильно. Еще нам удалось масштабировать найм — команда разработки увеличилась за два с половиной года в три раза.
Комментарии (10)
lxsmkv
11.06.2019 04:11Мысль интересная, сформулировать это в виде конкретных «квестов», так чтобы каждое последующее задание было сложнее, но охватывало предыдущий опыт. Как в играх. А то у нас «простыня» на 4 DIN A4 листа с технологиями, интерфейсами, инструментами, и пр. Не хотел бы я оказаться новичком у нас на проекте :).
vav180480
Это все понятно, а перевод килограммов в литры «на лету» уже сделали?
drmwks Автор
Добрый день! Комментарий совсем не по теме статьи — предложения мы собираем в нашей группе ВКонтакте.
Подобной доработки в планах нет.
vav180480
Добрый. Комментарий очень даже по теме, понятно чем живет и над чем работает компания, сколько лет прошло, команду втрое расширили, внедрили кучу всяких методик и технологий, а пользователю (например бензоколонке) нужен перевод «на лету» из килограммов (приходуют в тоннах) в литры (в них продают), а этого даже в планах нет. Ребят, вы молодцы (красны девицы) конечно.
mstrochkov
Здравствуйте.
Перевод веса в объем возможен только если известна плотность вещества.
В случае, когда вы изначально знаете значение плотности вещества (например, от производителя), то вы можете рассчитать для себя, сколько в тонне литров.
Например, для плотности 760 кг/куб. м (бензин АИ-92 при 20°C), в тонне будет примерно 1315л.
В МоемСкладе, в карточке товара есть возможность указать различную упаковку товара.
Например, если у вас базовая единица — литры, вы можете сделать упаковку 1т = 1315л.
Тогда в приемке вы сможете указать, что приняли 1 тонну, а продать в розницу уже в литрах.
Однако, так как у всех веществ плотность зависит от большого количества факторов (в первую очередь — температуры), то создать какой-то функционал, который будет всегда «на лету» верно пересчитывать вес в объем невозможно.
vav180480
Ага, таким вот костылем, еще раз КОСТЫЛЕМ ЧЕРЕЗ УПАКОВКУ, сделано и в 1С, как гриться:
— Дай списать.
— Хорошо, только не переписывай точь в точь чтобы не cпалили.
Ну и насчет плотности от температуры, на бензоколонке я залил 10л, мне продали именно 10л, я заплатил именно за 10л, а не 7,6кг, у меня в чеке стоит 10л, вопрос, как спишется бензин у бензоколонки? Аппаратура бензоколонки считает сколько килограммов залила? 7,5кг или 7,7кг? Или все таки по нормативу 0.76кг на литр шпарит? Вместо того чтобы предоставить пользователю функционал, например он в зависимости от температуры может шпарить литры 40 по цельсию и литры -40 по цельсию и в килограммы пересчитает правильно, мы сделаем как в 1С через упаковку, а вместо трудов неправедных мы лучше расширим команду втрое, скрам внедрим и подумаем как правильно рассесться в офисе когда пару новичков взяли, работа должна быть в кайф, ребят у нас стало больше ресурсов, давайте наймем больше программистов… найдем чем занять, примерно то же самое я слышал про бюрократию. Ну а тонны в литры… а там через упаковку можно.
Alroniks
Кроме предвзятой критики у вас ничего по существу вопроса. Так как вы предлагаете гонять на лету литры в килограмы и наоборот? Или вы прям хотите, чтобы на балансе было в кило, а списывалось в литрах? Так пока заливать будут, пару кило успеет испариться в атмосферу, их на потери списывать, или как?
vav180480
Вы думаете что если будете приходовать в литрах и расходовать в литрах у вас бензин испаряться перестанет, к чему этот вопрос? КОНЕЧНО СПИСЫВАЮТ В ПОТЕРИ это же очевидно любому кто знает что и для кого он пишет. Не важно в чем там будет на балансе, важно что вы приходуете в тоннах а продаете в литрах. Вы пойдите и узнайте как это делают на БЕНЗОКОЛОНКАХ без ваших костыльных систем «на упаковках» (кстати если я попрошу заправить на 500 рублей мне заправят 13,71 литровых упаковок, у вас там можно дробными упаковками торговать?), в эксельках, как приходуют, как продают, как списывают, зачем вам меня — анонима по факту, слушать? Не интересно, да? Нафик те бензоколонки, да? Мы лучше на микросервисы архитектуру перепишем, покроем все тестами, внедрим непрерывную интеграцию, оно же проще так, потерянные ключи под фонарем искать, обязательно обо все напишем на хабре, делом в общем займемся, а не бензоколонками… фу.
Alroniks
А я тут каким боком к компании выше, или к 1С? Претензии, пожалуйста, им высказываейте, я с этими инструментами вовсе не работаю, но задаю вам конкретный вопрос, как это следует считать? С ваших слов всё просто, так опишите идеальный подход. Мне в самом деле любопытно.
vav180480
Как ваш конкретный вопрос про испарение бензина относится к вопросу учета в разных единицах измерения? Бензин испаряется вне зависимости от способов учета. В огороде бузина, а в Киеве дядька. И да я хочу чтобы на балансе было в тоннах, а продажа была в литрах, я так многого хочу? Что могу ответить, в каких хотите единицах списывать, в таких и списывайте, хоть в молях, главное чтобы баланс сошелся. Что вы еще от меня хотите? чтобы я вам рассказал как из одних единиц пересчитывать в другие? Вы знаете, я не помню, надо в учебник физики за 5 класс заглянуть, я не Senior Software Developer.