[Управление персоналом, Карьера в IT-индустрии, Тестирование IT-систем] Найм Entry Level/Junior QA: за и против

Ответить на тему

Автор

Сообщение

news_bot ^®

Стаж: 6 лет 9 месяцев
Сообщений: 27286

news_bot ^® написал(а)
01-Окт-2020 21:35

Цитировать

Прямо сейчас в 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, а не пытаться затыкать дыры теми, кто просто не справится?
Отдайте проблемы на аутсорс, если есть возможность: например, вы можете запартнериться с онлайн-университетами и курсами и они смогут сами готовить именно тех, кто вам нужен, еще и отбирать лучших. Или наймите на время адаптации менторов или наставников извне, если у вас нет на это ресурсов изнутри. Делегирование таких задач потенциально может быть крайне выгодным.

Подведем итоги: конечно, выше описаны не абсолютно все плюсы, минусы и решения, да и у каждой компании всегда есть свои особенности найма, но тем не менее, иногда стоит остановиться, изучить ситуацию и задуматься - все ли я, как руководитель, делаю верно? Все же всегда нужно уметь максимально объективно оценить существующую кадровую политику, взвесить минусы и плюсы, оценить здраво фронт задач и их сложность и понять, действительно ли вам нужны только опытные “звезды” или наоборот, пора остановиться в бездумном наборе соискателей без опыта, которые не принесут никакой пользы в перспективе.На этом всё. Приглашаем вас на день открытых дверей, в рамках которого наши преподаватели подробно расскажут о курсе и программе обучения, а также ответят на все интересующие вопросы.
===========
Источник:
habr.com
===========
Похожие новости:

Теги для поиска: #_upravlenie_personalom (Управление персоналом), #_karera_v_itindustrii (Карьера в IT-индустрии), #_testirovanie_itsistem (Тестирование IT-систем), #_najm (найм), #_junior_qa, #_personal (персонал), #_qa_lead, #_blog_kompanii_otus._onlajnobrazovanie (
Блог компании OTUS. Онлайн-образование
), #_upravlenie_personalom (
Управление персоналом
), #_karera_v_itindustrii (
Карьера в IT-индустрии
), #_testirovanie_itsistem (
Тестирование IT-систем
)

Профиль ЛС

Ответить на тему

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы

Текущее время: 22-Ноя 13:09
Часовой пояс: UTC + 5