Как прийти на позицию QA-лида в команду и сделать ее только лучше
Всем привет. Меня зовут Костя Лях, я работаю на позиции Head of QA в одном из управлений T-Банка. За время карьеры успел поучаствовать в запуске проектов в стартапах и корпорациях.
Полтора года назад я принял новый вызов и перешел на позицию лида в сложившуюся команду в Т-Банке. До этого я тоже работал на позиции лида, но большую часть команды собирал самостоятельно, и мне казалось, что алгоритм работы в состоявшемся коллективе будет отличаться. Встал вопрос: как ничего не сломать и сделать только лучше в сформированной команде?
Я расскажу, что помогло мне при работе с командой, какие выводы я сделал, какие ошибки совершил и действительно ли подходы для новой и устоявшейся команды различаются. Статья пригодится руководителям и тем, кто планирует ими стать.
Итак, вы пришли на позицию QA-лида в компанию, как же все не сломать и с чего начать?
Понять ожидания руководства
Перед тем как бросаться в омут с головой, важно понять, чего ждут от вас и команды. Когда я пришел в Т-Банк, я стартовал именно с этого — сформулировал вектор для дальнейшей работы и для этого провел несколько встреч.
По моему опыту, полезно сначала встретиться с руководством, тимлидом или менеджером QA — зависит от организационной структуры. Цель встречи — собрать требования: например, какую скорость и качество работы они ждут, какие проблемы видят в команде, персональные цели для вас.
Следующий шаг — провести встречи с бизнесом, как правило это product owner, и собрать планы по ближайшему развитию продукта, например новые проекты, фичи, рефакторинги и так далее. Такие действия помогут оценить загрузку тестирования и необходимость найма в кратко- и среднесрочном периоде. Еще продакт может подсветить проблемы на стороне тестирования.
Из моего опыта, руководителям не всегда ставят четкие цели, чаще они выглядят так: «Команда QA медленно проходит регресс, нужно быстрее» или «При тестировании пропускают много критических багов в прод, разберись в проблеме». Тогда я сам их формулировал на основе информации, которую уже собрал, и согласовывал с менеджментом. Мне кажется, что именно таких действий и ждут от лида.
Познакомиться с командой и проектом
После того как собрали ожидания руководства, следующий шаг — оценить состояние своей команды, техническое состояние и зрелость проекта: от этого будут зависеть дальнейшие действия. Еще я обращал внимание на проблемы, которые мне подсветили на этапе сбора ожиданий от менеджмента.
Расскажу из своей практики, с кем советую познакомиться и что обсудить для оценки. В разговоре мне помогало то, что я заранее подготовил вопросы для каждого участника команды.
Знакомство с командой тестирования. Здесь стоит проанализировать опыт ребят, сильные и слабые стороны, мотиваторы и демотиваторы — это пригодится для эффективного планирования работы. Например, если у сотрудников нет навыков разбора клиентских обращений с прода, нет смысла давать такие задачи, пока вы их этому не научите. Или если у какого-то члена команды есть опыт в автоматизации и желание развиваться в этом направлении, самое время найти применение этому навыку на проекте. И сотрудник будет доволен, и проекту это принесет пользу.
Помогает собрать «боли» у ребят, чтобы потом проработать их наравне с процессными проблемами.
С командой разработки. Стоит организовать встречи с лидами и собрать информацию о проблемах на стыке разработки и тестирования, например плохо оформленные баг-репорты, медленное тестирование задач и так далее.
Помним, что описанные проблемы не всегда отражают действительность. Например, разработчики могут не описывать затронутый функционал в задачах, из-за чего QA придется выяснять подробности у исполнителя. Хотя фактически задача тестироваться не будет, со стороны это выглядит как проблема тестирования.
С остальными членами команды — дизайнером, аналитиком, сотрудниками поддержки, автоматизаторами и так далее. Цель — понять состояние технических требований к продукту, макетов, автоматизации на проекте, количестве пользовательских обращений. Во время разговоров еще можно узнать о проблемах взаимодействия команд с QA. Возможно, в вашей команде все круто и таких проблем нет — тогда на один повод порадоваться станет больше:)
Еще важно пообщаться со смежными командами QA: здорово поспрашивать о процессах обеспечения качества у других QA-лидов — это хороший способ найти для себя ориентиры.
Проверить наличие и актуальность метрик. Если таковых нет, то собрать метрики по ключевым показателям. Я не буду их расписывать, потому что это тема для отдельной статьи.
На мой взгляд, метрики — это необходимый инструмент для лида, но это не панацея, а дополнительный инструмент для анализа эффективности команды. Пример: на встречах продакт и поддержка подсветили проблему большого количества багов с прода. Можно собрать метрику отношения количества багов с прода к багам с теста или количества критичных дефектов с прода и убедиться, что претензии обоснованы.
Заслужить авторитет
Параллельно со сбором пожеланий и информации о команде начинаем заручаться доверием команды. Речь не только о QA, а в целом про всю команду разработки.
Зачастую QA-лид — это играющий тренер. Чтобы к вам прислушивалась команда, важно зарекомендовать себя не только как сильного менеджера, но и как инженера, который может успешно выполнять задачи, разные по технической сложности. По моему опыту, помогает уже в первый месяц погрузиться в проект в качестве инженера и освоить основные ритуалы в команде — написание тестовой документации, автотестов и так далее.
Мне кажется, что в первое время не стоит брать слишком сложные задачи, но со временем надо глубже окунуться в проект и показать экспертность инженера. Постепенно команда начнет тянуться к такому лиду, а когда есть авторитет в коллективе, намного проще проводить изменения.
Внедрить изменения
На первые три этапа уходит в среднем месяц. К этому времени обычно успеваешь собрать информацию по текущему положению дел и погрузиться в ритуалы команды. Как итог — на руках оказывается список сильных сторон и список проблем.
Следующий шаг — поработать над проблемами: для этого я ранжирую найденные проблемы, добавляю сроки для внедрения изменений, согласовываю план с руководством и начинаю итеративно внедрять исправления. Для работы с приоритетами можно использовать матрицу Эйзенхауэра.
Наверняка будут easy-win-решения, которые дадут явное улучшение в короткие сроки, и я советую начать с таких изменений. К примеру, QA-инженеры тратят много времени на ручную генерацию тестовых данных, из-за чего скорость работы тестирования замедляется, а для автогенерации нужно написать несложный скрипт на Python. В команде есть сотрудник, который умеет писать такие скрипты. Мне кажется, что хорошее решение — поручить ему эту задачу: он потратит несколько дней, которые потом сэкономят команде намного больше времени.
Приведу еще несколько примеров из своей практики для работы с приоритетами.
Например, команда медленно проходит регресс из-за того, что большая часть автотестов сломана и ребятам приходится проходить их на регрессе руками. Очевидно, что у этой проблемы высокий приоритет, потому что бизнес всегда будет просить выдавать фичи как можно скорее.
Или же продакт и поддержка подсветили, что у команды большое количество критичных багов с прода, по метрикам таких багов — более пяти в каждом релизе. Лучше заняться устранением проблемы в первом приоритете, например пересмотреть процесс приемочного тестирования задач, покрытие требований тестами и так далее.
В качестве примера с низким приоритетом предложу ситуацию с неописанными правилами оформления тестовой документации. QA пишут тест-кейсы без шаблона, но при этом все требования покрываются. Такая проблема вполне подождет, пока команда занимается более приоритетными вещами.
Помимо проблем с процессами и качеством можно столкнуться с тем, что команде не хватает компетенций для успешного выполнения работы или хромает мотивация. Важно не игнорировать это и работать с командой. Например, если на проекте низкий процент автоматизации и, как следствие, долгий регресс, лучше всего заняться развитием ребят в этом направлении или дополнительным наймом — это зависит от сложности проекта.
Есть риск столкнуться с негативной реакцией на предлагаемые изменения. Я всегда был за открытые дискуссии, поэтому, если видите негатив, обсудите это с командой. Как правило, в ходе дискуссии появляются более оптимальные решения.
Если после обсуждения понимаете, что решение лучше скорректировать, сделайте это. Мне кажется, что не стоит делать это слишком часто, потому что так лид подрывает свой авторитет в команде.
Если собираетесь внедрить какое-то изменение, лучше заранее собрать обратную связь у команды и скорректировать инициативу.
Делегировать
Не буду сильно углубляться в тему делегирования, лишь отмечу, что моя цель — построить самостоятельную команду. А делегирование напрямую ведет к росту экспертности.
Я делегировал задачи, в том числе и процессные, исходя из сильных качеств и навыков ребят. Например, если сотрудник пишет автотесты и ему интересно попробовать управление, стоит дать ему задачу для развития этих навыков, например ведение бэклога для автотестов и планирование.
В первое время придется провести не один раунд ревью для той или иной активности, но в будущем это себя окупает.
Оценить результаты работы
Итак, вы внесли изменения в процессы работы команды, теперь подождите какое-то время и оцените их эффективность.
Иногда результаты видны невооруженным глазом, но надежнее провести анализ метрик до и после изменения. Например, если сокращали количество багов с прода, нужно убедиться, что изменения не привнесли негативный эффект. Кроме метрик мне помогают разобраться в результатах отзывы руководителей и ключевых людей на проекте, с которым я взаимодействовал за время совместной работы.
Не всегда сразу видно резкое улучшение показателей, но если есть позитивный тренд, команда движется в верном направлении. Если он негативный, стоит вернуться и провести анализ предыдущих шагов.
Дальнейшее развитие команды
Давайте представим: вы развили сильную команду крутых специалистов, улучшили все процессы, которые только можно было улучшить, — что же делать дальше? Ответ простой: идеальных команд и процессов не бывает, всегда есть что развивать. Примерно 10 лет назад услышал любимую фразу своего бывшего руководителя из другой страны, которая до сих пор у меня в голове: If nothing changes, nothing changes.
Один из вызовов для меня как для лида — строить самостоятельные команды, в которой моя роль сведена к минимуму. Мне помогают следующие активности:
Устраивать ретро внутри QA, чтобы команда открыто подсвечивала проблемы.
Проводить брейнштормы для решения этих проблем.
Выращивать преемника (ов).
Проводить периодические аудиты команды, этим могут заниматься и инженеры. Я использую свои чек-листы с учетом особенностей команды. Еще на просторах интернета есть курс по проведению аудитов от «Лаборатории качества» — не проходил, но обычно у них неплохие обучения.
Обмениваться опытом со смежными управлениями.
Общаться с руководителем и черпать новую информацию по управлению командой.
Ошибки, которые я совершил
Я описал план действий с учетом своего опыта, но, конечно, тоже совершил ошибки. Расскажу о некоторых из них:
Не собрал требования от всех руководителей. У меня их было несколько — непосредственный и функциональный. Через месяц выяснилось, что у меня как у инженера есть цель написать N количество автотестов. Не скажу, что это было критично, но пришлось поднапрячься, потому что раньше я не работал с нативными тестами в мобильном приложении.
Не всегда делегировал задачи с учетом навыков ребят. Было несколько случаев, когда тратил много времени на ревью, но в итоге приходилось доделывать работу самому или просить об этом кого-то с более релевантным опытом.
После внедрения изменений иногда полагался на субъективную оценку, хотя по метрикам был негативный тренд.
Подведем итоги
По моему опыту, алгоритм работы в новой и сформированной командах очень похож. Собрал чек-лист из шагов, который может помочь:
Понять требования руководства.
Собрать информацию о команде и продукте.
Сформировать список текущих проблем.
Погрузиться в проект как QA-инженер.
Заслужить авторитет и доверие команды.
Внедрять изменения, не забывая делегировать задачи.
Оценить результаты изменений, включая обратную связь от коллег.
Развивать самостоятельную команду.
Что касается сроков, моя рекомендация — собрать проблематику и исправить критические аспекты за первые три месяца. Как правило, от лида ждут, что он внесет важные коррективы или по крайней мере наметит план действий в течение испытательного срока.
Конечно, проект и зрелость команды бывают разными, поэтому сроки будут различаться. К примеру, в кризисных командах действовать нужно будет быстрее, но алгоритм будет схож.
Надеюсь, что статья будет вам полезна и позволит избежать ошибок:)
