Home

Часть 1. Найм и развитие

Всем привет. Меня зовут Александр Наумов, я Team Lead QA в Утконос Онлайн. В этой статье я поделюсь личным опытом, который будет полезен тимлидам и руководителям: как мы за 5 месяцев набрали 28 начинающих специалистов, обучили и через 3 месяца получили миддлов. 

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

Когда задач становится слишком много 

В конце 2020, спустя почти год пандемии, планов и задач в Утконос Онлайн стало кратно больше — за 2021 компания хотела запустить много новых функций. Отделом QA мы оценили бэклог и поняли, что на это уйдет никак не меньше пары лет. Тогда у нас было три команды:
а) команда разработки мобильного приложения;
б) каталога и поиска;
в) корзины;
г) мобильного приложения.

В каждой — один проджект менеджер, три фронтенда, трое бекэндеров и два QA спеца. 

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

Анализ рынка

Когда вы ищете новых сотрудников, особенно в ИТ-сфере, важно понимать, что происходит на рынке в это время. В начале 2021 ситуация была следующей:

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

• Миддлы и сеньоры поняли, что нужно поднимать цены, и в конце года произошел скачок в зарплатах. 

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

Составление требований и этапы найма

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

Наш джун — это специалист, который хорошо изучил теорию, умеет пользоваться DevTools, писать простые SQL запросы. У него отлично развиты логическое мышление и скилл коммуникации.

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

Миддл прекрасно пишет тестовую документацию, может спокойно дополнять документацию по проекту, знает REST API, SQL, понимает GitFlow. 

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

Тимлид проводит аудит процессов тестирования в компании, формирует требования к документации, принимает решения по релизу проекта, является ментором для миддлов и сеньоров.

HR- процессы

Следующим вызовом для нас стала оптимизация процессов. Когда интервью много — а у нас их было более 128 за месяц —  HR начинает выгорать. Мы поняли, что это нам в первую очередь важно получить классных ребят в команду, поэтому решили принять участие и помочь с наймом.

Во-первых, HR вряд ли сможет увидеть резюме тех. специалиста так, как его видит TeamLead. На что он обычно обращает внимание: 

• ключевые слова (стек, должность);

• время работы;

• сколько работает на текущем месте;

• как часто меняет работу;

• как составлено резюме;

• раздел «о себе».

Я же обычно смотрю на:

• название используемых инструментов;

• обязанности на текущем месте работы;

• опыт (сколько работает в данной профессии — если это джун, то в принципе на опыт работы);

• как я могу использовать человека на проекте, какие задачи прямо сейчас отдать.

Мы расширили каналы поиска — помимо hh искали в профильных чатах и по знакомым. Провели лекцию о тестировании для HR. Создали опрос — памятку для HR, и тестовое задание, которое отсеивает людей на первом этапе.

Опросник для HR может состоять содержать следующие пункты:

1. Основные понятия в тестировании.

2. Инструменты, с которыми знаком соискатель. 

3. Какова мотивация работать конкретно с этим проектом и компанией.

4. Задание на написание тест-кейса — поиска багов по картинке.

Обычно собеседования у нас проходят в 3 этапа:

• HR знакомится с соискателем, дает опросник, выясняет заинтересованность в вакансии. 

• Техническое собеседование. Могут присутствовать тимлид и сеньор, который будет менторить джуна. На этом этапе нужно выяснить хард скилы. Например, мы спрашивали, что такое теория тестирования, API, Git, для чего это нужно, работал он с этим или нет. Немаловажно, как человек общается, легко ли обучаем. Также можно спросить о дальнейшем развитии — понимает ли человек, куда хочет расти.

• Третий этап — знакомство с командой. Иногда из-за различий в темпераменте людям некомфортно общаться и вместе вести проект. Если это выясняется на этапе знакомства, и у вас есть место в другой команде, можно познакомить человека со второй/ третьей и т.д.

Результаты оптимизации 

Ровно неделя ушла, чтобы создать единую систему оценки соискателя по его знаниям. Также у меня появился план собеседования — когда в день их 5 штук, а устаешь уже после второго, то хорошо при себе иметь такую шапраглку. С планом оказалось, что собеседовать может не только TeamLead, но и Senior, поэтому со временем я передал эту задачу своим коллегам. 

