Делегировать, искать подход и шутить: 11 правил жизни руководителя QA-отдела

Я пришёл в red_mad_robot почти четыре года назад на роль QA-инженера уровня мидл. Два года вёл проекты и рассчитывал, что ещё через пару лет буду готов стать руководителем. Не факт, что я получил бы эту должность. Но обсуждал перспективы с ментором и готовился. В итоге всё случилось неожиданно и гораздо раньше.

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

Какие этапы мы прошли и чему я научился за это время — расскажу в статье.

Когда я говорю «собрать команду с нуля», я не преувеличиваю. Для меня это был первый опыт и в управлении людьми, и в таком масштабном найме. На него мы, кстати, тратили очень много ресурсов.

Конечно, самое важное и сложное — построить core-команду. Это компетентные и мотивированные люди, готовые участвовать в жизни отдела. Нужно было быстро понять, кого именно я ищу, а потом соединить их так, чтобы они эффективно работали вместе.

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

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

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

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

За первый месяц наняли 3–4 человек, до конца года — ещё двоих. Так нас стало десять.

В середине 2021 года у нас появился крутой HR-партнёр Лена Быкова. Она участвовала в выстраивании менторства в отделе, а сейчас онбордит новых ребят и помогает с любыми вопросами, которые касаются кадров.

Наши ребята уже не раз рассказывали о том, как проводили у себя Робопрактики. Вот, например, статья от менеджеров проектов, а вот — от frontend-разработчиков. Бизнес-аналитик Катя Елисеева даже подготовила гайд по тому, как организовать у себя в компании такое мероприятие.

Летом 2021 года мы решили провести свою Робопрактику. Целей у неё было три:

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

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

Подготовились за 2–3 месяца и в декабре запустились. После анонса получили 400+ заявок на участие. Из них я лично отобрал двадцать человек, которых потом мы пригласили участвовать.

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

К началу 2022 года в отделе было 13–15 человек. После Робопрактики мы провели ретро и сгенерировали подробный план того, что теперь нужно делать: прокачивать PR, вводить новую автоматизацию тестирования, участвовать в мероприятиях. То есть именно то, что развивает отдел.

Летом мы провели первый после пандемии бесплатный офлайн-митап в новом офисе. Спикерами были сеньоры: позвали Лену Садовскую из «Яндекса» и Артёма Бадышева из «Альфа-банка», а от red_mad_robot выступила Оля Никитина.

Мы рассчитывали на 70 слушателей, но заявок получили в два раза больше. Зал был набит под завязку, ещё 150 человек присутствовали онлайн.

Сейчас мы планомерно развиваем отдел, делаем проекты и участвуем в PR-активностях. Прокачиваем ребят по разным направлениям: нагрузка, автотесты, базовое тестирование безопасности. Постоянно изучаем что-то новое, делимся этим на технологизациях и митапах, иногда проводим лекции в университетах. На сетапе помощь в развитии QA-команды в red_mad_robot Central Asia.

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

В какой-то момент я одновременно вёл один проект, запускал второй, достраивал отдел, активно нанимал людей и выстраивал систему менторинга. Работать в таком темпе было ошибкой. Никому не советую так делать. Это было тяжело физически и морально, к концу года я почти выгорел.

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

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

Я неконфликтный человек, не любитель применять какие-то «санкции». Считаю, что это абсолютно неуместно: мы все взрослые люди и можем договориться. Если человек что-то делает не так в моём понимании, то на это есть причины. И стоит поискать их вместе.

Например, если человек не выпускает сборку вовремя, пропускает баги или как-то странно себя ведёт, то, вероятно, у него есть проблемы вне работы. И нужно с ним поговорить, попытаться встать на его сторону, понять. Он поможет тебе разобраться, если ты будешь вести себя нормально, не станешь нагнетать и манипулировать. Если участник команды понимает, что лид на одной с ним стороне, а не просто требует результата, он сделает всё возможное, чтобы решить задачу.

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

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

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

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

