Или фиксим баги багатона, на котором фиксим баги.

Bugathon (багатон) — это мероприятие/соревнование, проводимое внутри компании между командами/сотрудниками. Его цель в том, чтобы исправить как можно больше дефектов продакшена (или тикетов о дефектах, но об этом позже). Если загуглить количество упоминаний о «hackathon», то вы обнаружите порядка 17 млн результатов, а по слову «bugathon» всего 17 тысяч. Корреляцию проводить не стоит, но значения вполне пропорциональны уровням интереса в создании новых фич в продуктовых командах и работе с дефектами в них.

Поэтому Багатоны — редкое явление, но не потому, что проведение подобного мероприятия говорит о том, что у компании проблемы с дефект-менеджментом и Багатон последняя надежда. Это не так, можно найти 3-4 других способа разобраться с багами при сопоставимых бюджетах. Дело в том, что успешный багатон — это не просто собрать все команды разработки в отдельный день, освободив от всех иных активностей, направив их фокус только на решение багов, со словами «кто решит больше дефектов, тот и получит конфету». Это достаточно массивный пласт работ со множеством нюансов. Краткое описание этого процесса можно прочитать в статье «Альфа-Багатон. Как мы закрыли кучу багов в двух больших продуктах в формате хакатона». 

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