Найм Entry Level/Junior QA: за и против

    Прямо сейчас в OTUS открыт набор на новый поток курса "QA Lead". В связи с этим Анастасия Шарикова - преподаватель курса поделилась с нами своей авторской статьёй. Передаём слово Анастасии:


    Всем привет! Меня зовут Анастасия Шарикова, я руковожу отделом тестирования в Bookmate и веду телеграм канал Yet another QA

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

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

    Помимо этого, сразу хочу оговорить, что сегодня мы не будем касаться философских тем в духе “все должны брать джунов/все не должны/а кто вообще такие джуны и что же стало с уютным миром IT”, а пройдемся именно по основным потенциальным плюсам, минусам и рекомендациям.

    Кого мы рассматриваем как начинающих? Это и Entry Level, то есть те, кто вообще не имеет коммерческого опыта, и Junior QA.

    Плюсы

    Итак, начнем мы с позитивной стороны: что же мы потенциально можем получить для своего отдела или команды в долгосрочной и краткосрочной перспективе, если начнем нанимать совсем зеленых специалистов? 

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

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

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

    • Мотивация и вовлеченность: вспоминаем про модель мотивации “Хочу/Могу” и понимаем, что большинство молодых специалистов (конечно, если мы не налажали при найме) относятся к категории “хочу, но не могу” и мотивированы на активное участие в работе и развитие просто потому что они смогли устроиться на работу. 

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

    • Вы можете словить настоящий талант: и я совершенно серьезно. Среди сотни соискателей без опыта, которые прочитали Савина и/или закончили курсы встречаются, как я их называю, прирожденные QA, которые находят и документируют баги или пишут тест-кейсы лучше, чем многие специалисты с 3+ лет опыта. Хорошо составленное тестовое задание - наше все в этом случае. И если уж вы нашли такой неограненный алмаз, то при должном усилии вы сможете получить в скором времени преданного крутого сотрудника.

    • Лояльность:  несмотря на то, что существует стандартное опасение, что "мол, мы вложим деньги и силы, а человек просто уйдет", можно провернуть и обратное - вырастить крайне лояльного сотрудника, который оценит, что вы ему “помогли”. Но, конечно, такое бывает не так часто, как хотелось бы.

    • Использование внешнего бекграунда: если вы разрабатываете,допустим, сервис для медицинских работников, то идеальным кандидатом для вас может оказаться не middle/senior, а entry level/junior, который решил поменять профессию, и ушел как раз из нужной вам сферы. Он или она смогут принести вам крайне актуальную экспертизу и взгляд того, кто был погружен в тему.

    • “Релокация” из смежных отделов: ну и напоследок очень популярный и потенциально полезный вариант. Попробуйте искать к себе специалистов “изнутри” - из сотрудника вашего же саппорта может выйти прекрасный тестировщик, которому к тому же не придется вникать в продукт и его особенности.

    Минусы

    И, конечно же, надо рассмотреть часто встречающиеся сложности, связанные с наймом Entry Level/Junior QA:

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

    • Контроль: если на опытного сотрудника довольно скоро после найма можно будет делегировать задачи и доверять самостоятельную работу, с новичками такое провернуть сложнее. Да и 1:1 и подобные встречи придется проводить чаще - стоит ли оно того?

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

    • Testing vs QA: если вам нужно просто протыкать регресс, то проблемы не будет, а вот если в задачи входит не только проверка по ТЗ, но и более глубокое понимание процессов, возможностей к улучшению на всех этапах и подобное, то мягко говоря не каждый начинающий специалист сможет помочь вам с таким. Даже если на курсах его учили основам QA, то опыт тут все равно будет играть важную роль. И уверенность в себе, кстати, тоже.

    • Риск нестабильности: самый популярный довод против, конечно же, не безоснователен - риск того, что вы вложите все в новичка, а он уйдет туда, где трава зеленее, огромный, особенно если вы не “компания мечты”, куда все стремятся. С этим можно работать, но и оценивать риски тоже надо.

    • Завышенные ожидания: боль всех нанимателей (простите, дорогие джуны, если вы читаете этот текст) - если раньше новички были готовы работать за еду за небольшие деньги, то теперь каждый второй, кто закончил любые курсы сразу просит от 60 тысяч в Москве и от 100 через год опыта, даже если не умеет открывать DevTools и не знает, чем тест-кейс отличается от чеклиста. При этом всем, как ни парадоксально, все чаще заинтересованность начинающих QA в саморазвитии без наставничества сверху крайне низка, а требовательность к работодателю все растет и растет. И я, конечно же, не про базовые гигиенические факторы.

    Что делать, если вы все же решились:

    • Разберите бардак на проекте: knowlege managment на базовом уровне полезен даже если у вас нет постоянного найма новых сотрудников, а уж когда надо вводить в курс дела новичков, то он вам точно пригодится. Ну и конечно же стоит наконец завязать с ТЗ по телефону, баг-репортами по переписке, тикетами на бумажках и прочими подобными практиками.

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

    • Признайтесь себе честно, насколько сложные у вас задачи: правда ли вам вообще нужны джуны? Может быть вам стоит попробовать выбить больше денег на ставку Middle QA, а не пытаться затыкать дыры теми, кто просто не справится?

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

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

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


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

    OTUS. Онлайн-образование
    Цифровые навыки от ведущих экспертов

    Комментарии 1

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

      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

      Самое читаемое