Привет, друзья! На связи снова Кирилл Пронин из PIX Robotics, и у меня для вас новая статья-сенсация!
Мы сейчас открыли новый набор стажеров нашу команду разработки RPA, и коллеги попросили рассказать, как проходила стажировка по C# в прошлом году. А я что — я только за, потому что: а) благодаря прошлой стажировке мы заполучили двух талантливых джунов; б) для меня стажировка стала первым опытом в роли TeamLead’a; в) это было весёлое и необычное путешествие с неожиданными результатами (саму крутую цифру я уже вынес в заголовок, об остальных — ниже).Для нашей команды это был первый опыт запуска стажировки, так что, как бы ни готовились, мы все равно не учли некоторые нюансы. Назвать их громко ОШИБКАМИ пальцы не поднимаются, а вот неожиданностями и нюансами вполне. А так как для меня это все стало еще и первым опытом «тимлидства», то поделиться всем этим хочется вдвойне. Так что в этой статье расскажу, как организовать продуктивную стажировку, как отбирать лучших из лучших, какие ошибки нам удалось избежать и, конечно, о ключевых особенностях работы.
Немножко вводных
Начнем с простого. К стажировке мы в компании PIX Robotics подходили долго и скрупулезно, ведь всего лишь каких-то 3 года назад нас было 24 человека, а сейчас уже 200. Еще в начале 2023 года мы обсуждали о возможностях стажировки, как это круто — нанять веселого, горящего глазами человека, всему научить за 3 месяца и вывести на рынок нового разработчика. Скажем так, открыть свою джедайскую школу разработчиков мечтает каждый IT-шник, но оценив все риски, задачи клиентов, сжатые сроки, возможности оплаты работы, малое количество ответственных и способных выделять под стажеров время, мы сказали «Стажировка класс, но не в этом году».
И вот спустя год, весной 2024 мы поняли, что пора рискнуть!
Что может получить стажер от этой штучки? Минимальный опыт работы, хард и софт скиллы, опыт коммерческой разработки, познание профессии и как вишенка на торте, трудоустройство в крутую компанию.
Что получаем мы? Таланты с большим потенциалом роста до классных сотрудников и плюс в карму PIX Robotics.
Провели парочку мозговых штурмов и постановили, что стажировка по C# в PIX это:
НИКАКИХ ЛЕКЦИЙ! Студенты пришли не на очередные занятия вуза, они пришли «делать».
ТОЛЬКО РЕАЛЬНЫЕ ЗАДАЧИ. Да, можно построить предварительные теоретические задачки, которые потом можно удалить и выкинуть, но лучше начать делать реальные кейсы и как можно быстрее. Да и никакие теоретические задачи не сравнятся с реальностью.
УСИЛЕННОЕ CODE REVIEW. Количество багов и нарушений может быть максимально большим, но главное подготовить команду к этому и при этом научить стажеров «правильно писать».
Как и кого мы отбирали?
Чтобы найти талантливых ребят, нужно знать, где их искать, и как отбирать. С первым вопросов особо не возникло, так как мы сотрудничаем со многими вузами. А вот отбор кандидатов — это один из сложнейших этапов, вот как можно просто взять и распознать хорошего спеца? Особенно если это студент, который еще нигде не работал и не может похвастаться никаким опытом. Так что отбор поделили на три этапа: анкета, тестовое задание и интервью-знакомство.
Нюанс 1. «Ваши ожидания — ваши проблемы»
Да, мы обнаружили «нюанс» уже на первом этапе анкетирования. Мы добавили графу «инфо о себе», где ожидали увидеть, что кандидаты будут писать про свои проекты, хобби и ценности в свободной форме. И что мы увидели? Да практически ничего. Лишь малая часть кандидатов указала хотя бы ссылку на github, но, что нам там смотреть и понимать, никакой информации. Во время собеседования с кандидатами, мы спрашивали - а почему нет никакой информации в заявке? Ведь мы даже привязаться к кандидату не можем, т.к. не знаем ни-че-го. А оказалось, что «Инфо о себе» многим кажется перегруженным абзацем, либо не все понимают, что конкретно от них хотят. Например, «я сходил сегодня в пятерочку и купил 3 кг груш» — это информация, и она о тебе.
В общем, запуская сейчас новый отбор на стажировку, мы учли эту недоработку и добавили конкретные разделы в анкету:
Как ты пришел в IT?
Что тебе нравится в IT?
В какой проект/фреймворк/язык ты бы хотел развиваться?
Есть ли у тебя пет-проекты? А может есть и реализованные? Или может частично что-то реализовал, работая в команде?
Какие у тебя хобби? И чем ты любишь заниматься в свободное время?
Благодаря такой разбивке, мы получим тот самый минимум информации, чтобы начать понимать, кто перед нами.
А вот с техническим заданием, состоящем из трех увлекательных задач, мы не прогадали. Каждая из них отражала одну из областей нашей работы. Первое задание — на понимание нашего продукта. Все-таки мы потом работать со студией разработки программных роботов PIX Studio, и умение находить информацию в нашей базе знаний и быстро адаптироваться к новым условиям — важный навык. Второе — на знание разработки на C# (стажировка этому и посвящена). И третье задание было посвящено работе с внешними API, объединяя первое и второе. Тут мы прям молодцы, потому что такой подход помог нам защититься от шаблонных ответов с помощью GPT и готовых решений, найденных в интернете.
Что ж, после всех этапов мы получили 6-рых кандидатов на стажеров-разработчиков, 6 новых последователей ПИКСа. Цифра для нас оказалась идеальной, чтобы, с одной стороны, комфортно управлять процессом, а с другой, чтобы гарантированно получить новых сотрудников. Об этом еще расскажу в конце.
Как выстроили работу?
Длительность стажировки была 3 месяца, по 4 часа в день. Не так уж и много, чтобы погрузиться в продукт и изучить все досконально, так что мы вместе с тимлидом команды заранее подготовили гайд с огромным количеством заготовок, документов, а еще мы расписали первые задачи, которые будут попадаться стажерам. Что туда вошло:
Инструкция по настройке проекта (куда подключаться, учетные данные, что скачать);
Соглашение по написанию кода;
Описание процесса разработки;
Памятка по гиту;
Стандарт оформления кода с примерами.
И расписали процесс стажировки с обязательными встречами, все как у «взрослых» разработчиков: дейли (ежедневные встречи), ретроспектива (встречи раз в 2-3 недели, чтобы понять все плюсы и минусы взаимодействия, заданий и что можно сделать лучше) и тет-а-теты (индивидуальные встречи с каждым 2 раза за стажировку).
На самые первые недели мы еще поставили встречи типа «Введение в технологии», где мы рассказывали о своих спецификах разработки, фреймворках и правилах. Получается, я вас (и себя) немного обманул, когда говорил, что мы не будем делать НИКАКИХ ЛЕКЦИЙ. Они были, мы рассказывали про наш продукт и фреймы, но гораздо интереснее, чем занудные лекции.
Так мы: сэкономили время и свое, и стажеров, лишив их прокрастинации и страха неизвестного. Ну хотя бы помогли снизить градус😊 Повысили продуктивность: организованные встречи и четкие процессы позволяют команде быстрее двигаться к общей цели. И создали культуру открытости и сотрудничества: регулярные обсуждения и индивидуальные встречи помогают каждому чувствовать свою ценность и вовлеченность в процесс.
Необычные задания
И вот мы на этапе реальных задач. Мы начали с автономных задач, требующих базового понимания продукта PIX Studio и его методов работы. Это была серьезная разработка, на улучшение навыка «рефакторинга». У нас в закромах был код, который мы давным-давно переписали и улучшили, но специально, в виде первого задания, выдали старую версию и сказали «А можете сделать это лучше? Применять можете все свои навыки и желания, а если еще создадите Unit-тесты – то вообще будете золотцем». Итого, на следующий день мы получили множество версий улучшений, большинство из которых отлично вписывались в наш продукт. Естественно, применять эти правки мы не могли, так как на проде уже существует это улучшение модуля, но как задание по определению уровня разработки, навыков и быстродействия — мы получили первичное понимание о работе кандидатов.
Затем провели мини-лекции о особенностях PIX Studio, но не о базовых, которые можно вычитать, а о внутренних модулях и фреймворках. В особенности про методы реактивного программирования, чем наша разработка отличается от всех других на C# и почему обычный код на C# не заведется.
А после я разделил ребят на три команды. В каждой команде было по два человека: один работал удаленно, а другой — в офисе. Это создало равные условия для всех, и мы могли перейти к основным задачам. И тут мы столкнулись с очередной неожиданностью.
Нюанс 2. Командная работа решает
Мы запланировали три уникальные задачи, каждая из которых имела свою степень сложности: простая, сложная и очень сложная.
Мы рассчитали, что команды справятся с заданиями в течение 1-1,5 месяца. Почему так много? Мы придерживаемся практики «(Сколько я потрачу времени, чтобы реализовать это + сколько нужно времени на коммуникацию ) Х коэффициент стажера (2) Х 30% погрешности», итого по этой формуле вышло (7 дней + 2 дня) Х 2 Х 30% = 23,4 рабочих дня. Однако, благодаря их упорству и отличной командной работе, они смогли завершить все задачи всего за две недели!
В последствии, количество ожидаемых дней их разработок стало падать, и стало примерно равным скорости обычных младших разработчиков. И мы поняли, что можем рассчитывать на срок выполнения задач, как от рядовых сотрудников.
Что даст работа в команде? Как минимум — софт и хард скиллы по работе в команде с неизвестным, обговаривание действий на созвонах, декомпозиция сложной задачи на несколько простых и поэтапное выполнение с тестом.
Двойной код ревью, перепроверки и еще раз переспросить
Код ревью — очень важный этап разработки, а в случае со стажерами, пожалуй, ключевой. Очень, очень опасно проводить ревью кем-то из участников стажировки, все-таки опыта у них почти нет, а оценка рисков и ошибок должна быть серьезная (в принципе, некоторые IT-компании в принципе против кругового ревью, ведь некоторые разработчики могут по-дружески ставить апрув, ну а в нашем случае со стажерами приведет к коду AA = BB - CC и потом разберись, что тут).
Так что мы решили, что в случае реализации простых задач, код ревью буду проводить только я как их тимлид. А когда задача была сложной и очень сложной затрагивала уже работающие компоненты, то мы ввели двойной этап код ревью. Такой скрупулезный анализ: сначала ревью проводил я, а затем техлид нашей команды разработки.
Выстроив такую логику, мы лишились громадных проблем на внедрении новых разработок. Тестировщики получали сразу полностью готовый и рабочий продукт, пусть цикл «ревью – на доработку» иногда проходил по 10 раз. Но ничего страшного — они только учатся.
Нюанс 3. Все понятно — не значит понятно
Эх, этого пункта я вообще не ожидал, а меня предупреждали…
Мне казалось, что я подготовился максимально: объяснял все по несколько раз, разъяснял ошибки, терпеливо все показывал, следил за нагрузкой, снова объяснял и повторял, вспоминая себя в юности. Я был готов к ошибкам, но они все равно поджидали меня в самых неожиданных углах и подворотнях!
Так что напоминаю себе и всем, кто хочет стать ментором:
Вас не будут слушать и воспринимать с 1-ого раза.
Все повторяйте 100500 раз.
Миллион раз спрашивайте «Все ли понятно?».
Миллиард раз задавайте себе вопрос «А вы бы сделали в их возрасте то, что они должны сделать?».
Триллион раз проверяйся все, что делают стажеры. Сидите с ними и следите за ними. Но так, чтобы они не поняли этого. Как говорится: «Скрывайся на виду у всех».
И знайте, что стажеры могут удивить вас (как позитивно, так и не очень).
Потому что за эти три месяца мы увидели большое число интересных ляпов, которые не свойственны разработчику, и если стажеру о них не сказать — это выльется в проблему.
Мой любимый кейс — именование коммитов. Коммит — это комментарий промежуточного или финального этапа разработки, благодаря им, мы по истории понимаем что, кто и когда сделал, и можем в случае чего вырезать.
У нас есть правило, как и у всех компаний, что коммит называем номером задачи + то, что выполнил.
Что мы ожидаем:
Казалось, какие ошибки тут могут быть? А вот что мы увидели:
И смешно, и грустно.
Созваниваемся со стажером, объясняем эти проблемы, говорим, что так нельзя. Показываем все заново и говорим фразу «Перепиши историю коммитов, пожалуйста».
И что мы получили?
ДА, НО НЕТ. Этот принцип будет везде следовать за вами, главное набраться терпения и спокойно уметь объяснить сложные вещи на пальцах.
Так что я вывел такую формулу по итогу работы со стажерами:
Полная отдача + проверка + помощь = возможно классный специалист.
Как совместить работу разработчика и тимлида?
А теперь немного обо мне, ведь эта стажировка стала обучением и для меня. С одной стороны, стажировка ограничивалась 4 часами в день, 5 дней в неделю, то есть, это ровно половина моего рабочего времени. С точки зрения статистики и планирования — у меня есть время на разработку. И это, пожалуй, нюанс 4.
Нюанс 4. Неверное планирование
«У меня останется время на разработку» — так думают почти все, кому дают менторство или тимлидство впервые, но это совсем не так. Если твоих сотрудников нет на работе, это еще не значит, что ты можешь оставить свое тимлидство на полочку и решать задачи, как прежде.
В самом начале стажировки мы с моим тимлидом постановили, что самая главная моя задача — быть их руководителем, менторить, реализовывать и так далее, но с точки зрения меня как разработчика — я не буду приносить никакого результата. Поэтому моя жизнь в какой-то степени облегчилась, ну, я так думал сначала...
В самом начале стажировки мне удавалось высвобождать время на решение задачек. Но спустя две недели я осознал, что это становится невозможным, и пора становиться менеджером.
Что мне помогло, чтобы стать хорошим тимлидом и остаться при этом разрабом?
1. Управление временем и приоритетами
Как разработчик, я уже знаком с техническими задачами, но в роли тимлида мне нужно будет уделять время управлению командой и проектами, а это серьезный труд, требующий подготовку заранее.
2. Развитие управленческих навыков
Чтобы эффективно выполнять обязанности тимлида, необходимо развивать навыки коммуникации и управления. Это включает в себя умение слушать, давать конструктивную обратную связь и мотивировать команду.
3. Делегирование задач
Мне нужно не бояться делегировать задачи другим членам команды. Это позволит сосредоточиться на более важных аспектах управления проектом и обеспечит развитие навыков у моих коллег.
4. Баланс между техническими и управленческими задачами
Мне нужно стараться находить баланс между техническими задачами и управлением командой. Теперь выделил определенные дни или часы для работы над кодом, чтобы не терять свои навыки и оставаться в курсе темпов разработки.
5. Тренироваться на необычных менеджерских кейсах
Опыт тимлидства нельзя вычитать в книжках, или нагуглить на форумах, это то, что приходит с опытом. Без проблем – не будет опыта в этом, без должности тимлида – нельзя развиться в хорошего тимлида, но отточить мастерство мне может помочь искусственный интеллект.
Да, я иногда создавал себе мини-собеседование с GPT, где писал следующий промпт:
«Я работаю начинающим тимлидом команды разработки, напиши мне какой-нибудь кейс менеджерской проблемы, чтобы я ответил на нее, а ты проанализировал ответ и улучшил мои навыки.» в ответ я получаю кейс, который очень похож на реальный, и отвечаю нейронке. В результате я получаю идеализированный ответ и подточенный мой ответ, чтобы осознать свои ошибки и стать лучше.
Как получить 30% релиза PIX Studio от стажеров? Оцениваем результаты
А теперь к самому главному. Построим график полезности сотрудника в отделе разработки по времени:
Если прочитать график, многие сразу говорят — брать разработчиков невыгодно, так как они способны прийти к какому-то значительному вкладку только на 3-ем месяце стажировки, и это так. Но, если мы посмотрим на это через призму того, что стажер всегда выполняет производственные реальные задачи, то сначала он будет создавать код медленно, а затем быстро наловчится и придет к хорошему показателю кпд.
Другими словами, т.к. мы постановили, что стажерам выдаем реальные задачи, то вклад в будущий релиз становится ощутимым и значимым. К концу сентября мы выпустили релиз PIX Studio, который содержал в себе 30% задач, выполненных стажерами — а это ощутимый результат.
Как итог — получилась весьма продуктивная стажировка не только для стажеров, но и для продукта. Мы все остались довольны, выполнили задачи в срок и выпустили классный релиз. Я, как тимлид, получил бесценный огромный менеджерский опыт, осознание, что тимлидство мне нравится и что это путь для дальнейшей карьеры. А стажеры получили увидели все аспекты реальной работы и поняли, какого быть разработчиком.
А теперь минутка рекламы: набор на летнюю стажировку по C# в команду разработки PIX RPA объявляется открытым!
Так что, если вы (или ваши знакомые) готовы много учиться и строить карьерный путь, отправляйте заявки. Обещаем поддержку команды, уютный офис (если вы из Москвы), сертификаты, рекомендации и пр. и пр. Благодаря прошлой стажировке мы заполучили двух талантливых младших разработчиков. Не сомневаюсь, что так будет и в этот раз 😊
Если Вам интересно что-то узнать дополнительно, остались вопросы или предложения —пишите их в комментариях! Удачного всем карьерного пути!
