Привет!

Меня зовут Александр Поплёвко, я руководитель продукта онлайн‑платежей в Леруа Мерлен.

В 2021 году меня постоянно терзала мысль: все вокруг только и говорят об «успешном успехе», а делиться болью и факапами — персональными или командными — как‑то не очень принято. Хотя, на мой взгляд, пользы от таких обсуждений ничуть не меньше, чем от положительных историй.

Под катом небольшая история о том, как мы организовали «факап‑митапы» (тоже не без факапов) внутри нашей компании, зачем это вообще нужно и при чём тут some title some text.

Идея организовать мероприятие, где все будут делиться историями, не стесняясь своих неудач и не боясь осуждения со стороны, появилась давно. Вроде бы уже все знают, что ошибаться — это нормально. Но в IT‑сообществе всё ещё довольно стигматизирована тема ошибок в работе. Как будто неприлично признаться коллегам (да и часто самому себе), что вот это у меня не работает, я потратил кучу времени и сил, но ничего не получилось. Или получилось, но совсем не так, как ожидал. Досыпьте сюда ещё синдром самозванца — будет совсем грустно.

Ещё один момент, подтолкнувший к идее: когда на проде происходят проблемы, отчёт о них обычно довольно формальный, редко когда это обсуждается и выходит за пределы команды. Если о таком и рассказывают, то это скорее очень техническое письмо — у нас упала такая‑то штука, причины были такие‑то. Часто это просто тяжело читать и хочется ответить сразу: «Ну, не получилось у вас — сами виноваты. У меня такого не будет, у меня всё хорошо». В какой‑то момент мне захотелось попробовать обсудить проблемы иначе — с рефлексией и человеческими эмоциями. Остановились на формате митапа.

Окей, есть мысль провести митап. Что делать дальше?

• Определяемся с целевой аудиторией
  Изначально хотели провести митап только для разработчиков. Больше упора на технические проблемы, сплочение сообщества и вот это всё. Но потом решили позвать всех, кто имеет отношение к IT, — от разработчиков и аналитиков до архитекторов и руководителей. Это важный шаг для компании — сообщества взаимодействуют, а не замыкаются на своём периметре. Таким образом ошибка в рамках одной команды с меньшей вероятностью повторится в других.

• Определяемся с форматом
  Тут всё просто: так как собирались в первый раз, то рассматривали только оффлайн‑формат в нашем офисе, где «все свои», а значит, делиться проблемами легче. Чтобы сгладить горечь факапов, добавили пиццу.

• Прогоняем спикеров
  В нашей компании принято перед любыми выступлениями прогонять доклады, и факап‑митап не стал исключением. Для выступающих есть лишняя возможность проверить навык публичных выступлений. Для организаторов — подсветить, что можно улучшить + сориентироваться по времени.

Как провести факап-митап и не профакапиться

Итак, спикеры найдены, зал забронирован, еда заказана. Прогоны прогнаны, анонсы анонсированы. За два дня до митапа происходит следующее:

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

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

Раз уж зашла речь про факапы

Короткая сессия саморефлексии Леруа Мерлен.

Факап раз

В 2017 году, когда мы только начинали собственную разработку в «Леруа Мерлен», ко мне, на тот момент начинающему бэкендеру, пришёл лид фронта. Постоянный клиент в большом количестве закупал товары для обустройства некоего помещения и очень расстраивался, что при оформлении заказа более чем на 50 единиц товара всё ломается.

Я пошёл выяснять и обнаружил, что ошибка крылась в моём же коде — списки товаров некорректно разбивались на блоки для запросов во внешнюю систему. Размер одной партиции был как раз 50 позиций, поэтому только на меньшем количестве всё отрабатывало корректно. Ошибку оперативно поправили, а позже ввели уровень покрытия бизнес‑логики тестами.

Факап два

В январе прошлого года команда мобильного приложения для клиента повысила уровень стрессоустойчивости, а пользователи «Леруа Мерлен» получили следующий пуш:

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

Также, если бы не эта случайность, то при первой боевой рассылке уведомлений на бóльшую аудиторию мы бы столкнулись с нерассчитанной нагрузкой — конверсии 18% от одного уведомления хватило, чтобы ненадолго положить API мобильного приложения и повлиять на работу некоторых методов сайта.

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

В таких ситуациях не стоит возлагать вину на разработчика, который сделал неверное действие с продом. Ведь за неверным действием разработчика может стоять некорректный процесс внутри команды, который даёт возможность совершения ошибки. Даже стоит поблагодарить коллегу за использование безобидного some text в качестве плейсхолдера. Ведь могло быть и хуже.

По следам митапа

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

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

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

Выводы:

• Не бойтесь проводить встречи по разбору полётов. Главное — позитивная атмосфера, чтобы это не превращалось во всеобщее унижение.

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

• Не стесняйтесь ошибаться. Это нормально.