Один релиз — один ответственный. Но каждый раз новый
Поначалу такая идея воспринималась неоднозначно. Было страшно брать на себя ответственность за весь релиз; некоторые задачи казались сложными и непонятными.
Каждый спринт мы назначаем нового ответственного за релиз. Эта роль переходит каждому QA-инженеру по очереди. На время спринта он берет на себя часть обязанностей лида и становится человеком, который координирует весь процесс подготовки версии.
Важно понимать, что это не формальная смена статуса и не новая должность. Инженер продолжает выполнять свои задачи по тестированию, но одновременно начинает смотреть на релиз глазами человека, который отвечает за общий результат команды.
В его зоне ответственности оказывается не только качество продукта, но и организация процесса. Он распределяет задачи между инженерами, следит за тем, чтобы для новых функций своевременно создавались или обновлялись чек-листы, проверяет состав релиза, собирает тестовые прогоны, формирует наборы конфигурационного тестирования и распределяет устройства для регрессионного и смоук-тестирования.
Когда появляется релиз-кандидат, именно ответственный первым проверяет его на общую работоспособность, запускает регресс, контролирует прохождение тестирования, собирает статусы команды и информирует коллег о ходе проверки. После завершения тестирования он готовит отчет для заказчика в Jira, сообщает менеджеру о готовности версии к выпуску и фиксирует результаты в таблицах пострелизного мониторинга и статистике по пропущенным дефектам.
На первый взгляд кажется, что все это — набор отдельных задач. На практике это единый процесс, в котором любое неверное решение может повлиять на сроки выпуска или качество продукта.
Когда первые сложности остались позади, стало понятно, что новая роль дает гораздо больше, чем просто дополнительную нагрузку. Многие неожиданно для себя поняли, что им интересно не только тестировать продукт, но и организовывать процесс, распределять задачи, следить за общим ходом тестирования и координировать работу команды.
В какой-то момент мне даже понравилось брать на себя микроменеджмент команды, иметь возможность попробовать себя в новой роли и получить опыт, которого обычно не хватает инженерам без управленческих обязанностей.
Мы перестали растить только исполнителей
Когда QA занимается исключительно поиском дефектов, он неизбежно смотрит только на свою часть процесса. Но релиз — это всегда работа системы, а не отдельного человека.
Ответственный за релиз начинает иначе воспринимать проект. Он видит, сколько задач одновременно находятся в работе, какие проверки критичны именно сейчас, где могут возникнуть узкие места, какие риски появляются при переносе задач между версиями и как изменения в одном модуле влияют на весь выпуск. Фактически инженер начинает управлять не тест-кейсами, а рисками. Это уже другой уровень ответственности.
Такой подход позволяет постепенно развивать у каждого специалиста навыки, которые обычно ассоциируются только с руководителями. Приходится планировать работу небольшой команды, оценивать загрузку коллег, принимать решения в условиях ограниченного времени, расставлять приоритеты и постоянно коммуницировать с разработчиками, аналитиками, менеджерами и заказчиком. При этом никто не оказывается в роли руководителя «по приказу». Человек получает возможность попробовать себя в новой роли внутри безопасной среды, где команда всегда готова помочь.
Самыми сложными оказались не технические задачи
Мы ожидали, что больше всего вопросов будет вызывать организация тестирования. На практике оказалось иначе. Самое сильное напряжение у большинства инженеров возникает в первые один-два релиза, когда появляется необходимость принимать решения самостоятельно. Особенно это касается подготовки итогового отчета для заказчика. Если внутри команды любую ошибку можно быстро исправить, то внешний отчет воспринимается совсем иначе. Возникает естественный страх что-то упустить, неверно сформулировать вывод или отправить некорректную информацию.
Этот страх оказался довольно типичным — практически каждый новый ответственный говорил, что больше всего переживал не из-за технических задач, а из-за необходимости самостоятельно принимать решения и нести ответственность за весь релиз.
Поэтому в первые релизы мы сознательно добавили дополнительную поддержку. Более опытные коллеги просматривают отчет перед отправкой и помогают обратить внимание на детали, которые новичок еще может не замечать. Такой подход позволяет снизить стресс и одновременно сохранить высокое качество коммуникации с заказчиком.
Вторая неожиданная сложность — сборка тестовых ранов. Со стороны кажется, что это техническая операция, но именно от качества сформированных наборов зависит полнота проверки. Если допустить ошибку на этом этапе, последствия проявятся уже во время регресса. Здесь помогает понятная внутренняя инструкция и обязательное ревью первых тестовых ранов. После нескольких релизов инженер уже уверенно выполняет эту задачу самостоятельно.
Автономность всегда имеет свою цену
Конечно, такая модель не лишена недостатков. Ответственный за релиз продолжает участвовать в тестировании, но значительную часть времени начинает занимать организационная работа. Вместо выполнения только собственных задач приходится постоянно собирать статусы, отвечать на вопросы команды, следить за сроками, координировать проверки и контролировать десятки параллельных процессов.
«Больше всего оказалось непривычно постоянно переключаться между своими задачами и вопросами команды. Иногда кажется, что за день сделал меньше тестирования, чем обычно. Но со временем понимаешь, что начинаешь гораздо лучше видеть, как устроен весь процесс.»
— QA-инженер команды
В результате непосредственно на тестирование остается меньше времени. Есть и психологическая сторона. Не каждому инженеру комфортно заниматься своеобразным микроменеджментом команды, даже если это происходит всего один спринт. Кому-то проще сосредоточиться исключительно на технической работе. Но именно выход за пределы привычной зоны ответственности чаще всего становится точкой профессионального роста.
Выигрывает вся команда
Главное изменение мы увидели не в отдельных релизах, а в работе команды в целом. Когда ответственность регулярно переходит от одного инженера к другому, знания перестают концентрироваться у одного человека. Каждый понимает полный цикл подготовки релиза и знает, какие действия необходимы на каждом этапе.
За несколько месяцев ротации практически каждый инженер команды хотя бы раз побывал в роли ответственного за релиз. Новые участники стали быстрее погружаться в процесс подготовки выпусков, а необходимость постоянно обращаться к одному человеку по организационным вопросам заметно сократилась. Самым важным результатом для нас стало не ускорение релизов, а то, что процесс перестал зависеть от одного носителя знаний.
Если лид временно отсутствует, процесс не останавливается. Команда продолжает работать практически в обычном режиме, потому что необходимые компетенции уже распределены между несколькими специалистами. Кроме того, заметно меняется отношение инженеров к своей работе. Они начинают думать не только о качестве отдельных задач, но и о качестве релиза в целом. Появляется понимание взаимосвязей между этапами разработки, тестирования и выпуска продукта.
Для самого проекта это означает более устойчивый процесс, меньшую зависимость от конкретных людей и постепенное повышение зрелости всей команды.
Такой подход работает не только в QA
Хотя мы внедрили эту практику в команде тестирования, сам принцип гораздо шире. Ротация ответственности может использоваться практически в любой инженерной команде, где существует сложный повторяющийся процесс, завязанный на одном человеке. Это может быть выпуск релизов, сопровождение продакшена, проведение архитектурных ревью, организация дежурств или управление инцидентами. Во всех этих случаях проблема обычно одна и та же: ключевые знания и ответственность постепенно концентрируются у нескольких опытных специалистов.
Передавая часть этих функций всей команде, компания одновременно решает две задачи. Она снижает зависимость от отдельных сотрудников и создает естественную систему подготовки будущих лидов без отдельных программ обучения и искусственных тренингов.
За время работы этой практики я окончательно убедился: далеко не каждый QA должен становиться руководителем. Но каждый инженер выигрывает, если хотя бы несколько раз берет на себя ответственность за весь релиз. После этого начинаешь иначе смотреть и на тестирование, и на работу команды, и на продукт в целом. Именно поэтому сегодня я воспринимаю ротацию ответственного не как дополнительную обязанность, а как один из самых эффективных инструментов развития инженеров и повышения устойчивости команды.
Когда специалист видит весь процесс, а не только свою часть работы, меняется качество принимаемых решений, уровень ответственности и отношение к проекту. Команда становится более зрелой, а релизы более предсказуемыми.
Именно поэтому мы перестали воспринимать роль ответственного за релиз как исключительную обязанность лида. Для нас это инструмент развития команды, который одновременно делает процесс устойчивее, а каждого инженера — сильнее как профессионала.
