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

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

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

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

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

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