Как быстро и эффективно масштабировать команду в 2 раза с помощью джунов

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

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

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

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

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

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

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

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

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

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

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

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

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

Рекомендации по интервью

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

Здесь возникло несколько новых решений:

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

Опросник для эйчара может состоять из:

1. Основные понятия в тестировании.
2. Инструменты, с которыми знаком соискатель.
3. Какова мотивация работать конкретно с этим проектом и компанией.
4. Задание на написание тест-кейса — поиска багов по картинке.

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

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

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

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

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

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

Инструкции

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

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

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

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

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

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

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

Лекции

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

Нейминг

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

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

Как джуну попасть в команду и развиваться в профессии

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

Сразу скажу, что «войти в айти» через тестирование — плохая идея. Особенно, если вы хотите стать разработчиком и писать код. Вас может так затянуть в задачи и развитие, что времени на новое обучение не останется. Лучше сразу выучить язык и пойти на джуна-разработчика.

Как устроиться в компанию

Если коротко — ломиться во все двери, даже если они закрыты.

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

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

Как выделить свое резюме

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

Что джуну делать, чтобы развиваться

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

Девиз джуна: «Глупых вопросов нет. Я глупый — объясняйте, стану умным».

Результаты

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

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

1. Устранили BUS-фактор: написали более 40 инструкций, поместили в Confluence и расшарили среди команд. Джуны и миддлы меньше дергают старших товарищей, вся документация у них под рукой.
2. Так как у нас появились внутренние лекции и матрица компетенций, 30% сотрудников выбрали направление, куда будут развиваться дальше: одни решили пойти в сторону Scrum, другие поняли, что хотят лидировать направление, а часть выбрали автотестирование.
3. Эйчар теперь отлично понимает, кто нам нужен, пользуется опросником, матрицей. Раньше мы получали 30 резюме и из них отбирали 10-15. Сейчас 8 из 10 соискателей мы переводим на следующий этап собеседования.
4. В конце года ушло четыре сотрудника из тестирования: двое стали продактами и открыли два новых направления, один ушел в аналитику, другого вырастили в разработчика, двое теперь лиды команды разработки, и еще один человек — тимлид QA. Главное, на что мы не рассчитывали: люди из смежных отделов — эйчар, аналитика — сказали, что хотят работать с нами.