Самое сложное — всё между собой мэтчить. Потому что, к сожалению, всем угодить невозможно. Нужно договариваться, но всё равно стараться всегда давать людям возможность развиваться в том, что им интересно.

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

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

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

People management — это важный скилл для руководителя. Я бы даже сказал, сродни таланту, который можно развить. Встречи один на один — абсолютно неотъемлемая часть становления команды, если, конечно, руководителю не безразличны люди.

Когда в команде было десять человек, я мог встречаться с каждым чуть ли не еженедельно. Расспрашивал, узнавал, всё ли хорошо. Это не о контроле, а о том, чтобы держать руку на пульсе: знать, что человек себя хорошо чувствует, всё нормально — это здорово помогает. Когда в команде уже двадцать человек, это невозможно делать часто. Всё равно нужно делать регулярно, просто реже.

Кому-то это нужно в большей степени, кому-то — в меньшей. И это тоже нормально, не нужно заставлять. Достаточно время от времени ненасильственно снимать статус.

Прошлый год для всех был сложным и повлиял на общее состояние — не только на команду QA, но и на всю компанию. Быть руководителем в такое время — двойная ответственность, потому что команде важно транслировать спокойствие. Это правило работает для любой стрессовой ситуации — будь то обстановка в мире или проблема на клиентском проекте.

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

Достаточно отдыхать — так же важно, как и хорошо работать. Нормальный work-life balance приводит к лучшим рабочим результатам, чем работа по 14 часов в день. Переработки ведут к выгоранию, срыву сроков, плохому качеству проекта и увольнениям. А когда человек нормально отдыхает, то в хорошем настроении просыпается и думает, как сделать работу ещё круче.

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

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

В red_mad_robot выстроена система менторства: старший сотрудник регулярно встречается с младшим и делится опытом, советует полезные материалы, помогает двигаться по индивидуальной траектории развития. Это доверие к людям очень многого стоит. Поэтому у нас другие механизмы, за счёт которых мы привлекаем и развиваем людей. Кажется, сам я нигде в России или СНГ так быстро не прокачался бы, как сделал это в Роботах.

Когда не хватает времени на встречи one-to-one, я как руководитель получаю информацию о команде через менторов и, если нужно, реагирую. Раньше у нас была проблема с нехваткой лидов, которые руководят QA-инженерами на проектах. Мы долго пытались нанимать их на рынке, но при мне — почти безуспешно. Теперь, благодаря системе менторства, у нас очень круто получается выращивать из джунов мидлов, а из мидлов — тимлидов проектов. Мы знаем, что делать, какие инструменты изучать, какие прокачивать софты, — и люди быстро растут. Поэтому сейчас мы даже не особо зависим от рынка.

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

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

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

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

Если темы на проработку нет, то мы садимся и начинаем штормить. Вот, например, недавно Маша Кузнецова написала материал о том, как жить QA-инженеру в условиях проблемной документации. Не в каждой компании есть возможность взять и опубликоваться на «Хабре» — я считаю, что это очень круто.

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

Потом случились структурные изменения, кто-то уволился, началась пандемия, ситуация в целом была накалённая — и всё замерло.

Когда строишь команду, важно иметь чёткое понимание, кого ты хочешь в ней видеть. Какие у каждого человека должны быть базовые ценности, насколько он адекватен, совпадает ли с культурным кодом компании. Ты строишь команду так, как видишь, и опираться можешь только на себя. Естественно, всегда есть риски. Я вообще не был уверен на 100%, что у меня всё сложится. Не рискнув, я бы этого не узнал.

А ещё, разумеется, важно общение с ребятами. Они должны понимать, что они нужны и важны. К любому человеку можно найти подход — и тогда всё будет хорошо.

Кстати, у нас открыта вакансия QA-инженера (manual).

Над материалом работали: