В New.HR подкасте мы обсудили с Романом Ивлиевым — техническим директором проекта mos.ru, почему программисты не особо хотят работать в госкомпаниях, как ему удалось вырастить команду с 3 до 50 человек, почему он берет на работу джунов и как привлекать разработчиков в госпроект с помощью HR-бренда.
Роман Ивлиев начинал с тестировщика ПО, разрабатывал проекты в «Лаборатории Касперского», «ИТАР-ТАСС», Woman.ru и Banki.ru. Последние 3 года он – технический директор проекта mos.ru, официального сайта правительства Москвы, где власти публикуют новости, афишу мероприятий, рассказывают о городских проектах.
В mos.ru Роману поставили задачу создать внутренний техотдел, чтобы заменить разрозненных специалистов на аутсорсе.
Мифы о работе в госкомпаниях
В госкорпорациях России никто системно не занимается развитием HR-бренда. У айтишников госпроекты ассоциируются с чем-то медленным, плохим и работающим на древних технологиях. А на самом деле большинство госкомпаний технологичные и работают на современной технике.
Кто-то считает, что в госах нет интересных техзадач, но это не так. Только в реестре МВД – 140 млн «пользователей», это, по сути, Badoo в молодости. Пенсионный фонд России разрабатывает сложные системы, «Почта России» открыла компанию «Почтовые Технологии», чтобы повестки в суды и штрафы приходили гражданам на электронную почту.
А mos.ru – это портал для жителей Москвы, который внешне похож на «Lenta.ru» 2005 года. У технарей нет ощущения, что это интересный проект, потому что техническая часть спрятана под капотом. Внутри сложные системы, связанные через множество интерфейсов, которые синхронизированы и работают согласно действиям законов.
Внутри «огонь», а снаружи иногда не очень, и отсюда развивается ассоциация, что государство делает плохо.
Со временем растущие требования к качеству и скорости разработки портала привели к тому, что в один прекрасный день было принято решение выделить разработку сайта в отдельный проект, собрать собственную команду и прокачать внутреннюю экспертизу.
На старте в ИТ-команде вместе со мной было четыре человека – сейчас же разработкой mos.ru занимается 50 человек, половина из них работает удаленно. Чтобы быстрее набрать команду, я проводил по 30-40 собеседований в месяц и параллельно разрабатывал план технического развития портала.
В то время находить разработчиков на портал было сложно, потому что люди плохо откликаются на вакансии компаний, продукты которых они не покупали или которыми не пользовались. Разработчики в регионах вообще не знали о портале, а московский средний специалист пользуется максимум тремя услугами: получить паспорт/ загранпаспорт или оплатить штрафы.
План развития портала выстроить проще, чем набрать айтишников в госкомпанию. Нельзя просто так прийти, встать на табурет и сказать: «Пацаны, я вот отсюда, я крутой, приходите, у нас здорово и замечательно»
Специфика работы в mos.ru
В целом разработка портала не сильно отличается от создания любого другого сайта, но есть свои нюансы, продиктованные, например, законодательством. Портал синхронизируется с выпускаемыми законами, поэтому разработка в ряде случаев зависит от постановлений правительства Москвы и федеральных законов. Если закон или постановление еще не появились, то команда ждет их и не может выкатить сервис. Или когда на заседании принимают поправки какого-то закона, разработчики обязаны срочно дорабатывать существующий функционал.
Разработка в mos.ru не имеет права срывать сроки. Нет смысла делать какой-то сервис для Масленицы, когда она прошла. Услуга, связанная со школой, должна работать с 1 сентября, ведь 2-го она будет уже не актуальна.
Задачи часто ставятся на довольно высоком уровне, поэтому наша команда состоит из пробивных сотрудников, которые готовы пойти к менеджеру, дизайнеру, тимлиду, чтобы разобраться в деталях.
Нам нужны ребята-геологи, которые шагают в неизвестность с палкой и фонарем.
Принципы найма Романа Ивлиева
Подход к решению задачи. На собеседовании нет правильных или неправильных ответов. Наблюдайте, как кандидат думает и принимает решения.
Спросите, что он не успел сделать на прошлой работе и почему. Если ответ: «Не сделал, потому что было мало времени» – это пассивная позиция.
Почему ушел с предыдущего места работы или "чем провинилась предыдущая компания". Этот вопрос покажет базовые ценности кандидата. Нужно спросить так, чтобы получить нешаблонный ответ.
Я спрашиваю, чем провинилась предыдущая компания. И некоторые люди с ходу начинают рассказывать, как их там гнобили, заставляли делать какую-то хрень. Для меня это чёрная метка. Я токсичного человека на работу не возьму. Не бывает идеальных контор, везде есть свои косяки, но лучше расскажи о хорошем, зачем мне знать о плохом.
Чем бы вы хотели заниматься. Спросите об интересах кандидата. Если он ответит: «Мне нравятся интересные задачи», – попросите расшифровать. Нормально, если он скажет: «То, чем вы занимаетесь, я никогда не делал и поэтому не знаю, нравится мне это или нет, но давайте попробуем».
Иногда спрашиваешь у человека, чем бы ты хотел заниматься, а он говорит, что ему по фигу. Я готов это услышать от 20-летнего пацана, который приходит джуном, но я не готов это услышать от мидла и дальше. Потому что ты должен уже определиться, что тебе нравится, либо сказать, что точно не нравится.
Образование и профильные курсы. По образованию сложно судить о человеке, ведь неясно, как именно он учился. Да и к качеству самого образования у вас могут быть вопросы.
У меня в команде успешно работало большое количество людей, которые изначально вообще не имели отношения к IT. Я работал даже с разработчиком, который был психологом по образованию, чуть ли не кандидатом наук.
Профиль на GitHub. Обращайте внимание на активность. Если у фронтендера есть репозиторий или какая-то активность с современными технологиями, значит, человек интересуется разработкой.
Профессиональный кругозор. В IT постоянно все меняется, поэтому важно знать об изменениях и постоянно учиться. Спрашивайте у кандидатов, что они читают, слушают, смотрят, за кем из экспертов следят.
Без самообразования не будешь расти, поэтому я постоянно пинаю своих пацанов, чтобы они ходили на конференции, смотрели ролики, чтобы команда обучалась. Например, в mos.ru мы запустили регулярные Tech-talks, на которых собирается вся команда, а кто-то один выходит и рассказывает, как он сделал какую-нибудь фичу. Это отличный формат для обмена опытом и среда для взаимного образования.
Этапы собеседований. В mos.ru проводят собеседования в несколько этапов. Первый: разговор с техническим директором по телефону или скайпу. Цель: продать вакансию и заманить разработчика на собеседование в офис, чтобы обсудить детали.
Звоню часто сам. По-моему, есть разница, кто приглашает на собеседование: СТО или HR. Со мной можно обсудить любые инженерные вопросы. Я всегда могу рассказать про работу больше, чем любой HR, знаю все тонкости.
Второй этап: техническое собеседование с командой. На этом этапе важно понять, получится ли у команды сработаться с кандидатом, поэтому важно развеять все сомнения на старте.
Мы искали старшего Frontend-разработчика 4 месяца, и кандидат чуть не слетел на последнем этапе. Свои ожидания от работы он сформулировал так: «Я бы не хотел, чтобы мне указывали, что делать». Но потом мы выяснили, что эта фраза про то, что кандидат хотел быть услышанным в рабочих моментах. Без этого контекста мы бы его не взяли, потому что фраза анархистская, а анархист у нас только я.
Третий этап: собеседование с HR. Если все хорошо – оффер. По статистике в mos.ru из пяти кандидатов предложение о выходе на работу получает один.
Фейковые резюме. Вы можете встретить кандидата с идеальным резюме, но при этом как специалист он будет никакой. А у классного разработчика резюме может быть скудным или вовсе отсутствовать.
Тестовые задания. Кажется, что тестовые задания имеет смысл применять к тестировщикам, но не к разработчикам или сисадминам. Сложное тестовое никто не будет решать, а простое выполнят все. А по-настоящему человек сможет проявить себя только на испытательном сроке.
Мы пробовали играть в тестовые задания. Давали поломанную сборку или криво написанный сервис. Но человеку никто ему не мешает обратиться за помощью к профессионалам и решить эту задачу за бутылку пива. Поэтому я всегда стараюсь максимально понять возможности кандидата на собеседовании.
Когда стоит нанимать джунов
Начинающих разработчиков стоит брать исходя из проектной загрузки команды. Должно быть время на обучение джунов, и должен быть сеньор, которому интересно стать наставником.
Искать стоит заранее. Потому что вашим старшим разработчикам рано или поздно надоест заниматься рутинными простыми задачами, и они начнут перегорать. А вы к этому времени уже подрастите мидла, чтобы потом не искать замену сеньору.
Джунов стоит брать только на фултайм в офис, удаленно учить очень сложно.
С таким подходом я взял пять человек с уровнем чуть ниже мидл, они кроме верстки ничего не умели делать. Теперь они умеют JavaScript. Из пяти верстальщиков мы себе вырастили пять фронтенд-инженеров.
Как техническому директору собрать команду в короткие сроки
Советы Романа Ивлиева на примере работы в mos.ru:
- Думайте наперед. Продумайте план разработки на полгода, чтобы лучше понимать, кого в какой момент надо нанимать.
- Ищите сами. В первую очередь ищите среди знакомых или компаний, которые разваливаются или реструктуризируются.
Чтобы собрать команду, я сам звонил потенциальным сотрудникам. Искал их через знакомых и в веб-студиях, которые закрываются. Благодаря этому первую часть команды удалось скомпоновать из двух компаний, я схантил оттуда несколько человек.
- Образование ничего не значит. Не стоит отсеивать кандидатов из-за непрофильного образования, портфолио или резюме. Принимайте решение о найме вместе с командой. Реальные компетенции кандидата вы увидите на испытательном сроке.
- Собеседуйте кандидатов до HR. Это увеличит конверсию собеседований, а вы сможете научить своего HR нескольким вещам: правильно рассказывать про компанию и задачи, отвечать на вопросы и возражения кандидатов.
Например, на старте я заметил, что люди неохотно реагировали, когда узнавали, что у нас в штате три человека. Приходилось объяснять, что никто никуда не делся, что мы все строим с нуля.
- Развивайте HR-бренд. Выступайте на конференциях, митапах, на любых профильных мероприятиях. Если про текущий продукт пока нечего рассказывать, говорите про свой опыт, отношение к вечным вопросам в разработке. Ваша задача, чтобы вас начали ассоциировать с текущим продуктом и шли к вам, а не в продукт.
Я позиционировал себя в первую очередь как руководителя, а не как представителя бренда. И это работает. Некоторые приходят на собеседование и говорят, что видели меня на каких-то выступлениях. В метро подходят какие-то личности, говорят: «Вот ты книжку рекомендовал в Яндексе, а я забыл название».
- Рассказывайте честно о своем проекте. Объясняйте, чем вы отличаетесь от других компаний, и раскрывайте особенности.
На конференциях и тусовках я рассказываю, что у нас в mos.ru тоже можно работать и получать от жизни удовольствие, получать опыт, профессионально развиваться. И решать проблемы миллионов москвичей.
P.S. Послушать подкаст c Романом вы можете на любой удобной платформе: Soundcloud, Apple Podcast, Google Podcast, Castbox, Overcast, Youtube, Яндекс.Музыка, Telegram (@newhrpodcast)
О, прям такая ядрёная госуха чувствуется что в самой статье, что в каментах.
В таких местах нормальному спецу ещё и менеджером, и культуртрэгером, и педагогом приходится работать за те же бабки.
"Приди да помоги" лол, какая непосредственность. Ну да, в госухах обычно и приходится всем "помогать", т.е. фактически переделывать чужую работу. Спасибо, я уж лучше смузи похлебаю и сыром закушаю.
Ну я в коммерции отработал лет 10, там тоже регулярно приходилось и менеджером и помогать, быть культуртрэгером , педагогом и всё за те же бабки. Есть задача - её надо решить. По моим наблюдениям и общению с коллегами из самых разных контор - это повсеместное явление. Или если вас наняли разработчиком, то джунов подтягивать - удел воспитателя, а ваша задача хреначить код?
каких джунов? в госах не джунов, а старых пердунов надо подтягивать, которые там по двадцать лет сидят.
Вариант подтягивания старых пердунов в госах.