В итоге, мы кратно улучшими воронку найма: если раньше отсеивалось 70% соискателей, то теперь 80% резюме подходило под наши требования. Так что HR начали поставлять тестировщиков как по конвейеру) Нужно было что-то делать с ними дальше — мы же взяли джунов и расчитывали быстро их вырастить до миддлов. 

Что мы делали на этом этапе, и какими инструментами пользовались — расскажу во второй части статьи. 

Часть 2. Документация и карты компетенций

Всем привет! На связи Александр Наумов, TeamLead QA Утконос Онлайн. В первой части моего рассказа о том, как мы масштабировали команду в 2 раза с помощью джунов (и не умерли при этом), я поделился, как мы проанализировали рынок, составили требования к соискателям, оптимизировали HR-процессы и улучшили воронку найма на 50%. В этой части затронем темы BUS-фактора, разработки единой документации для команд и инструментов развития джунов.

Устраняем BUS-фактор. Разработка единых процессов для всех команд

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

Описание стендов

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

Инструкции

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

Документация

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

Страница джуна

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

Нейминг 

В команде все должны использовать термины в одинаковом значении. Может, для кого-то GitLab — это место для тапочек)

Однажды я с джуном пришел на скрам. Проскочила фраза от разработчика: «Хотфикс сделал, мерж создал, жду апрувов». На что я ответил: «Хорошо, как задеплою, посмотри алерты, я обстреляю стенд по плану». Надо было видеть выражение лица джуна. В итоге, хорошей идеей оказалось составить словарь. Через две недели джунам стало проще — они быстро начали общаться на том же языке. Так что подумайте о создании своего словаря.

Развиваем сотрудников

Самые важные вещи, которые нужны, чтобы растить джуниора — это компетентный ментор, постоянное обучение и реальные цели на испытательный срок.

Обучение 

Ментор хорошо знает проект, процессы в команде и компании, у него классные навыки коммуникации, он умеет объяснять. Его роль — обучить, показать часто используемые инструменты, помочь с выполнением задач, познакомить с коллегами. После обучения новый специалист должен понимать статус задачи, что с ней происходит, когда с ней работать, а когда она находится на стороне разработки.

Опытным путем мы поняли, что один специалист — это 50% времени ментора. Поэтому в одного человека нельзя впихнуть больше двух джунов. При этом не стоит ждать, что ментор будет выполнять задачи — этим будут заниматься его джуны. 

Цели на испытательный срок

Цели вытекают из требуемых навыков, которые вы составляете на этапе найма. Целями вы подтягиваете джунов до желаемого уровня. Например, если вам важно умение вести тестовую документацию, писать простые SQL-запросы, логическое мышление, владение Charles и DevTools, то на 3 первых месяца задачами могут стать: овладеть инструментом Charles — подменять данные, перенаправлять потоки, писать SQL-запросы в Select, Join, выкатывать задачи в продуктив через Hotfix, актуализировать тест-кейсы команды.

Матрица компетенций

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

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

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

Лекции

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

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

Результаты

В качестве итога статьи поделюсь результатами оптимизации нашей работы.

1. Мы наняли 28 специалистов, часть которых по завершению испытательного срока выросли до миддлов. 

2. Устранили BUS-фактор: написали более 40 инструкций, поместили в Confluence и расшарили среди команд. Джуны и миддлы меньше дергают старших товарищей, вся документация у них под рукой.

3. Так как у нас появились внутренние лекции и матрица компетенций, 30% сотрудников выбрали направление, куда будут развиваться дальше: одни решили пойти в сторону Scrum, другие поняли, что хотят лидировать направление, а часть выбрали автотестирование.

4. HR теперь отлично понимает, кто нам нужен, пользуется опросником, матрицей. Раньше мы получали 30 резюме и из них отбирали 10-15. Сейчас 8 из 10 соискателей мы переводим на следующий этап собеседования.

5. В конце года ушло 4-е сотрудника из тестирования: 

1. 2-е стали продактами и открыли два новых направления

2. 1 ушел в аналитику, 1-го вырастили в разработчика

3. 2-е теперь лиды команды разработки, и еще один человек — тимлид QA