РБК Pro —  
это сервис для предпринимателей, руководителей и специалистов, которые хотят меняться и менять бизнес
Материал раздела Основной

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

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

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

Делимся девятью наиболее часто встречающимися ошибками, которые приводят к найму неподходящих кандидатов.

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

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

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