Делегировать, искать подход и шутить: 11 правил жизни руководителя QA-отдела
Макс Осадчий рассказывает, как за два с половиной года вырос из QA-инженера в руководителя отдела тестирования red_mad_robot, расширил его с четырёх до двадцати человек, и делится уроками, которые усвоил за это время. Будет полезно тем, кто управляет командами или планирует это делать.
Я пришёл в red_mad_robot почти четыре года назад на роль QA-инженера уровня мидл. Два года вёл проекты и рассчитывал, что ещё через пару лет буду готов стать руководителем. Не факт, что я получил бы эту должность. Но обсуждал перспективы с ментором и готовился. В итоге всё случилось неожиданно и гораздо раньше.
Три года назад, во время пандемии, возникла необходимость перестроить отдел полностью. С нуля. Это произошло потому, что часть людей уволилась, часть — ушла в другой проект, и в отделе осталось всего четыре человека, не считая меня. Сейчас их два десятка.
Какие этапы мы прошли и чему я научился за это время — расскажу в статье.
2020: нанимаем костяк команды
Когда я говорю «собрать команду с нуля», я не преувеличиваю. Для меня это был первый опыт и в управлении людьми, и в таком масштабном найме. На него мы, кстати, тратили очень много ресурсов.
В течение полугода каждый день было по два-три собеседования, и я присутствовал на каждом. Я понимал, что если сейчас поспешу с выбором людей и лишний раз не проконтролирую, подходит нам человек или нет, то это может сильно аукнуться в будущем.
Конечно, самое важное и сложное — построить core-команду. Это компетентные и мотивированные люди, готовые участвовать в жизни отдела. Нужно было быстро понять, кого именно я ищу, а потом соединить их так, чтобы они эффективно работали вместе.
При этом я не делал ставку только на опытных специалистов. Нанимал и джунов. Например, Ксюша Сергеева до работы у нас не имела большого опыта непосредственно в QA. Но на собеседовании я увидел, что она организованный, осознанный и зрелый человек, и быстро понял, что мы друг другу подойдём.
Так что я брал и до сих пор беру себе в отдел в большей степени таких людей. Если человек адекватный, на одной волне с командой, у нас общий культурный код и понимание базовых ценностей, обучить его можно чему угодно.
Из той команды, которую я начал нанимать с самого начала, почти никто не ушёл. Одна девушка переехала в другую страну после стажировки, но все остальные работают. Для меня это показатель того, что я выбрал правильную стратегию найма.
Я не стал бы нанимать сеньоров и мидлов только потому, что они хорошие люди с развитыми софт скиллами. Поэтому, конечно, мы смотрим и на хард скиллы. Но базово для меня важно другое. Какой бы рок-звездой в технических качествах ни был человек, если я видел, что нет контакта в коммуникации и мы не сможем договориться, — то нет, точно нет.
За первый месяц наняли 3–4 человек, до конца года — ещё двоих. Так нас стало десять.
Сначала было психологически тяжело. Но важно верить в себя, это всегда актуальный совет. И не бояться: даже если не получится в первый раз, получится во второй. Или в третий. Или в четвёртый. Ну вы поняли.
2021: как готовились и провели Робопрактику
В середине 2021 года у нас появился крутой HR-партнёр Лена Быкова. Она участвовала в выстраивании менторства в отделе, а сейчас онбордит новых ребят и помогает с любыми вопросами, которые касаются кадров.
Наши ребята уже не раз рассказывали о том, как проводили у себя Робопрактики. Вот, например, статья от менеджеров проектов, а вот — от frontend-разработчиков. Бизнес-аналитик Катя Елисеева даже подготовила гайд по тому, как организовать у себя в компании такое мероприятие.
Летом 2021 года мы решили провести свою Робопрактику. Целей у неё было три:
- закрыть потребность в найме,
- получить опыт по организации большого мероприятия,
- пропиарить отдел, который уже требовал чего-то более масштабного.
Планы были масштабными: десять полноценных двухчасовых лекций по две штуки в неделю с заданиями на закрепление, двадцать участников, у каждого — ментор. Нужно было подготовить материалы лекций, презентации, сами выступления. Ребята горели идеей: хотели поделиться знаниями и попробовать себя в роли спикеров. Мы помогали друг другу: проверяли, подстраховывали, прогоняли каждую лекцию заранее.
В программе было самое важное из теории и максимум практики. Включили в неё особенности тестирования веба и мобайла, вопросы клиент-серверной архитектуры, протоколы передачи данных, API, снифферы, снятие логов, производственный процесс, софты и харды.
Подготовились за 2–3 месяца и в декабре запустились. После анонса получили 400+ заявок на участие. Из них я лично отобрал двадцать человек, которых потом мы пригласили участвовать.
По результатам Робопрактики, как и хотели, пригласили троих человек на работу в компанию. Двое до сих пор работают. Сгенерировали много материала, который используем и сейчас, когда вгружаем новых роботов и выступаем на внешних мероприятиях. И, конечно, получили очень крутой опыт и отзывы.
На этапе анкетирования пришлось вспомнить всю теорию и примеры из рабочей жизни, чтобы достойно аргументировать свою позицию. И меня пригласили на Робопрактику. В офисе нас встретили с такими добротой и вниманием, что создавалось впечатление, будто это какой-то другой мир. На следующей неделе приступили к занятиям, и организация была на высоте. Нам показали, как пользоваться сервисом, который, как выяснилось, ребята своими руками собрали персонально для участников. В постоянной атмосфере драйва нам в разных форматах подавали исключительно полезный и интересный материал — графики, таблицы, видеоролики. Теорию всегда подкрепляли реальными примерами и делали упор на практику, были готовы прийти на помощь. Очень рада, что меня пригласили на собеседование — я прошла его и получила заветный оффер. Первые несколько месяцев мы часто ходили по офису дружной командой, вместе осваивали новые инструменты, помогали друг другу и держались рядом. Робопрактика сближает!
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. Не душнить, а шутить
Для меня самый верный показатель хорошей атмосферы в отделе — это чат с мемами. И это не шутка. Когда я пришёл в компанию, уже был общий чатик, а в команде была классная атмосфера, высокая вовлечённость и хорошие отношения. Все были на одной волне. И этот чат не замолкал круглосуточно.
Потом случились структурные изменения, кто-то уволился, началась пандемия, ситуация в целом была накалённая — и всё замерло.
Когда люди шутят, общаются, коммуницируют — всё в отделе хорошо. Для меня это самый чёткий индикатор. Если этого нет, нужно бить тревогу и что-то делать. Мне удалось запустить эту активность: чат ожил и потеплел. И спустя полтора-два года я всё ещё обращаю внимание на это — ребята очень много общаются и шутят. Это очень важно.
Вывод
Когда строишь команду, важно иметь чёткое понимание, кого ты хочешь в ней видеть. Какие у каждого человека должны быть базовые ценности, насколько он адекватен, совпадает ли с культурным кодом компании. Ты строишь команду так, как видишь, и опираться можешь только на себя. Естественно, всегда есть риски. Я вообще не был уверен на 100%, что у меня всё сложится. Не рискнув, я бы этого не узнал.
Так что главное правило — токсичность исключаем, человечность оставляем. Конечно, без хард скиллов никуда. Но их можно прокачать. А человечность не прокачаешь. Мне кажется, всё основывается на ней.
А ещё, разумеется, важно общение с ребятами. Они должны понимать, что они нужны и важны. К любому человеку можно найти подход — и тогда всё будет хорошо.
Кстати, у нас открыта вакансия QA-инженера (manual).
Над материалом работали:
- текст — Макс Осадчий, Ника Черникова,
- редактура — Виталик Балашов,
- иллюстрации — Рома Борцов.
Чтобы ничего не пропустить, следи за развитием цифры вместе с нами:
Да пребудет с тобой сила роботов! 🤖
Лучшее, что читал на VC за последнее время)
"Лучше сделаю сам" — главная проблема начинающих руководителей. Кажется, что все вокруг немного тупенькие и как нужно точно не сделают). Проблема решается с помощью софта для делегирования. Вы используете такой?
Привет, это Макс! Для делегирования не использую никакой софт. На общих командных (проектных) встречах ставлю задачи, обсуждаем саму задачу, сроки, критерии.
Если говорить про задачи отдела, то это или в рамках встречи, либо в чате. Плюс, часто через сore-команду делегирую задачи на остальных ребят в отделе. Тут хорошо работает наша система менторства.
А ЭДО как организовали? Контролируйте задачи и принимаете отчеты в тг только?
Как-то слишком идеально, не может быть такого на практике
Привет, это Макс! В статье я говорю о правилах, к которым, я считаю, нужно стремиться. Естественно, бывают проблемы, «пожары» и недопонимания. Бывают сложные релизы и переработки. Но это не значит, что мы не должны стремиться к лечению этих возникающих проблем.