Багатон как в первый раз
Bugathon (багатон) — это мероприятие/соревнование, проводимое внутри компании между командами/сотрудниками. Его цель в том, чтобы исправить как можно больше дефектов продакшена (или тикетов о дефектах, но об этом позже). Если загуглить количество упоминаний о «hackathon», то вы обнаружите порядка 17 млн результатов, а по слову «bugathon» всего 17 тысяч. Корреляцию проводить не стоит, но значения вполне пропорциональны уровням интереса в создании новых фич в продуктовых командах и работе с дефектами в них.
Поэтому багатоны — редкое явление, но не потому, что проведение подобного мероприятия говорит о том, что у компании проблемы с дефект-менеджментом и багатон последняя надежда. Это не так, можно найти 3–4 других способа разобраться с багами при сопоставимых бюджетах. Дело в том, что успешный багатон — это не просто собрать все команды разработки в отдельный день, освободив от всех иных активностей, направив их фокус только на решение багов, со словами «кто решит больше дефектов, тот и получит конфету». Это достаточно массивный пласт работ со множеством нюансов. Краткое описание этого процесса можно прочитать в статье «Альфа-Багатон. Как мы закрыли кучу багов в двух больших продуктах в формате хакатона».
Именно эти нюансы или подводные камни часто приводят к тому, что багатон даже не начинается, а если проходит, то не так как ожидалось. На этом я здесь и сосредоточусь на подводных камнях, которые могут ждать вас во время организации багатона. Для меня написание этой статьи поможет понять, что можно было сделать лучше, в формате публичного отчёта. Не всё же об историях успеха рассказывать, ведь, как мне кажется, рассказ о подводных камнях будет интереснее. Хотя бы тем, что вы будете знать, как и когда их обойти.
Рецепт багатона, на первый взгляд, выглядит не сложно:
Понять, зачем нужен багатон.
Написать план.
Согласовать проведение.
Найти деньги.
Прорекламировать мероприятие раз.
Подготовить платформу/инструменты для проведения.
Причесать тикеты с дефектами.
Собрать ревьюверов и жюри.
Продумать игровую механику
Прорекламировать мероприятие два.
Провести.
Подвести итоги.
Профит.
Но есть нюансы. Начнём с начала.
Зачем вообще нужен багатон?
Для качества вашего продукта!
Любое хорошо организованное внутреннее мероприятие позитивно скажется на отношениях внутри коллектива, особенно если вы все-таки выбрались с удаленки пообщаться в офис по такому случаю и поесть пиццы. Оно скажется положительно и на командах и их фиче-овнеров, живущих в позиции «Вот наша страница и наша кнопка, а вот это всё не наше, и пусть об этом думают другие». На багатоне они вспомнят о том, что конверсия зависит от качества и других страниц и других кнопок. А это важно.
Например, одна из метрик качества продуктов в Альфе — это комплексный показатель качества. В расчёт этого показателя входит коэффициент, отвечающий за работу с «забытыми и никому не нужными» дефектами. Для некоторых команд это как один комар в ночи, которого нужно все-таки встать и убить, чтобы премию дали спалось хорошо.
Примечание. О комплексном показателе качества вы можете подробнее узнать из «PRO Тест № 25 ӏ QA-метрики».
Так вот, багатон с конкретно выделенным временем и фокусом на исправление дефектов, — отличный шанс освободить себе спринты для работы с новыми, классными и, в этот раз, безбаговыми фичами.
Например, на первом проведенном багатоне в нашем банке, цитирую (с небольшими изменениями):
«На доску для Багатона добавили 81 баг, за время Багатона удалось исправить 57 из них. «Исправленным багом» считалось не просто заявление от команды вида «Готово, пофикшено!», а более сложный процесс — доработка по такому багу должна была встать на бой, а затем сотрудник сопровождения должен был подтвердить, что баг действительно закрыт. В итоге 53 бага успешно встали на бой»
Сколько это времени в спринтах, 53 бага из 81, каждый может посчитать для себя, применив на свою ситуацию.
Первый багатон считался проведённым успешно, хотя бы потому, что его было решено проводить каждые полгода.
Возможно, первый раз для организаторов это был вызов, а для нас (для меня, в частности) показалось протоптанной дорожкой, по которой стоит просто пройти. Но они прошли не одинаково. Финансирование и организация — то, что отличает два проведенных багатона. Поэтому о них я напишу в начале, а уже затем поговорим про другие немаловажные факторы успеха!
Деньги
Правят мотивацией как участников багатона, так и их руководителей.
Если модель бизнеса вашей компании включает в себя наличие внутреннего заказчика и внутреннего исполнителя, то нужно крепко подумать, кого просить заплатить за организацию и призовой фонд.
По факту, есть всего два варианта: платит ИТ, платит бизнес.
Если вы, как ИТ, решили вложиться в багатон, как к способу привлечь внимание к лонглисту накопившихся миноров, то будьте готовы к вопросам по типу: «А зачем оно мне надо? Мы не закладывали эти два дня в квартал! Два дня работы продуктовой команды — это знаете сколько?»
Поэтому может оказаться так, что выделенные ИТ-деньги из его бюджета могли бы потратиться куда эффективнее, даже на исправление тех же самых дефектов, но в другом формате. К примеру, можно предложить провести мероприятие, в рамках которого команды в течение месяца будут отыскивать дефекты, получая увеличенную премию за каждый найденный недостаток.
Основываясь на опыте проведения багатона в другом подразделении банка и результатам ретроспективы, мы пришли к выводу, что багатон, как мероприятие, сначала нужно продать бизнесу, а уже затем ожидать его значительной вовлеченности в успешное проведение.
Под «продать бизнесу» подразумевается, что надо убедить бизнес в необходимости провести неизвестное мероприятие, которое мы провели всего-то 1 раз в Банке (это не митап, которых десяток в год), выделить на это бюджет, выделить бюджет на денежные поощрения, и выделить рабочее время.
Во время награждения все выглядят довольными.
Готовы ли вы к такому? Крепко задумайтесь.
Под вовлеченностью подразумевается мотивация и призыв команд к участию, а также выделение продуктового времени на данную активность. Для широкого охвата и, следовательно, результативности, фактор мотивации к участию со стороны заказчика имеет большое значение. В противном случае, вам придется обращаться к отдельным руководителям для получения согласия на участие их эффективных команд в вашем мероприятии.
Кстати, о согласиях.
Коммуникации и оргкомитет
Второй босс подводный камень — согласования.
Согласования начинаются с рабочей группы. Сейчас я вижу два подхода:
Как это было первый раз — рабочая группа вовлеченных и заинтересованных людей с фасилитатором-ответственным.
Отдельно выделенный менеджер проекта с KPI за результат.
Вероятно, если химия случилась и уровень зрелости команды высок, вы сможете продвинуть проект группой. Однако на больших продуктах, особенно в условиях турбулентности, я выбираю менеджера, с которого будет итоговый спрос. В нашем случае этот спрос был размыт, и мы на ходу договаривались о том, кто и какую часть подхватит. Это не есть хорошо — обозначайте рамки ответственности каждого сразу!
Составление чек-листа коллег — одна из важных задач для менеджера проекта. Список должен включать коллег, с которыми необходимо пообщаться, уведомить и согласовать тему проекта. Я бы разделил их на три группы:
те, кто может помочь провести проект;
те, кто может случайно помешать;
и те, кто обязан согласовать.
Начнем с самой важной группы — это согласующие: те, от кого зависит, придут ли вообще сотрудники на ивент, или же они будут заблокированы другими важными задачами.
Просто так забрать у владельца продукта команду на день, а тем более на два, не выйдет.
У PO есть план, который есть в планах у CPO, который есть в планах где-то ещё выше. Так что именно вся эта вертикаль должна быть оповещена о ваших намерениях. А вершина этой вертикали должна одобрить ваши намерения и уже в обратную сторону запустить волну информирования о планируемом событии.
Ведь даже если вы сможете убедить несколько сотен человек, что им нужно собраться в команды, выбрать капитанов и подготовиться к некому багатону, все труды заблокируются руководством, ведь если директора ИТ в контексте, это далеко не значит, что все остальные руководители знают, что вы готовите какой-то там проект. Убедитесь, что все, как по горизонтали, так и по вертикали, как минимум оповещены о сроках.
Есть смежные ИТ-подразделения, с которыми вы, вероятно, интегрированы. И если у них в календаре работ окажется плановая профилактика, то на проект все поедут в тыкве, а не на карете.
Ну и, наконец, технические лидеры — со всеми необходимо утвердиться о планах и сроках. Иначе вы можете попасть в ещё одни плановые работы по рефакторингу всего проекта, накладывать на который другие ветки с фиксами проблематично.
Второй важный аспект привлечения внимания лидеров — это получение экспертного мнения при работе над технической часть мероприятия.
Мы составляли список дефектов, маркируя их лейблами с предполагаемым уровнем исправления проблемы: фронт, мидл, бэк. В этом процессе ранжирования принимали участие лидеры аналитики и тестирования, опираясь на свои знания архитектуры и умение анализировать логи, они постарались определить корректные параметры дефекта.
Однако, не все дефекты были правильно размечены, что привело к ошибкам команд при выборе дефекта на старте проекта. Например, мы указали, что дефект на уровне фронтенда требует усилий Android-разработчика, но после анализа внутри команды выяснилось, что необходимо внести изменения в API, а команда на мероприятие прибыла без Java-разработчика.
Даты
На итоговом ретро, группа карточек, которая вошла в топ проблем, это «неудачно» выбранные даты проведения.
Большой бэклог подразумевает долгосрочные и краткосрочные планы, в которые, в моменте, очень тяжело уместить какие-либо активности, тормозящие производство. Критически важные работы на сервере на полдня могут сопровождаться длинной цепочкой согласований. О том, чтобы за пару месяцев до начала крупного внутреннего мероприятия занять сторонними задачами все команды проекта можно даже не думать!
Сегодня вам мешает плановая, за год — согласованная недоступность системы, завтра целое направление тушит землю под ногами, послезавтра реализация государственных требований, ну, а в конце декабря все устали, и им не до дефектов, даже за хороший призовой фонд.
Чего точно не стоит делать, так это отталкиваться от того, что у вас есть бюджет, и им предлагают воспользоваться вот с ноября, а то в следующий год уже заехать не сможем.
Так что чем больше у вас будет времени перед стартом, тем вероятнее, что и команды будут планировать кварталы и спринты за вычетом времени на ивент, и никакие другие ограничения вам не помешают. Далее все зависит лишь от необходимых коммуникаций.
Возможно, стоит начать разбивать этот камень киркой ещё до начала выбивания бюджета, чтобы понять —, а есть ли у вас вообще время на багатон? Смотрите по ситуации.
Команды, участники и игровая механика
На первом багатоне команды были довольно разнородны по составу — могло быть 8 человек, а мог быть и один, но это не спасло нас от некоторых замечаний в обратной связи от участников состязания, которые были связаны с их чувством несправедливости от того, что в одних командах состав на 13 человек, а в других, несбалансированных, где фронты взяли себе двухнедельные отпуска в середине декабря, могут собраться лишь трое — аналитик, JavaScript-разработчик и тестировщик.
А мем не про них, не обижайтесь, просто он забавный.
Но, тем не менее, первое место в нашей истории заняла команда из четырех человек.
На фото — капитан команды победителей
Есть несколько факторов, играющих как в пользу, так и во вред крупной команде. Если это слаженная команда, то они могут грамотно выбирать себе в работу задачи. В противном случае время может быть потрачено на бесполезные споры и аналитику, что решать, а что нет.
Я хочу подчеркнуть, что всё, над чем стоит работать организатору — это пришедшие участники, мотивированные и вовлеченные до самого конца. Ведь чем больше команд участников мы получили и удержали, тем лучшего результата добились — исправили кучу дефектов и сделали наш продукт качественнее.
К сожалению, выбранные нами стратегия и тактика по каждому из пунктов выше не сулили успеха по части массовости соревнования. Объявив участие открытым с произвольным составом команд, где люди сами решают, кто их лучший друг-эксперт, с текущим интересом на старте, мы бы имели не более 10 команд. И это прям потолок.
Так что мы решили действовать по «госуховски» — добровольно-принудительно сформировать из продуктовых команд, казалось бы, отлично сложенных, команды багатоновские (сейчас пишу и понимаю — зря-зря).
Из 74 продуктовых команд лишь 34 пришли на ивент и взяли хотя бы одну задачу в работу.
Хотя бы одну задачу решили 19.
Ну, а активно боролись до конца всего 5 команд.
А на первом месте оказалась не продуктовая команда, а отдельно сформированная, хорошо ладящая между собой, команда из лидеров.
Вероятно, формат с открытым, не принудительным участием принес бы тот же результат, но не требовал бы такой борьбы за продуктовое время команд в пользу багатона.
В открытое состязание можно было бы пригласить команды разработки из других проектов/платформ/подразделений банка, но эту гипотезу, как и остальные, необходимо доказывать и тестировать.
Здесь у того, кто удивляется и уже видит доску со стороны, мог возникнуть вопрос — почему 34 пришли и лишь 5 остались до конца? Я не знаю ответ на этот вопрос. Хочется увидеть в комментариях рекомендации, истории и ссылки на ресурсы, что прольют свет на эту проблему.
В самом деле, я не вижу идеального рецепта, как нескольким десяткам команд раздать сотню дефектов так, чтобы в работу прежде всего брали сложные и высокоприоритетные задачи, а команды равномерно решали одну задачу за другой, не отвлекаясь на успехи соседа.
Как это было у нас.
Поделили все дефекты на три уровня приоритета/критичности — легкий, средний, высокий.
Экспертно постарались определить, какие из них решаются одной строчкой кода, а какие требуют изменений на нескольких компонентах, в такой же градации: легкий, средний, высокий.
За легкий-легкий (ЛЛ) команда получала 10 баллов. За сложный-сложный (СС) — 90, так как исправление требовало больших трудозатрат, а дефект имел высокий/критичный приоритет исправления.
Понимая ценность сложных-сложных и остальных высокобалльных задач, многие команды прежде забрали в работу именно их.
Но по разным причинам не все смогли быстро справиться с ними, а те, кому повезло больше, вырвались на вершины лидерборда, не оставляя шансов остальным даже близко подобраться к ним за оставшееся время.
Возможно, отношение ЛЛ к СС не сопоставимо с трудозатратами и временем на исправление, и подход к ранжированию дефектов в такой разбалловке должен быть намного более кропотливым. Вероятно, уменьшив диапазон от ЛЛ к СС, мы бы не получили десяток демотивированных команд, кто имеет 0 или даже 10 баллов за одну задачу, когда сосед набрал 180, вытащив и решив за несколько часов несложный дефект. Так, половина вступивших в бой сложила клавиатуры ещё на середине пути.
Выводы?
Багатон может стать мощным и интересным инструментом для работы над дефектами, что затерялись в бэклогах команд.
Принимая во внимание весь анализ ошибок что мы смогли выделить первоначальный рецепт проведения нужно приправить несколькими пунктами:
Написать план.
Продать идею бизнесу и выбить бюджет.
Найти дату багатона, и это не должен быть конец года.
Продать идею руководителям подразделений и согласовать участие сотрудников разных подразделений в нужные даты.
Согласовать даты уже с техническими лидерами
Прорекламировать мероприятие раз.
Продать идею потенциальным участникам мероприятия.
Подготовить к багатону ревьюверов и жюри
Причесать тикеты с дефектами. Перепроверить.
Подготовить платформу/инструменты для проведения багатона.
Продумать игровую механику. Еще раз продумать игровую механику.
Продумать состав команд и ввести ограничения если это необходимо.
Прорекламировать мероприятие два.
Провести.
Подвести итоги.
Профит.
Рассказал о самых важных подводных камнях во время организации багатона. Надеюсь, было полезно.
