Багатон и его суперсила

Как организовать багатон, найти win-win-сценарий для цифрового продукта, внутреннего сообщества тестировщиков, прокачать HR-бренд… и не сойти с ума.

Привет! Меня зовут Роман Чередников, я продакт-менеджер в Группе «Иннотех». В конце июля 2023 года мы провели багатон — внутреннее соревнование для тестировщиков, и результаты оказались интересными, делюсь.

Багатон — формат внутренних соревнований, помогает «поймать», найти и описать как можно больше несовершенств в продукте и коде.

Легенда гласит, что если выдача по запросу «хакатон» принесёт 17 млн результатов, то «багатон» — «всего» 17 тысяч. Кажется, все хотят создавать новые продукты, а вот разбираться с дефектами в них хотят примерно в тысячу раз реже. Но мы-то не такие!

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

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

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

Важно: мы просили участников не только фиксировать баги, но и оставлять свои предложения по улучшению продукта!

Какие задачи мы хотели порешать багатоном:

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

Мы рассчитывали, что придёт 50–60 человек, или пять-шесть полноценных команд. Была, кстати, большая внутренняя убеждённость, что идеальный «размер» команды — это 10 человек, и багатон её только подтвердил.

Но вернёмся к ожиданиям vs реальности: очень быстро число регистраций перевалило за 100, и в итоге к старту соревнований мы пришли со 106 участниками, которые (не без нашей как организаторов помощи) разделились на 12 команд. Круто? Безусловно!

Наш багатон в цифрах:

Результаты превзошли все ожидания: за четыре часа участники «собрали» больше 1 000 багов (конечно, после проверки на предмет повторов цифра стала меньше, но всё же!) и предложений по улучшению продукта. А ещё «поймали» четыре бага по безопасности и два критических инфраструктурных дефекта.

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

Интригу сохраняли до последнего: о том, какой продукт зовём коллег тестировать, рассказали за 15 минут до старта. Коротко о том, что тестировали (и немного — почему).

DION — российская платформа корпоративных коммуникаций. Вышла на рынок весной 2022 года, разработана группой «Иннотех». Сегодня платформой пользуется более 75 тыс. сотрудников российских компаний, её сервисы позволяют экономить до 10 % времени на запуск новых продуктов и сервисов. Без преувеличения — флагманский продукт, чьё качество — наш главный приоритет.

Что мы отдали на откуп (и поломать) коллегам в этот раз:

Тестирование охватило максимум платформ: iOS, Android, Mac, Windows, десктоп и web.

Организуя багатон, нам хотелось дополнительно подсветить важность работы тестировщиков. Но тут важно добавить, что мы звали участвовать не только тестировщиков в прямом смысле слова: UI/UX-исследователей, аналитиков и вообще всех неравнодушных коллег, которые для нас не в последнюю очередь — вовлечённые пользователи, каждый — с собственным взглядом на пользовательский опыт и оптимальные сценарии.

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

Мы точно не прогадали с таймлайном багатона, отрываю от сердца — пользуйтесь:

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

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

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

1) делаем багатон в первую очередь для того, чтобы «раскачать» внутреннее сообщество и отлично провести время

ИЛИ

2) причиняем добро и наносим РЕАЛЬНУЮ пользу тестируемому продукту.

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

Именно формированию критериев оценки багов мы посвятим максимум времени на переосмысление и доработку при подготовке следующего багатона. Но это тянет на тему для отдельного поста.

Результаты багатона, которыми можно гордиться:

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

К вопросу о следующем разе: мы хотим проводить багатоны на регулярной основе. В идеале багатон должен стать таким же привычным внутренним сервисом, как, например, внутренние митапы. Зачем багатону становиться частью business as usual-подхода к разработке продуктов, спросите вы.

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

Что нужно, чтобы сделать багатоны стандартной практикой? Хороших задач, чтобы качественно поломать голову, всегда достаточно: остаются развитое и разветвлённое комьюнити специалистов (тестировщиков и не только), «неспокойные» и инициативные лидеры таких сообществ, простые и масштабируемые инструменты организации и каналы коммуникаций, а также прозрачная процедура бюджетирования для призового фонда.

Главные выводы для себя на будущее:

— доступ к внутренней базе классных специалистов;

— вовлечённость самих экспертов.

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

Кажется, я ничего не забыл, надеюсь, было полезно. И напомню: DION активно растёт, развивается и очень ждёт классных кандидатов. Приходите, у нас интересно и нескучно!

Кстати. Прямо сейчас у нас открыта пара вакансий для QA-инженеров, SRE инженер Dion.

Если не приглянулась ни одна из позиций — отправьте своё резюме на rcherednikov@inno.tech, будем на связи.