9 ошибок при найме разработчика в продуктовую команду

Napoleon IT
17-01-2022
1049
Разное
9 ошибок при найме разработчика в продуктовую команду

1. Отсутствие опыта работы в кросс-функциональной продуктовой команде 

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

Также в таких командах применяется итеративно-инкрементальный подход. Он предполагает, что  работа идет короткими итерациями — в новые версии продукта регулярно и часто внедряется самый приоритетный с точки зрения бизнеса функционал. Чаще всего итерация длится не больше двух недель. За это время нужно успеть спроектировать, разработать, протестировать и выпустить полностью готовую часть продукта. Задача —  как можно скорее получить данные с живого рынка о реакции пользователей.  Разработчикам, которые не привыкли работать в таком динамичном ритме, предпочитают заранее получать детально описанные требования и много времени уделять проектированию системы, может быть сложно перестроиться. 


2. Неподходящая инженерная культура 

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

3. Разработчик-суперзвезда 

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

4. Низкий уровень вовлеченности в продукт  

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

5. Разные взгляды на треки обучения 

В процессе разработки  всегда есть «узкие горлышки». Часто они встречаются в компетенциях по бэкенд-части, анализу данных и тестированию. В таких случаях, развитие разработчика в одной из дефицитных областей укрепит команду и ускорит время выпуска продукта. Но не все сотрудники  готовы быть T-shaped-специалистами и осваивать непривычные для себя навыки. Многие фокусируются на  своей узкой специализации, особенно если она редкая, чтобы стать высокооплачиваемым сотрудником в менее конкурентной среде. Стоит заранее прояснить, готов ли  кандидат изучать то, что необходимо для разработки продукта, и узнать, по какому принципу он выбирал вектор развития на прошлых местах работы. Так, вы поймете, насколько будут оправданы инвестиции в его обучение .Выбирайте специалистов, готовых развиваться в новых направлениях, которые могут потребоваться вашему продукту.

6. Неумение работать с обратной связью

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

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

7. Отказ от общения с пользователями и заинтересованными лицами

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

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

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

8. Неверная оценка основных компетенций разработчика 

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

9. Фокус только на профессиональных навыках

Исследования и практические проекты показывают, что для прогноза адаптации и эффективности сотрудника на новом месте, необходимо анализировать его “мягкие” навыки (soft skills) и мотивацию. Ч чем выше уровень позиции сотрудника,  тем большее значение они имеют для его карьерного роста.

Какие именно soft skills и виды мотивации необходимо принимать во внимание? Для ответа на этот вопрос, мы провели  исследование. Оно охватило более 100 компаний, работающих  на рынках России, США, Европы и Китая. Результаты показали, что те soft skills, которые в значительной мере определяют скорость и качество адаптации сотрудника  в новой компании, можно сгруппировать в четыре основных кластера: «Взаимодействие с инновациями», «Подход к решению задач», «Взаимодействие с людьми» и «Поведение в стрессе. Внутри каждого из них мы выявили ключевые компетенции. Например, в кластер «”Взаимодействие с людьми» вошли коммуникативность, экстраверсия/интровесрия, межличностная восприимчивостьЮ кросскультурная адаптивность и способность к командной работе. Оценка этих навыков в рамках рекрутмента позволяет точно определить индивидуальные предрасположенности кандидата  и, как результат, подобрать для него наиболее комфортную среду работы. А это, в свою очередь, залог успеха компании.

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

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



 

Поделиться
Больше не нужно искать и обзванивать диджитал-агентства!
Создайте тендер и получите предложения от лучших веб-студий Украины.
В каталоге 1700+ диджитал-агентств, готовых помочь в реализации ваших задач. Выберайте и экономьте до 30% своего времени и бюджета! Это бесплатно и займет менее 3-х минут.
Создать тендер
Статьи по теме
01-01-1970
01-01-1970
01-01-1970
01-01-1970
Перейти к списку статей
Подписка на рассылку
Получайте одно письмо в неделю с самыми важными новостями.
Bug