Top.Mail.Ru

Ищете разработчиков в продуктовые команды? Есть три совета

Колонки
Колонки
Кирилл Иванов
Кирилл Иванов

Технический директор Self_

Ирина Печёрская

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

В Self_ тоже столкнулись с этим и смогли нашли решение. Разбираемся, как находить и успешно интегрировать в agile-команду продуктовых разработчиков.

Ищете разработчиков в продуктовые команды? Есть три совета
  1. Колонки

Self_ 10 лет на рынке. Сегодня здесь работают 60 человек, из них 45 — это разработчики. В общей сложности командой реализовано более 200 проектов. Среди наших клиентов такие авторитетные компании, как «Ростех», «Связной Банк», «ВТБ», «Газпромбанк», «Манго Страхование» и другие крупные игроки.

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

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

Разработка продукта подразумевает долгосрочное сотрудничество с заказчиком, где качество нашей работы определяет выполнение KPI клиентов, их прибыль и дальнейшее развитие, в котором мы заинтересованы участвовать и дальше.

Никаких HR

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

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

К слову, это большая проблема найма в IT. Многим нашим клиентам мы помогаем сформировать внутренние команды. И видим, что стандартные первичные HR-интервью сокращают воронку кандидатов процентов на восемьдесят. Рынок, как я сказал, перегрет. Понимая это, специалисты требуют какого-то минимального уважения.

А тут приходит эйчар и говорит: «Какой у вас опыт работы с очередями?». Кандидат уточняет: «А в ваших проектах какие используются протоколы?». Эйчар этого знать не может. Разговор зашел в тупик, и человека мы, скорее всего, потеряем.

Найм в IT — это в первую очередь продажа компании. Особенно в продуктовой разработке. Мы всегда интервью начинаем с того, что просим человека задавать вопросы, а не гоняем его по каким-то техническим темам. Сначала мы продаем ему себя, ведь это нам как команде нужны мотивированные люди, а не просто хорошие исполнители — это специфика принятого у нас agile-подхода.

Интервью проводят технические специалисты и скрам-мастера. Они приходят и говорят: «Вот мы ищем себе бэкенд-разработчика. У нас вот такой заказчик. У нас вот такие сложности». Человек сразу понимает, куда он попадет.

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

Мы же всегда пытаемся быть максимально честными с кандидатами. Периодически даем фидбэк прямо на интервью. Часто готовим для соискателей развернутый отчет с описанием их сильных и слабых сторон. А для себя заполняем чек-лист, в котором расписаны hard и soft skills. И не просто ставим плюсы и минусы, а оставляем расширенные комментарии по каждому пункту.

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

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

Да и вообще у нас тестирование — скорее исключение. Оно уместно, если мы не уверены в hard skills кандидата. Или если человек сам понимает, что ему не хватает каких-то навыков и готов быстро разобраться. Вот пара реальных наших тестовых для аналитиков:

Задача 1 Задача 2
Написать требование/постановку для разработчика мобильного приложения по реализации карты банкоматов и отделений банка.
Можно опираться на реализацию популярных банков.
Формат требования — свободный, все, что вы считаете необходимым для возможности взять в работу задачу со стороны разработки.
Заказчик прислал первоначальную постановку — ее необходимо дополнить/обогатить, чтобы можно было формализовать полноценное требование.
User Story
Я как клиент хочу иметь возможность выбрать из списка продуктов банка дебетовую карту и выпустить ее.
В процессе заявки должны быть предусмотрены следующие шаги:
1. Выбор транспорта денежных средств. Карта может быть как физическим пластиком, так и токеном электронных кошельков (ApplePay/GooglePay/SamsungPay).
2. При выборе карты (физического пластика) необходимо реализовать возможность выбора доставки карты в отделение или курьером.

Продумать требования

С технической точки зрения все просто. Мы обычно рассматриваем кандидатов уровня мидл, мидл плюс. Готовы брать джуна на вырост, только если видим высокий уровень интереса к проекту и команде и потенциал для роста. Соответственно, мы ожидаем от кандидата владения 99% нашего стека технологий.

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

Очень важный аспект — умение и желание работать в гибких методологиях. Мы верим: создать качественный продукт, который не устареет к моменту запуска, можно только с гибкими методологиями. От каждого участника команды требуются скорость и гибкость. Только так мы принесем пользу нашему клиенту и его клиентам. Поэтому мы всегда обсуждаем с кандидатом основные принципы аджайла и скрама, чтобы понять, насколько человек принимает это. С нами ему придется плотно работать в этой системе, что не всем комфортно.

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

Перестроиться на «гибкие рельсы» быстро не получится. Опытному разработчику нужно года четыре поработать в agile-команде, чтобы переформатировать мышление, новичок подстроится быстрее. Это нужно понимать на берегу, иначе всем будет неудобно и тяжело.

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

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

Конечно, у нас есть ребята, которые говорят: «Биться за продукт, делать его лучше — я всегда за. Но вот, простите, выступать на демо я не могу, я просто стесняюсь». Это нормально. Со временем кто-то втягивается в выступления, кто-то пробует пару раз и понимает, что ему некомфортно. Без проблем.

Предложить комфортные условия труда

Важный аспект успешного найма — обеспечить разработчику комфортные условия труда и качественное общение (помимо задач и оплаты). Как я и говорил, IT-специалисты избалованы рынком и привыкли к тому, что их заманивают всякими штуками. У нас они тоже есть, хотя и в небольшом количестве.

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

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

Как получить максимум

Быть радикально честным

Наверное, ключевая вещь — это честность. Честная вакансия, с реальными условиями и требованиями. Честное интервью, на котором вы расскажете про команду и проект.

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

Интервью должны проводить подкованные люди

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

Уметь рассказать об условиях работы, формальностях и нюансах оформления

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

Соблюдать баланс между свободой и защищенностью

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

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

Мотивировать не деньгами, а интересными задачами и быстрым развитием

Продуктовому разработчику нужны современные технологии и опытная команда, которая сможет подарить ему новую экспертизу. Если это все есть, то зарплату можно указать даже ниже рынка. Разработчикам, в особенности, продуктовым, категорически важна интересность проекта.

Но и дополнительная мотивация не помешает. Продумайте бонусы по результатам проекта. Дайте сотруднику плюшки, которые будут полезны и вам, и ему: оплатите профессиональное обучение, занятия спортом. Дайте оборудование, с которым комфортно работать.

В IT каждый день выходят новые фреймворки, появляются новые технологии. Это значит, что ребятам нужно постоянно учиться, для них это жизненно необходимо. Это их будущее. И одновременно — будущее команды. Растут наши специалисты — растет вся команда. Win-win.

Фото на обложке: puhhha/shutterstock.com

Нашли опечатку? Выделите текст и нажмите Ctrl + Enter

ТЕГИ
ArtTech — карта разработчиков арт-технологий
Все игроки российского рынка технологий для искусства
Перейти

Материалы по теме