Все о выращивании специалистов внутри компании: зачем, как и когда этого делать не надо

На рынке всегда дефицит сеньоров и недостаток мидлов, а вот джунов много, особенно в последнее время. И, если позволяют ресурсы компании, этих джунов можно брать и выращивать внутри, подтягивая до нужного уровня или даже совершенно других компетенций. Однако для этого нужна особая культура внутри компании и некоторые конкретные инструменты. Об этом расскажет Ариадна Данцкер, ментор Solvery и Cluster IT Lead в Райффайзене. Передаем ей слово.

Я работаю в IT уже 8 лет. Училась на то, что сейчас называют Data Science, хотя тогда такого понятия у нас в России еще не было. После учебы какое-то время работала не совсем по специальности, на заводе Procter and Gamble. Потом все-таки ушла в IT и прошла путь от стажера-разнорабочего в команде аутсорсеров до руководителя достаточно большой команды. Сейчас кроме руководства я занимаюсь менторством в Solvery — помогаю людям стать более эффективными и реализованными. Работа отнимает очень много времени — и важно, чтобы это время тебя радовало.

Я активно пропагандирую идею, что работа с развитием и удержанием сотрудника в команде начинается с собеседования. Именно здесь вы формируете у него ожидания от будущей работы — и ваша задача, чтобы потом эти ожидания не разошлись с реальностью.

Если у вас в компании есть культура роста, нужно еще на этапе собеседования проверять, впишется ли в нее новый человек. В том числе для этого важно собеседовать не только по хард-, но и по софт-скилам. И сразу обрисовывать кандидату, что именно его ждет.

Если у вас в команде внезапно оказывается человек, которому не особенно интересно профессиональное развитие — подумайте, почему это случилось. Переработайте структуру собеседования, чтобы еще на интервью проговаривать, как у вас в компании относятся к обучению, чего ждут от сотрудников, что готовы предоставить. Например, расскажите про обязательный план развития — если человеку это совершенно неинтересно, он скорее выберет другую компанию, где к этому относятся проще.

Что делать, если в команду уже попал такой человек, и есть потребность развить его навыки, потому что их не хватает для решения текущих или будущих задач? Я думаю, что нужно поговорить и на конкретных примерах объяснить пользу от обучения. Начать можно с подтягивания скилов по каким-то конкретным инструментам или библиотекам — а потом человек внезапно для себя может втянуться в эту историю более глубоко. Когда поймет, что это реально важно и делает его работу интереснее.

Вообще человек, который долго работает в IT, практически в любом случае развивается. Но скорость и направление будут зависеть от того, какая среда создана в компании. Здесь есть два уровня.

Микроуровень, уровень команды. Планы развития, помощь друг другу, регулярные ассессменты, код-ревью. Тут все во многом зависит от тимлида и от других членов команды — какие практики они используют и как к ним относятся. Код-ревью сейчас есть почти везде, а вот парное программирование или регулярные встречи с обсуждением плана развития могут быть не внедрены.

Макроуровень, уровень организации. Общие практики, принятые в компании. Профессиональные сообщества, обучающие мероприятия, профессиональные оценки. Оплачивают ли обучение, есть ли менторы, с которыми можно позаниматься, чтобы подтянуть те или иные навыки. Выстроены ли системы оценки, есть ли для этого отдельные люди, команды, четкие критерии.

Как правило, все начинается именно с макроуровня. Если в компании с условиями для развития все нормально, то и для команд будут существовать более-менее отлаженные процессы. Но микроуровень все равно обеспечивает именно тимлид и члены конкретной команды.

Я лично с таким не сталкивалась, но представляю, что где-то такое может быть. Либо культура развития присутствует, но слабая, и на микроуровне хочется сделать что-то большее.

В первую очередь нужно обсудить с командой — а видят ли они потребность в развитии? Или их устраивает политика компании «просто работать»? Если устраивает, то придется оставить все как есть — и, возможно, сменить работу. Если нет, можно попробовать действовать. Лучше внедрить следующие инструменты:

• Код-ревью. Если его нет, его обязательно нужно внедрить. Договориться о критериях хорошего кода, запланировать время для просмотра и комментирования кода друг друга. Возможно, команде тут понадобится мастер-класс — стоит его организовать. Иногда на этом же этапе становится понятно, в каком именно направлении членам команды нужно развиваться.
• Парное программирование. Более опытный сотрудник работает в паре с менее опытным, и они решают задачу совместно.
• Индивидуальный план развития. Составлять с каждым членом план навыков, которые ему нужно освоить. Важно, чтобы они не были оторваны от реальности и соответствовали потребностям команды. То есть чтобы их можно было сразу применить на практике.
• Мастер-классы от членов команды. Кто-то в команде наверняка лучше других разбирается в каких-то вопросах. Организуйте взаимное обучение — пусть люди учат друг друга. Например, проводят небольшие лекции. Или каждые две недели устраивают «час технического мастерства», на котором разбирают интересные и сложные темы.

