Интервью с Романом Горбуновым: как управлять большими QA-проектами и повышать эффективность команды

Когда в QA-проекте 20 тестировщиков и релизы выходят каждую неделю, привычные способы управления перестают работать. Задачи теряются между согласованиями, люди перегружены, а руководство не понимает, почему при таком штате качество стоит на месте. О том, как выстроить работу так, чтобы команда не выгорала, а результат оставался предсказуемым, мы поговорили с Романом Горбуновым, руководителем QA-проектов.

Разобрали, чем управление большим QA-проектом отличается от маленькой команды, как оценивать эффективность тестировщиков без субъективщины и что делать, когда проект растёт быстрее процессов.

Что меняется, когда команда перерастает десять человек

Роман, чем управление большим QA-проектом отличается от маленькой команды? Где проходит эта граница?

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

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

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

А что перестаёт работать первым, когда команда растёт?

— Обратная связь. Раньше ты видел результат работы сразу, теперь между тобой и исполнителем появляется слой: тимлиды, старшие тестировщики, координаторы. Информация идёт дольше и искажается, и ты узнаёшь о проблеме, когда она уже выросла.

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

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

Как оценивать эффективность команды без субъективщины

Многие руководители жалуются: метрики есть, а толку нет. Одни тестировщики пишут много тестов, другие мало, но качество продукта от этого не зависит. Как вы решаете эту проблему?

— Я не оцениваю тестировщиков по количеству написанных тестов. Это самый простой и самый вредный показатель. Человек может написать 300 автотестов, половина из которых будет падать на каждом релизе.

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

То есть количество не главное?

— Количество важно только в связке с качеством. 50 стабильных тестов, которые закрывают критические сценарии, полезнее 500 нестабильных, которые никто не смотрит.

Ещё один показатель — сколько времени разработчик ждёт обратной связи. Если тестирование тормозит релизы, это видно всем. Если нет, значит команда работает эффективно, даже если цифры в отчётах скромные.

А как вы оцениваете отдельных людей? Всё-таки зарплаты, повышения, премии.

— Смотрю на то, как человек влияет на команду и продукт. Один тестировщик может найти 10 дефектов, но если он делает это молча и не делится знаниями, команда получает от него меньше, чем от того, кто нашёл 3 дефекта, но выстроил процесс проверки, который потом используют все.

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

Что делать, когда проект растёт быстрее процессов

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

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

Я стараюсь вводить процессы заранее. Не ждать, пока команда вырастет до 20 человек, а начинать с 10. Тогда переход проходит мягче.

А что делать, если уже поздно и всё сломалось?

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

Проблема в том, что люди часто начинают с инструментов. Покупают новый фреймворк, настраивают CI/CD, а через полгода выясняется, что процессы всё ещё не выстроены. Просто теперь они автоматизированы.

Что самое сложное в управлении большим QA-проектом?

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

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

Что бы мы сделали на месте руководителя нового большого проекта

Представь, что завтра тебе дают большой QA-проект с нуля. С чего начнёшь и чего точно не будешь делать?

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

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

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

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

Вместо заключения

Большой QA-проект держится не на количестве тестировщиков и не на наборе инструментов. Важнее прозрачность, понятные приоритеты и доверие к результатам проверок. Если команда понимает, зачем она делает свою работу, и видит, как это влияет на продукт, она справляется сама. Руководителю остаётся следить за системой и вовремя её пересматривать.

Остались вопросы? Пообщаться с нашими экспертами вы можете на бесплатной консультации.