Команда как продукт. Практическое руководство по созданию и управлению продуктовой командой в IT - страница 8



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

Особенности найма в стартап или новую команду

Если говорить о новой команде или стартапе, то важно оценить ритм, в котором необходима поставка ценности бизнес-заказчику или стейкхолдеру. Если нужен агрессивный ритм, а обычно это именно так и бывает, то без специалистов с уровнем не ниже Senior просто не обойтись, ведь некогда погружать людей, тратить ресурс на обучение и адаптацию – есть конкретный скоуп задач, которые приведут тебя и твой продукт к заданной цели. Собирать команду стартапа с жесткими сроками из специалистов другого уровня практически бессмысленно, выживает всего один из десяти стартапов и срок его выхода на рынок зачастую играет ключевую роль. Стартапы, которые не требуют жестких сроков реализации, а делаются в спокойном режиме, вполне себе могут быть собраны специалистами уровня middle или middle+, но с точки зрения комплексных архитектурных решений, потенциала масштабирования продукта и его кроссплатформенности лучше иметь в команде хотя бы одного специалиста уровня senior.

Если же мы посмотрим на найм в новую команду в какой-нибудь большой компании, то ситуация тут весьма типична для сектора. Если на примете есть грамотные специалисты, то в таких компаниях, как правило, существует возможность организовать переход таких специалистов в твою команду как с рынка, так и в рамках ротаций внутри компании. Тут большой объем работы ложится на тимлида или, за его неимением, на владельца продукта. Самое время задуматься над наймом в команду хорошего тимлида, которому можно доверить такую сложную работу, как сбор и подбор команды. Сбор команды в крупной компании обуславливается множеством факторов, например бюджетом, тебе просто никто не даст собрать команду целиком из Senior-специалистов, потому что это наверняка выйдет за рамки бюджета и придется очень долго доказывать, почему ты выбрал именно такой подход, что с высокой долей вероятности наложит на тебя дополнительные обязательства в виде более быстрого запуска MVP или иных историй. Проблема тут, конечно же, кроется гораздо глубже, как только ты начнешь соприкасаться с кросс-функциональным взаимодействием, выделением или созданием инфраструктуры, то все коммиты тут же начнут быстро уезжать вправо и возникнет негатив как по отношению к тебе, так и по отношению к команде в целом – никто не любит нарушенных обещаний. Самый правильный вариант тут собирать команду из специалистов разного уровня. Например, если в продукте предполагается один продуктовый дизайнер, то, конечно же, лучше искать скилованного специалиста, а если количество разработчиков планируется около трех-пяти человек, то лучше набирать специалистов разного уровня, но всегда помнить о потенциале роста внутренних сотрудников и создании атмосферы как в команде, так и вовне ее, способствующей этому развитию.


– — – — – — – — – — – — – — – — – — – —