В  Lamoda Tech мы работаем не только над e-comm платформой и приложениями, но и создаем продукты для внутренних пользователей. Например, системы для пунктов выдачи заказов, приложения для пеших курьеров и так далее.

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

В какой-то момент ситуация стала критической: в списке скопилось больше 100 задач. Для двух небольших команд это стоило бы пары лет разработки, если брать по 2 задачи в каждый спринт.

Смотреть в этот бездонный колодец было больно. Поэтому мы решили действовать радикально: пофиксить все старые баги на багатоне и изменить работу с техподдержкой, чтобы не копить баги в таком количестве. Расскажу, как мы это организовали.

Откуда столько багов?

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

В основном это были технические проблемы и запросы из саппорта: неудобный интерфейс, ошибки при работе с несколькими сменами на ПВЗ, ошибки в мультизаказах, выдача корректного текста ошибки и так далее.

Конечно, объем бэклога расстраивал. Команду демотивировало, что появляется все больше задач, которые мы возьмем в работу «никогда-нибудь». Я задумывалась о введении Zero Bug Policy, когда есть только два варианта работы с багом: или признать его критическим и сразу исправить, или просто не заводить, если баг не так серьезен, чтобы бросать на него все силы. Но команда не поддержала эту идею. При возникновении похожих ошибок нам было важно знать, когда с проблемой столкнулись впервые и как часто она повторялась после. 

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

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

А после мы планировали изменить систему работы с багами.

Подготовка к багатону

Готовиться мы начали в конце ноября. Я была проджект-менеджером и договорилась с заказчиком, что мы выделим ребятам время на фикс багов, объяснила важность этой задачи. Основным аргументом была мотивация команды: когда мы закроем бэклог, всем станет спокойнее и легче работать. Кроме того, исправление ошибок должно было сделать работу пользователей удобнее.

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

Вся подготовка проходила в три этапа:

Шаг 1. Посмотреть бэклог и выбрать подходящие для мероприятия баги по определенным требованиям.

Я попросила тимлидов и одного системного лида просмотреть бэклог и выбрать задачи, которые можно брать в работу. Некоторые задачи сразу удалили, поскольку они потеряли актуальность, другие были не воспроизводимы, и так далее. Так мы закрыли около 20 багов. 

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

В итоге мы отобрали 35 различных багов. 

Шаг 2. Придумать систему оценки.

Мы выбрали оценку по времени: участники могли получить столько баллов, во сколько часов работы оценен баг. Командам мы не сразу рассказали про багатон. Поэтому мы смогли провести груминг для оценки багов, пока никто не знал про мероприятие — чтобы никто не накинул лишних часов-баллов. 

Шаг 3. Организовать удобный способ отслеживания статуса багов для мероприятия.

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

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

Не кодить по ночам

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

Равные по силам команды

Всего нас было 20 человек вместе с тимлидами, и мы решили поделить команды по тестировщикам — их было 4. Получилось по три разработчика и одному тестировщику на команду.

Тестировщики тоже могли получить баллы

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

Багатон проходил онлайн

Команды сами выбирали, где и в каком формате им общаться. Подарки всем участникам и победителям тоже были виртуальные: мы вручали сертификаты на покупки в одном популярном маркетплейсе. 

Общий и командный зачет

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

Зачет обновлялся несколько раз в день, на третий день с утра мы объявляли итоги. 

Работать над задачей могла только одна команда

Если ты взял задачу — перевел исполнителя в Jira на себя, — то любые другие участники не могут ее брать. 

Оценки менялись в зависимости от статуса задачи

За баг, который был оценен в 8 часов, команда могла максимально получить 8 баллов — в случае, если задача была доведена до статуса ready to merge. Статус testing/need testing/need fixing (работа проделана, но не до конца) давал 3/4 от общей оценки задачи. Задача, доведенная до статуса code review, давала команде 1/2 от оценки. За невоспроизводимый баг команда получала 4 балла вне зависимости от оценки в часах.

Проведенное review давало 1/8 оценки задачи, но только для тимлидов. Мы установили это правило, так как тимлиды будут тратить время на ревью задач, при этом не занимаясь самими багами. 

После багатона: как мы изменили работу с техподдержкой

В спринте багатона было 35 багов. В итоге мы закрыли 26 из них. Это крутой результат за два дня, тем более, что там были баги и на 16 часов, и на 8: мы фактически закрыли годовой бэклог. Ощущения от проделанной работы — непередаваемые.

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

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

Благодаря Support Weekly нам удается: 

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

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

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

• Замечать системные проблемы: мы видим, каких проблем много, куда стоит обратить внимание.

• Держать бэклог в актуальном состоянии. 

Встреча Support Weekly изначально задумывалась как временное решение, но в итоге она с нами уже больше года. Сейчас в бэклоге около 20 неприоритетных багов, но они больше не кажутся бездонным колодцем: команда знает, что это за проблемы, решает их — или сознательно не решает, но помнит, почему. 

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

Поделитесь, как вы работаете с неприоритетными багами? Если у команды нет ресурса фиксить все на 100%, вводите ли Zero bag policy или действуете как-то еще?