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

Макс Осадчий рассказывает, как за два с половиной года вырос из QA-инженера в руководителя отдела тестирования red_mad_robot, расширил его с четырёх до двадцати человек, и делится уроками, которые усвоил за это время. Будет полезно тем, кто управляет командами или планирует это делать.

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

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

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

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

2020: нанимаем костяк команды

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

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

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

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

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

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

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

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

Сначала было психологически тяжело. Но важно верить в себя, это всегда актуальный совет. И не бояться: даже если не получится в первый раз, получится во второй. Или в третий. Или в четвёртый. Ну вы поняли.

2021: как готовились и провели Робопрактику

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

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

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

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

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

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

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

Все встречи проходили онлайн
Все встречи проходили онлайн

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

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

Лена Киселёва, QA-инженер red_mad_robot

2022–2023: от стабилизации к развитию

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

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

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

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

Как управлять командой: мой опыт

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

1. Не упарываться, а делегировать

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

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

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

Нужно доверять людям и делегировать. Контролировать статусы, где-то помогать, подключаться — да. Но ни в коем случае не упарываться и не делать всё самому.

2. Не ругаться, а искать решение

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

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

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

3. Не терпеть, а расставаться

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

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

Руководитель должен уметь увольнять.

4. Слышать потребности людей и грамотно планировать ресурс

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

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

Довольно очевидно, но людей действительно важно слушать и слышать. Как ты к человеку относишься, так он и будет относиться к тебе.

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

5. Не контролировать, а снимать статус

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

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

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

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

6. Подходить к каждому индивидуально

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

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

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

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

7. Не паниковать, а транслировать спокойствие

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

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

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

8. Не выжимать людей, а держать баланс

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

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

Если говоришь команде: «Ребята, не перерабатывайте», желательно не перерабатывать самому. От людей не скроешь, если ты с ними нечестен. Поначалу мне это часто возвращали — сам я в то время не следовал своим же советам.

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

9. Менторить и обучать

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

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

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

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

10. Поощрять развитие личного бренда

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

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

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

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

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

11. Не душнить, а шутить

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

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

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

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

Вывод

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

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

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

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

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

  • текст — Макс Осадчий, Ника Черникова,
  • редактура — Виталик Балашов,
  • иллюстрации — Рома Борцов.

Чтобы ничего не пропустить, следи за развитием цифры вместе с нами:

Да пребудет с тобой сила роботов! 🤖

11
5 комментариев

Лучшее, что читал на VC за последнее время)
"Лучше сделаю сам" — главная проблема начинающих руководителей. Кажется, что все вокруг немного тупенькие и как нужно точно не сделают). Проблема решается с помощью софта для делегирования. Вы используете такой?

2
Ответить

Привет, это Макс! Для делегирования не использую никакой софт. На общих командных (проектных) встречах ставлю задачи, обсуждаем саму задачу, сроки, критерии.

Если говорить про задачи отдела, то это или в рамках встречи, либо в чате. Плюс, часто через сore-команду делегирую задачи на остальных ребят в отделе. Тут хорошо работает наша система менторства.

1
Ответить

Как-то слишком идеально, не может быть такого на практике

Ответить

Привет, это Макс! В статье я говорю о правилах, к которым, я считаю, нужно стремиться. Естественно, бывают проблемы, «пожары» и недопонимания. Бывают сложные релизы и переработки. Но это не значит, что мы не должны стремиться к лечению этих возникающих проблем.

1
Ответить