Меня зовут Эльдар Мингалиев, я работаю в компании Neti, которая занимается не только самостоятельным выполнением проектов, но и предоставлением разработчиков на проекты заказчиков.
Наши клиенты – не только заказчики, но и компании-интеграторы, которые нуждаются в разработчиках, консультантах. Такие заказчики хорошо разбираются в квалификации персонала и зачастую предъявляют к нам высокие требования.
За годы работы мы накопили обширный опыт работы с такими заказчиками и на основе этого опыта запустили стажерскую программу, про которую я дальше расскажу. Но доклад посвящен не только стажировке, а в целом – процессам подбора персонала.
Мы постоянно находится в поиске хороших разработчиков. За 12 лет существования компании мы только один раз приостанавливали набор – это был ковидный год. Все остальное время мы в поиске.
Мы хотим расти и расширяться, но хороших специалистов на рынке не становится больше. И это глобальная проблема.
Мы стремимся к тому, чтобы качество наших услуг непрерывно росло. Но не все специалисты разделяют наши ценности, и у нас достаточно сильная зависимость от входящего потока резюме.
Также не все специалисты хотят соответствовать нашим корпоративным стандартам, а переучивать 30 или 40-летнего человека не всегда возможно. Это скорее вызовет демотивацию, чем приведет к повышению эффективности работы.
Все эти факторы уменьшают количество потенциальных кандидатов, которых мы можем позвать на работу.
Осознав это, мы решили снизить зависимость от входящего потока резюме и запустили стажерскую программу – начали самостоятельно готовить кадры внутри компании. Пока наша стажерская программа рассчитана только на разработчиков.
Собираем портрет стажера
Кто к нам приходит
«Новички не идут в 1С» – такое мнение, на наш взгляд, ошибочное.
Молодые ищут работу не каждый день, и те кандидаты, которые нас интересуют, начинают проявлять активность в конце весны и начале осени, когда лето заканчивается, или все заканчивают писать диплом. В остальное время – большинство откликов от тех, кто хочет свичнуться в ИТ из кладовщика с опытом 10 лет.
Заявок на вакансию стажера всегда много – где-то раз в 40 больше, чем мы можем обработать за раз. А поскольку среди них много непрофильных специалистов, большинство не проходит первоначальный фильтр.
В итоге мы набираем стандартную для нас группу – 15 человек. Это экспериментально подобранный размер группы для одного наставника, больше точно не стоит.
Мы не проводим практически никакого продвижения нашего набора стажеров и публикуем вакансию только в одном регионе. Но эти люди находят нас и из других городов.
Кого мы берем
Входной поток очень мощный, и нам нужно четко представлять, как должен выглядеть «пластилин», из которого мы дальше будем «лепить» идеального разработчика. А поскольку мы платим за стажировку успешным кандидатам, то считаем, что имеем право выбирать наиболее сильных:
-
Мы стараемся брать кандидатов с профильным образованием. Это не догма, но довольно сильный триггер. Есть вероятность, что такой кандидат будет знать что-то, кроме материалов по 1С, например: компьтерные сети, проектирование приложений, проектирование СУБД и т.д. А это в конечном счете скажется на его будущих компетенциях.
-
Мы берем только людей с ИТ-бэкграундом, которые уже успели обжечься на каких-то своих пет-проектах, учебных задачах, смотрели какие-то курсы. Для нас подходит любой вариант предоставления учебных проектов: на любом языке, любом стеке. Мы все тщательно смотрим и можем оценить практически все что угодно. Не так важно получить диплом профильного ВУЗа (это хорошо), но еще лучше, если ты уже сам поработал с задачами, попрограммировал. Если этого нет, то мы считаем такого кандидата недостаточно замотивированным.
-
Мы не берем людей, которые не знают базовых вещей в программировании. По моему опыту, выработать у человека алгоритмическое мышление – это очень долго и сложно. Поэтому таких стараемся не рассматривать.
-
Мы отсекаем бездельников. Пытаемся понять, чего же человек хочет, что он знает о профессии в целом. Если человек ничего не знает, слышал только про зарплату, такой нам не подходит. И если человеку нужен только вход в ИТ, а надолго задерживаться он у нас не собирается, таких тоже стараемся вычислять. Мы ищем достаточно целеустремленных людей, имеющих представление о профессии, с которыми можно дальше работать.
В целом в опроснике для кандидатов у нас 23 вопроса, и только 5 из них по программированию.
Как проходит стажировка
Стажировка у нас – это марафонский забег длиною месяц: 5 дней в неделю по 8 часов в день в полностью удаленном формате. Это не обучение, а отбор с элементами обучения, в нашем случае – собеседование длительностью в месяц.
-
У нас подготовлено 4 блока учебных задач с дедлайнами.
-
Есть наставники, которые помогают с любыми вопросами, подключаются в любой момент.
-
Важный момент – мы не читаем никаких лекций, у нас только практика. Мы даем задачу и снабжаем теоретическим базисом, который человеку поможет эту задачу решить. Но этот базис не содержит прямых ответов.
-
Мы считаем, что в нашем деле большое количество теории, наоборот, отдаляет человека от результата. Кандидат должен показать свои навыки самостоятельного поиска и обработки информации. По факту это он и будет делать каждый день – искать какое-то решение, применять его, пытаться как-то переделать под условия задачи.
-
К обучению на курсах мы в процессе стажировки практически не прибегаем. Есть несколько курсов, которые нравятся, но это очень небольшая часть обучения. На мой взгляд, большинство курсов нужно смотреть уже после того, как попробовал что-то сделать сам, получил какой-то опыт. Тогда и курс смотреть интереснее, и некоторые моменты гораздо глубже понимаются, потому что ты уже успел сделать какие-то шаги. И теоретический материал тебе становится понятнее. А когда ты смотришь его в первый раз не зная ничего, половину пропускаешь мимо ушей.
-
Если кандидат успешно решил все задания, и нас все устраивает, мы зачисляем его в штат младшим разработчиком.
Софт-скилы стажера
В процессе стажировки мы оцениваем софт-скилы и считаем, что это – самое важное, потому что у стажера ничего другого, кроме таких скилов, и нет. Этих скилов несколько штук, и их довольно легко отслеживать.
-
Умение и желание задавать вопросы. Без вопросов ничего не получится. Это, наверное, единственный навык, который легко может перекрыть все остальные.
-
Стрессоустойчивость. Стажер может не выдержать внезапно свалившийся на него поток информации. Это момент, который важно отслеживать. Для некоторых людей неуспешная стажировка может поставить крест на их дальнейшем желании обучаться самостоятельно. Если у стажера во время выполнения какой-то задачи возникла проблема, и он долго не может прийти к решению – это повод для серьезного разговора с призывом уделить время отдыху.
-
Самообучение. Без этого навыка будет крайне тяжело. Если стажер делает что-то только после того, как наставник ему подсказал – это верный признак, что с самообучением у человека плохо.
-
Коммуникация/построение беседы. Стажер не должен вызывать негативных ощущений в процессе общения. Дотошность не в счет. Хороший стажер должен раздражать своей дотошностью, но в целом общаться дружелюбно, демонстрировать готовность к сотрудничеству.
-
Дисциплина. В будущем этот навык превратится в клиентоориентированность. Стажер должен понимать свою ответственность за корректное и своевременное решение учебных задач, должен вовремя отвечать на сообщения и звонки наставника.
Основываясь на пяти этих пунктах, помимо самих учебных заданий, мы можем легко понять, хотим ли дальше продолжать взаимодействовать со стажером или лучше прекратить.
Проблема обучения сотрудников
Думаю, что любая ИТ-компания нацелена на развитие имеющихся компетенций у разработчиков. Но когда все разработчики заняты на проектах, время на обучение есть только между проектами.
Часто в ответ на просьбу изучить какой-то курс, пока есть время между проектами, от разработчика можно услышать что-то вроде: «А зачем мне учиться в стол? Вот будет задача на проект, тогда я разберусь».
Но когда будет задача на проекте, разбираться уже будет поздно. Поэтому мы решили поставить обучение на новые рельсы. И начало этих новых рельсов мы заложили в стажировке и обучении джунов. Сначала нужно научиться учить тех, кто ничего не знает, и потом уже браться за «зубров».
Мы постарались быть последовательными и разрабатываем учебные задачи под все интересующие нас области знаний. Мы их называем «кубики» один «кубик» – это какая-то единица знаний: СКД, Vanessa Automation, «Конвертация данных», какая-то конфигурация или технология. Несколько задач, которые позволяют приобрести хотя бы навык джуна в этой технологии.
Когда перед человеком ставится практическая учебная задача, это почти всегда воспринимается как вызов. Программировать разработчики любят. А под это дело уже не так стыдно поднимать и теоретическую базу. Таким образом мы сами создаем ситуацию, когда у человека появляется внутренняя мотивация к обучению. Тут главное – контролировать процесс.
Роль наставника
Наставник – это очень важная единица. Он может как заинтересовать и замотивировать разработчика, так и полностью демотивировать.
Я уверен, что большинство успешных разработчиков, которых вы знаете, стали профессионалами своего дела без наставника. Эту роль взяли на себя форумы, чатики, личности, на которых хотелось быть похожими. И свой горький опыт.
Тогда зачем нужен наставник, если и так все работает?
-
Основная задача наставника – довести обучение до результата, при этом взвинтить темп, «утащить на глубину», продемонстрировать этот результат более явно.
-
От наставника зависит, как и чему научатся подопечные. Даже у самого целеустремленного подопечного могут возникнуть проблемы. Он может надолго застопориться или пойти не тем путем, что в итоге выльется в потерю мотивации.
-
В таких случаях нельзя бросать людей на произвол. Внимательный наставник может уменьшить время обучения и улучшить осознание результата обучения в разы.
-
Всем, кто начинает чему-то учиться, важно понимать, когда он сделал хорошо, когда плохо, когда правильно, а когда вообще неправильно. И еще лучше, если будут какие-то примеры, аргументы. Для этой цели мы даже разработали специальный сервис для обучения 1С, где автоматически проверяются решения задач на корректность.
Личность наставника
Софт-скилы, необходимые наставнику:
-
Квалификация. Наставник должен сам по себе быть хорошим и опытным специалистом в том, чему он обучает. Желательно, чтобы у него был опыт мелких и крупных провалов. Такой человек сильнее осознает цену ошибки. Можно и без такого опыта, но только в том случае, если специалист повидал достаточно чужих провалов и проводил над ними рефлексию.
-
Умение мотивировать. Наставник должен представлять себе цель происходящего и уметь напомнить об этой цели подопечному. Демонстрировать ценность достижения этой цели.
-
Развитый эмоциональный интеллект. В первую очередь – это контроль собственных эмоций. Подопечный может раздражать или быть душным. Важно находить в себе правильные эмоции для того, чтобы не обращать на это внимание. Эмпатия и умение управлять эмоциональным состоянием подопечного – очень важные умения. Здесь важный момент – насколько человек осознает собственные эмоции и может ли представить себя на месте подопечного.
-
Понимание наставничества как процесса. Наставничество – это не просто разговоры, нужно уметь вовремя подготовить материал, уметь работать с документами, фиксировать процесс обучения. Нужно самостоятельно определять план обучения и методику, и если у подопечного что-то не получается, нужно методику поменять. Возможно, пойдет лучше.
-
Умение давать обратную связь. Наставник должен давать обратную связь не только подопечному, но и своему руководителю, а также другим наставникам. Умение делать это корректно, точно, по сути и коротко дается далеко не всем и не сразу.
-
Коммуникация и ведение беседы. Наставнику нужно уметь грамотно и кратко объяснять свои мысли, подбирать аргументацию для убеждения, отличать открытые вопросы от закрытых, уметь структурировать и управлять целым ходом беседы.
-
Планирование времени. Важно уметь экономить и свое, и чужое время. У многих наставников возникает желание уделить подопечному слишком много времени, хотя можно было обойтись короткой пятиминутной беседой.
Если подытожить, то наставник должен быть мягким в общении, но твердым в решениях. Если наоборот – это точно не сработает. Отсутствие твердости и последовательности не позволит построить обучение эффективно.
Стажер стал джуном: что дальше
После прохождения стажировки успешные кандидаты зачисляются к нам в штат младшими разработчиками, но обучение на этом не заканчивается. Мы также разработали и подготовили учебные задачи, которые джун делает в процессе работы.
-
После зачисления кандидата в штат наставник также продолжает с ним работу, но уже более детально. Важно, что стажеры решают все задачи индивидуально, чтобы не портить друг другу впечатление от поиска решений. Но, попав в штат джунами, мы объединяем их в группы.
-
Объединение в группы позволяет сэкономить время наставнику. К нам может попасть 15 человек, и объяснять все каждому отдельно – трудно эмоционально и долго по времени. Работая в группах, они начинают синергично дополнять друг друга, помогать развиваться дальше. Конечно, у нас есть и экзаменационные задачи, которые мы выдаем отдельно и не разрешаем работать над ними в группах.
-
В процессе обучения мы наблюдаем за поведением каждого джуна. Ведем учет джунов. У стажеров – это ежедневный учет, у джунов – еженедельный или ежемесячный. Мы смотрим, какое впечатление сложилось у наставника от конкретного человека.
Процесс становления разработчиком достаточно длительный и требует детальной проработки разных вопросов. Наша задача – как можно быстрее вырастить из джуна начинающего мидла, потому что джуны, если говорить откровенно, никому не нужны.
-
Мало научить джуна только техническим приемам, важно дать ему представление и об инженерных практиках – научить разрабатывать в соответствии со стандартами, заложить навыки анализа и оценки задач. Даже если на ваших проектах всегда есть консультант, который пишет ТЗ, и архитектор, способный дать оценку, разработчику всегда нужно проводить анализ задачи – чего в ней не хватает, и что его отдаляет от решения. Он должен заранее понимать, из-за чего он может не успеть уложиться в срок, и предупреждать об этом.
-
Также очень важно уметь проводить рефлексию над своей работой. Я всех своих джунов прошу описывать, что они сделали, какого достигли результата, и что можно было сделать лучше. Без этого развитие может проходить неуправляемо.
-
В целом, мы стараемся обучить джунов профессии – как работать с комфортом. Это очень важный момент, потому что многие, начиная работать, сильно себя загоняют, желая сделать все и сразу, бежать впереди паровоза. Это приводит к стрессу и к дальнейшей потере мотивации. Нам нужно научить людей понимать, какие факторы в работе наиболее сильно влияют на собственное ощущение от работы. Какие практики помогают принести наибольший эффект от результата работы.
-
Во время обучения мы также стараемся давать джунам и «боевые» задачи, чтобы они адаптировались понемногу к реальному миру, видели, как заказчики пишут ТЗ, видели, как заказчик не принимает их работу и так далее. Но стараемся этим не злоупотреблять, реальных задач даем крайне мало – мы ориентированы на обучение, чтобы как можно плотнее заложить фундамент.
Обучение у нас проходит 6-9 месяцев. И после этого разработчик хотя и не имеет крепких хардскилов, но уже не потеряется в большинстве задач. А за счет софт-скилов и дисциплины сможет совладать с многими проблемами.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции Анализ & Управление в ИТ-проектах.