Митап для разработчиков: как организовать и сделать так, чтобы не было скучно

Опыт мобильных разработчиков Finch и трэш-митапа Drink&Code.

Привет! Меня зовут Саша, я PR&HR в Finch. Мы в компании создаем мобильные приложения для крупных брендов вроде «Газпром-медиа», ФК «Спартак» и «Столото».

В ноябре прошлого года мы провели наш первый митап для мобильных разработчиков Drink&Code. Когда мы его организовывали, делали все по наитию: придумывали на ходу, подсматривали за коллегами. Получилось классно: мы собрали 40 разработчиков, пришли ребята из CarPrice, Rambler, Rendez-Vous, «Сбербанка».

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

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

Приготовьтесь, что дальше будет много букв. Начнем!

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

Для нас это был особенно актуальный вопрос: мы занимаемся разработкой уже больше 13 лет и за это время ни разу не проводили публичные митапы. Жили же как-то до этого, зачем вообще тратить на это время, деньги и силы разработчиков?

Мы сформулировали две проблемы, боли, которые нас сейчас беспокоят:

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

Прежде чем переходить к организации митапа, нужно ответить еще на один вопрос: что конкретно мы хотим донести до участников митапа? Условно говоря, нужно описать то впечатление о компании, которое должно сложиться в голове у участников после мероприятия.

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

После того как вы разобрались, зачем вам митап, и поняли, как вас должны воспринимать участники, самое время задуматься о масштабе мероприятия. Стоит ответить на следующие вопросы:

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

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

Далее перейдем к программе. Этот вопрос особенно важен, так как, буду честен, митап, где есть только доклады — скука смертная. Да что там, на него просто никто не придет! Конечно, спикеры могут выбрать интересную тему и хорошо подготовиться, но такое бывает не всегда — да и успеха не гарантирует.

Классических митапов очень много: CocoaHeads, митапы RedMadRobot, встречи в Яндексе — на каждом из них 3-4 матерых разработчика (преимущественно из продуктовых компаний) рассказывают доклады. Не поймите меня неправильно — это вполне рабочий формат, просто зачем разработчикам идти на ваш митап, если можно пойти на CocoaHeads?

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

Наш концепт был прост: 3 доклада и 3 коктейля. В перерывах между выступлениями гостей учили правильно мешать алкоголь. Причем сами коктейли были классическими: Old fashion, «Маргарита» и т.д. — их вполне можно потом готовить дома.

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

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

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

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

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

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

Все просто — чем четче вы определите аудиторию, тем проще будет готовить доклады и тем задорнее пройдет митап. По сути нужно ответить на следующие вопросы:

Отдельно раскрою первый пункт, так как он очень важен. Когда мы готовили доклады к Drink&Code, то рассчитывали на аудиторию junior/pre-middle разработчиков. Но это была лишь гипотеза: хотя мы делали предварительный отбор людей, при согласовании заявок на опыт особого внимания не обращали.

На митапе выяснилось, что к нам, помимо junior разработчиков, пришли еще и крепкие middle и несколько senior специалистов. Понятно дело, что им было неинтересно, и 5-6 человек покинуло зал еще на втором докладе. Было неприятно.

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

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

По каким критериям отбирать спикера?

В нашем случае выступали middle разработчики, у которых было 2-3 года опыта. Самое главное, мы подобрали таких людей, чтобы каждый из докладчиков отличался своей подачей: кто-то спокойно и методично рассказывал кейсы, а кто-то шутил и превратил наш офис в Stand-UP клуб №1 на 40 минут.

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

Я крайне рекомендую посмотреть лекцию Егора Толстого (ex. Avito) про выступления и подбор докладов. В лекции Егор говорит, что доклад должен быть либо хайповым, либо хардкорным, либо прикладным. В идеале, сделать так, чтобы 2 из 3 направлений пересекались.

Скажу очевидную вещь, но доклады напрямую зависят от аудитории и наоборот. Если вы хотите собрать у себя senior-iOS-разработчиков, то расскажите им крутые кейсы про SwiftUI — это и популярно, и имеет прикладное значение. Тоже самое работает и наоборот: если собираете junior iOS, то им могут быть интересны базовые кейсы про работу с сетью.

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

Обязательно продумайте хронологию докладов. Мы на Drink&Code выстроили все в порядке сложности: от самого простого до самого «загруженного» — чтобы не распугать аудиторию раньше времени.

Кстати, к слову о темах, мы выбрали наши прикладные кейсы: создание промоигр на ECS, перевод легаси на GraphQL и нестандартные кейсы CollectionView. В последнем добавили щепотку хардкора.

Название. Название должно быть хлестким и запоминающимся, в идеале сразу — передающим суть. Drink&Code больше подходит хакатону, но мы решили, что сейчас это лучшее, что мы можем придумать.

Стилистика и логотип. ИТ-мероприятий много, поэтому, дизайн точно нужен — так вы будете как-то выделяться на фоне остальных. Мы придумали характерный, минималистичный дизайн с разноцветным бокалом. Он сильно подходит стилистике Finch — у нас минималистичный сайт, Facebook и дизайн презентаций.

Мерч. С митапа прошло уже два месяца, а участники до сих пор спрашивают у нас про футболки, так они понравились. Не стоит недооценивать силу мерча. Мы думали, что в 2020 году майками никого не удивишь, но спрос на майки доказал обратное. Люди любят халяву, особенно с крутым дизайном. Теперь жалею, что мы не сделали стикеры, свитшоты или стилизованные бокалы под виски.

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

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

Обязательно напишите всем участникам, которых вы подтвердили на Timepad, лучше в Telegram. Всем до единого. Если не отвечают, то лучше позвоните и уточните, собираются ли они приходить. Если из 50 человек, которых вы подтвердили, 30 ответили, что не придут, то лучше перенести мероприятие. Иначе на следующий день к вам дойдут не 20, а максимум 10 человек: кто-то заболеет, кто-то заработается, кому-то будет лень ехать.

За неделю до мероприятия мы подтвердили 70 гостей (брали с запасом). За день до митапа мне подтвердило участие 54 человека. По факту пришло 40. То есть чуть больше половины от первоначального количества участников.

У меня был случай, когда за день до бизнес-завтрака больше половины аудитории отказалось от участия. Я подумал, что это плохо, но не критично — у меня еще есть половина списка, которая сказала, что точно будет. В итоге из 30 доехало 6 человек. Все прошло ужасно, а клиент был недоволен.

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

Я дам лишь несколько советов, которые могут помочь:

После мероприятия обязательно соберите обратную связь от участников и спикеров. Спрашивайте сотрудников и гостей. Мы сделали короткую Google-форму и предлагали заполнить её всем, кто пришел к нам. При этом фидбек можно было дать голосовым сообщением, картинкой и текстом — просто форма была комфортнее всего.

Банально, но без фидбека вы не поймете, как все прошло и над чем стоит работать в следующий раз. Мы узнали, что 80% участникам понравилась атмосфера и формат мероприятия, а вот над докладами стоило поработать получше (писал об этом в разделе «Доклады»).

Говоря о результатах, то у нас получилось следующее: двум iOS-разработчиком настолько все понравилось, что они прислали резюме. К сожалению, ни один из них нам не подошел (один пока что начинающий Junior, второй просит слишком много). Но мы считаем, что для начала это неплохо.

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

Ближе к лету мы планируем сделать следующий митап, приглашаем докладчиков из других компаний. Если вам или вашим сотрудникам будет интересно поучаствовать, то напишите мне в Telegram @norovy.

#встречи