Home

Автор статьи: Глеб Саркисов (Gleb Sarkisov)

Преодоление кризисов в качестве лидера команды: первый год в роли Head of QA

Всем привет, я Глеб.

За 7 лет работы в QA я успел попробовать разные роли:

– тестировщик в стартапе;

– тест-лид в агентстве и корпорации;

– и вот недавно прошел год, как я работаю хедом QA в Mayflower.

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

Про страхи

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

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

1. Люди

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

2. Переход в новую роль

В Mayflower роль Head of QA — это всего минус один от c-level в структуре организации. Ранее напрямую с такими серьёзными ребятами мне работать не приходилось. Поэтому внутренний мандраж первое время, конечно, присутствовал. Как выглядит работа с c-level? Есть ли какие-то общепринятые правила, которых я пока не знаю? Справлюсь ли я с этим форматом?

3. Экспертиза

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

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

Люди

Опыта управления такой большой командой у меня ещё не было, поэтому, естественно, я боялся оказаться для них плохим лидером. К сожалению, Википедия не дает определения понятия «плохой лидер», поэтому я поделюсь своим, кем я точно НЕ хотел стать для своей команды.

Плохой лидер:

– не умеет в баланс между ответственностью и доверием, например, может полностью утаскивать на себя принятие решений, не обсуждая и не делегируя лидам, инженерам, или, наоборот, скидывает все проблемы и необходимые изменения своим сотрудникам;

– не выражает поддержку там, где она необходима / заслужена или перехваливает сотрудника;

– не годится для того, чтобы брать с него пример в решении проблем и движении к достижению цели;

– не справляется со своим характером, и из-за этого кто-то огребает;

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

Портрет антилидера у меня был, так что же я сделал, чтобы в него не превратиться?

Конечно, сначала я знакомился с ребятами на личных встречах и разбирался в общем процессе их работы. Здесь стоит отметить, что все 27 инженеров группами по два-три человека вгружены в отдельные полностью укомплектованные продуктовые команды (со своим проджектом, продактом, аналитиком, разработчиками и тд). Мне пришлось использовать разные подходы к абсолютно разным людям, которых было много. Кроме того, они работают в разных командах, в каждой из которых существует своя атмосфера и специфика. Я понимал, что путь к нахождению общих точек соприкосновения и доверию лежит через решение кризисных ситуаций:

— острых ситуаций отдельных ребят;
— сложных кейсов по процессам работы отдела.

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

«Капитанский» рецепт выхода из кризиса, по которому я пытаюсь идти каждый раз:

1. Анализ проблемы и подсвечивание ключевых точек напряжения, которые и являются источником проблемы.
2. Транслирование всем задействованным лицам, кто и что сделал неправильно. Идеально, чтобы каждый четко понимал свою роль, ответственность и результат в данной проблеме, ситуации или процессе.
3. Обозначение и фиксирование ожиданий (в виде целей/блока ретро/тд для человека/команды). Должно быть ясно, что, кто и зачем должен выполнить в определенный срок.
4. Договоренность насчет формата синхронизаций с человеком/командой по статусу решения проблемы.
5. Сам процесс мониторинга решения проблемы.
6. Подведение итогов по достижению оговоренного срока для решения проблемы.

Спустя год я вижу, что с большинством у меня выстроились доверительные отношения.

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

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

Чем больше человек в команде, тем сложнее следить за всем происходящим и системное общение с каждым инженером случается не чаще раза в 4–5 месяцев. И всё же, если того требует ситуация, надо делать исключения и видеться чаще.

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

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

Переход в новую роль

Помимо самой софтовой части работы с людьми было тревожно начать работать в прямой связке с c-level.

Вопросы в голове были примерно такие:

• Вдруг я знаю мало, а они много и поэтому их решения будут круче и применимее?
• Будут ли мне давать свободу в принятии решений или придется действовать строго по указке?
• Получится ли выйти на взаимопонимание и доверие в плане принимаемых решений? Смогу ли я достаточно внятно продавать свою позицию по разным вопросам?

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

Мои наблюдения по прошествии года:

1. У менеджмента действительно может быть круче экспертиза по управленческим решениям. И вместо сомнений в себе, куда эффективнее попытаться перенять глобальное мышление, способность видеть общую картину благодаря их рекомендациям, советам, вопросам.
2. Самый большой челлендж на старте — понять, что ты сам определяешь, куда движется отдел тестирования, с какой скоростью и для каких целей.
3. Вас нанимают как раз потому, что нужен хороший менеджер, берущий на себя ответственность за отдел, готовый искать хорошие решения для имеющихся проблем. На старте важно договориться об ожиданиях по уровню свободы в принимаемых решениях. И поэтому надо выстраивать честный диалог с CTO, COO и тд — пусть это может казаться сложным в первое время. Как только появляются первые плоды вашей работы, диалог с c-level сразу становится более комфортным и понятным.

Экспертиза

Третьим элементом, который вызывал вопросы, оказалась моя профессиональная экспертиза и её применимость. Она, в свою очередь, раскладывается на отладку процессов и управление инструментами QA.

Отладка процессов

В плане отладки процессов я переживал, что:

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

Что я в итоге сделал и получилось ли всё пофиксить? Я выстроил коммуникацию со всеми холдерами процесса доставки. Засетапил синки с лидом проджект-менеджеров, QA-техлидами, настроил сбор и анализ метрик (читайте мою другую статью про Плотность дефектов “со звездочкой”). Ввел процесс постмортемов для каждого критического бага на уровне лидов фронта, бэка и QA, и в ближайшее время планирую увести это внутрь команд. На наших постмортем-встречах мы детально обсуждаем криты. Такой процесс позволяет не только быстрее и точнее залатывать открывшиеся дыры в процессах, но и действовать превентивно.

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

Управление инструментарием QA

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

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

1. Успеваем ли мы писать тесты? Каково качество написанных тестов? Есть ли люди, которых надо подтянуть до нужного базового уровня?
2. Насколько текущее решение помогает нам решать поставленные задачи? «Хватает» ли нам выбранного фреймворка?
3. На что из нашего бэклога мы в первую очередь должны тратить ресурс? Какие наши ожидания от полугода-года работы по разгребанию фокусных задач из бэклога?
4. Какие наши ожидания от скорости прохождения тестов? Сколько у нас flaky тестов сейчас и сколько мы хотим, чтобы было?

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

Все, что касается самих инструментов (мобилки для тестирования, отдельное приложение и остальное), артефактов (чеклист, тест-кейс и прочее) — обсуждаем c техлидами и отделом.

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

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

Заключение

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

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

Смелости, терпения и удачи!

Обсудить в форуме