Также можно попробовать воздействовать на макроуровень. Например, запросить лекции по навыкам, которые будут реально полезны для компании. Или попробовать организовать профессиональное сообщество, привлекая участников других команд. Но часто это сложно и требует очень серьезной работы.

Мотивация тимлида в выращивании сотрудника понятна — так он получает в команду более высококвалифицированного специалиста. Однако рост во многом зависит и от действий других членов команды. А зачем им тратить свое время на другого человека? Причин несколько:

Собственный карьерный рост. Во многих крупных компаниях для роста в должности нужно заниматься менторством и обучением других сотрудников. А даже если это условие необязательное, обучение других все равно сильно прокачивает софт-скилы и способствует развитию, особенно до руководящих должностей.

Собственное развитие. Обучение кого-то — лучший способ учиться самому. Вспомнить что-то забытое, разобраться в том, чего не понимаешь, может быть даже освоить что-нибудь новое. Как правило, наблюдая за тем, как один сотрудник учит другого, я на самом деле вижу параллельное развитие двух людей.

Удовольствие от процесса. Часто учить кого-то или помогать кому-то просто приятно.

Работа в более профессиональной команде. Чем сильнее будет каждый сотрудник в команде, тем лучше будет продукт, который они сделают. Но нанимать сразу сильных удается не всегда: они или очень дороги, или их вообще нет на рынке. Команда, которая понимает важность скила каждого члена, сама будет вкладываться в обучение друг друга, чтобы достигать еще больших высот.

Тренировка перед публичными выступлениями. Если сначала читать небольшие лекции и проводить мастер-классы у себя в команде, потом выступать на конференциях будет намного проще. Это хорошая стартовая точка для тех, кто хочет прокачивать личный бренд или просто выступать на разных мероприятиях.

У меня есть много историй роста, за которыми я наблюдала лично или в которых непосредственно участвовала. Но самая интересная не о вертикальном, а о горизонтальном росте — когда человек сменил не просто должность, а целую профессию.

Мы в команде занимались только backend-компонентами. В какой-то момент возникла потребность часто делать доработки в мобильном приложении. Мы с командой собрались и стали думать: нанимать кого-то со стороны или выучить одного из наших? На обучение было достаточно времени, задачи не горели. Один сотрудник согласился — сказал, что хотел бы попробовать.

Мы нашли ему крутого ментора по Android, выделили обоим сотрудникам время из рабочего, установили срок изучения теории — два месяца. Вместе с командой собрали мелкие простые задачи и баги, с которых он начнет работу, чтобы применять знания на практике. После обучения сотрудник смог делать самостоятельно базовые вещи — нам этого хватало. Постепенно он развивался и в итоге стал тянуть на крепкого мидла, плюс полностью закрывал нашу бизнесовую потребность в доработках для Android.

Какое-то время он работал мобильным разработчиком и стал больше погружаться в специфику бизнеса. Я думаю, дело в том, что, работая над бэкендом, он меньше понимал, как его работа влияет на клиентов. А в мобильной разработке увидел это более наглядно. Понял, что работа с клиентами ему интересна, и в какой-то момент решил, что хочет быть продактом.

Тут уже он обучался не сам, а прошел курсы — GoPractice, я их рекомендую всем продактам. И в итоге получился человек, который хорошо понимал, как работать с кодом, delivery, мобильной аналитикой и практически всем, чем нужно. Стал внутри компании продактом и с тех пор успешно им работает.

В целом развитие сотрудника — как научно-технический прогресс: помешать ему невозможно, даже если у вас почему-то есть такое желание. Но бывают ситуации, в которых стоит сначала подумать, а потом оплачивать обучение — неважно, рублями или рабочим временем:

• Когда человек просто без причины хочет что-то изучить. Например, поработать с Docker, хотя в компании его вообще не используют. В таком случае он может изучать это сам, но ресурсы компании на это тратить не стоит — это никак не будет применимо на практике.
• Когда планы компании слишком неопределенны. Например, есть только предположение, что в будущем может понадобиться какая-то технология. В таком случае человек может ее выучить, а предположение не оправдается. Он потратил время на обучение, а если захочет применять новый навык — вообще может из компании уйти.
• Когда бюджеты команды сильно ограничены. Развитие сотрудника повышает его стоимость на рынке труда. Если вы не готовы платить ему больше, лучше не форсировать развитие. Особенно это касается роста мидлов и сеньоров.

Всегда думайте, что и зачем вы делаете, четко обозначайте цели — и тогда станет понятно, как именно действовать.

Если хотите пообщаться с Ариадной по поводу выращивания специалистов и личного карьерного развития — это можно сделать в сервисе по поиску менторов Solvery.

А вакансии в крупных компаниях, в которых уже есть среда для профессионального роста, можно найти в телеграм-боте getmatch. Разные технологии, релокейт, зарплаты до 450 тысяч — и все бесплатно и подобрано под ваши требования.

• Карьерный рост в IT: почему важно всегда мониторить рынок и переходить на работу, к которой еще не готов
• Найм в 2022: меньше релокации и удаленки, но прежние планы. Немного цифр и комментарии HR
• Главное о вопросах на собеседовании: каких ждать от HR и какие задать самому