* Какие ожидания есть у ПК от деврела? Где чаще всего «болит»?
* Как «подружиться» с техлидами, архитекторами и экспертами, чтобы они не саботировали процессы, а вовлекались.
* Мотивация и вовлечение членов ПК.
* Привлечение новых участников в ПК: как «выращивать» новичков в комитете.

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

Работа со школьниками и студентами — новая реальность IT-компаний, ведь именно школьники и студенты будут драйверами бизнеса через 5-7 лет.

В рамках доклада разберем:
* зачем компании ввязываться в эту гонку и при чем тут Минцифры РФ;
* чем работа с молодежью отличается от классического DevRel;
* как стартовать путь в этом направлении;
* возможно ли синхронизировать усилия DevRel и команды по работе с молодежью.

В качестве бонуса: пара-тройка подробных чек-листов для себя и слайдов для C-Level.

Как мы запускали блогерский клуб внутри инженерной команды.

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

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

Вы могли слышать или даже пользоваться телеграм-ботом https://t.me/devrelcfpbot, которого я собрал за пару часов с помощью Cursor и базовых знаний программирования. На его примере — и не только — я расскажу, как DevRel-специалист может использовать нейросети в своей работе: от генерации идей и автоматизации рутинных задач до работы с контентом и аналитикой бюджетов. Обсудим, где AI реально помогает, а где пока что больше шума, чем пользы. Попробуем понять: сможет ли AI заменить DevRel'а, или всё это — просто хайп?

Прямо сейчас мы наблюдаем взрыв в сфере AI. Хочу собраться на неформальную дискуссию с экспертами по LLM и обсудить, как в ближайшей перспективе нейросети изменят нашу жизнь.

* Как AI изменит повседневные задачи инженеров?
* Новые инструменты, такие как Cursor и Cline, уже помогают автоматизировать многие аспекты программирования. Каков их потенциал в будущем?
* Что станет с более «софтовыми» задачами?
* Как AI повлияет на роли, требующие не только технических, но и социальных или творческих навыков?
* Как изменится рынок инженеров? Кто будет востребован в ближайшие несколько лет и какие навыки станут ключевыми?
* Что станет с площадками для нетворкинга и конференциями?
* Как AI может изменить формат взаимодействия и обмена опытом на различных технических мероприятиях?

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

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

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

Мы посмотрим на хронологию внедрения гребли в механику стендов и отказа от нее: сложно ли изменить отношение к HR-бренду, когда тебя воспринимают как активных и спортивных ребят, а не как технологичную компанию? Как работать и жить с этим, и как вообще узнать про это? Стоит ли идти на поводу у аудитории или решать свои задачи? И как менять отношение к HR-бренду через стенды на конференциях.

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

В докладе поделюсь своим опытом ведения каналов технобрендов (Авито и Т-Банк) и расскажу:
* как построить процесс, если вы один / у вас есть команда СММ / агентство на подряде;
* как генерировать идеи для креативных постов;
* где искать идеи для контента в целом, чтобы не превращать канал в «доску с анонсами»;
* почему ответы на комментарии важны и при чем тут комьюнити;
* за какими метриками лучше следить (а лучше, вообще, не следить).

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

В докладе:
* что такое продуктовый DevRel;
* где DevRel’ово место в feedback loop to the product and back to users, как это делают большие корпорации и где могут быть подводные камни;
* если есть задача поDevRel’ить внутренний проект, который компания решила продавать наружу, что делать?
* почему DevRel — это потенциально хороший PM.

1. Зачем компании разработчики, и место DevRel в Битрикс24

Роль внешних разработчиков и вендоров в экосистеме Битрикс24: драйверы развития продукта, снижение оттока, рост новых сценариев для бизнеса клиентов. Почему партнеры и внешние команды — стратегический актив, а не «обслуживающий персонал». DevRel как функция, а не отдельная роль: координация между маркетплейсом, продуктовой разработкой, поддержкой, бизнесом, образовательными инициативами.

2. DevRel-стратегия: что делаем для разработчиков

* Технологические потоки на партнерских конференциях.
* Онлайн-мероприятия (TechTalks).
* Библиотека тьюториалов и примеров.
* Маркетплейс и инфраструктура публикации решений.
* Прозрачные каналы сбора обратной связи (публичные чаты, саппорт).

3. Кейс: переделка документации как катализатор изменений

Откуда стартовали: легаси-дока на проприетарных технологиях, невозможность масштабирования, низкая вовлеченность, дороговизна изменений и поддержки английской версии. Переход к новой платформе: Diplodoc + GitHub, документация как код, вовлечение партнеров через pull-request, стандартизация и автоматизация. Внедрение AI для генерации примеров и автоперевода, ускорение процессов поддержки. Влияние на сообщество: рост вовлеченности старых партнеров, снижение порога входа для новых, прозрачность и контроль качества.

4. Инструменты для разработчиков: REST, SDK, шаблоны приложений, UI Kit

Открытые SDK (PHP, JS, Python в разработке), UI Kit на Vue/Nuxt, шаблоны и стартеры для быстрой разработки интеграций. Все — Open Source, фокус на снижении издержек для внешних команд. Измерение успеха.

5. Системные ограничения и вызовы DevRel

Почему компания не «API-first». Ограничения ресурсов: борьба за приоритеты, необходимость стандартизации и поддержки легаси-интеграций. Сложности миграции: «новый REST не отменяет старый, экосистема большая».

6. Тьюториалы, обучение и развитие

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

7. Планы и развитие DevRel-функции в Битрикс24

Расширение набора SDK и шаблонов, публичные репозитории, новые форматы вовлечения комьюнити. Рост вклада внешних разработчиков, планы по стандартизации и эволюции REST. Долгосрочная цель: DevRel как одна из ключевых бизнес-функций, обеспечивающая рост и удержание клиентов за счет силы экосистемы решений.

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

На докладе мы разберем:
* какие плюсы и какие подводные камни ждут в продуктовом DevRel;
* как меняется отношение к функции внутри компании, если DevRel влияет не только на разработчиков, но и на продукт, бизнес и даже индустрию;
* почему международный контекст делает продуктовый DevRel особенно важным.

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

Поговорим, что учесть при таком планировании. Как адаптировать, развивать и расширять планы от сезона к сезону. Как эти подходы могут меняться в зависимости от структуры и численности IТ в компании. Что меняется, когда появляется команда. И что делать, если одним утром вы проснулись, мир вокруг поменялся — а ваша стратегия превратилась в тыкву.

Расскажу про свой подход в укрощении разных видов исследований ЦА для реальных задач в техномаркетинге. Можно будет преисполниться и узнать:
* как изучение своей аудитории помогает принимать решения;
* как проводить исследования, даже если ты не исследователь и не маркетолог;
* как встроить исследовательский подход в DevRel-стратегию.

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

Бренд работодателя — это не слоган и не карьерная страница. Это то, как компанию чувствуют люди — изнутри и снаружи.

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

Можно ли собрать универсальный набор навыков, который делает человека директором — в любой профессии? Не по должности, а по сути.

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

Мы поговорим о том, как расти до лидера, пока профессия еще формируется. Как самому выстраивать карьерные треки, определять метрики и менять правила игры.

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

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

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

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

DevRel и рекрутеры работают на одну цель — привлекать лучших специалистов в компанию. Но почему тогда наша коллаборация часто превращается в поле битвы?

Непонимание процессов, конфликт KPI, разрыв в коммуникации — мы провели опрос среди специалистов из обоих лагерей и нашли самые острые боли в этом взаимодействии и готовы ими поделиться.

Во время доклада разберем:
* главные конфликты между DevRel и рекрутингом (откуда растут ноги и как вернуть всем крылья);
* как KPI одной команды могут ломать процессы другой;
* реальные кейсы и аналитика: что не так в текущих взаимодействиях;
* инструменты и подходы, которые помогут перейти от противостояния к партнерству.

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

В работе DevRel-специалиста запросы сыплются со всех сторон: от руководства, нанимающих менеджеров, инженеров, HR-команд — всех не перечесть. Каждый считает свой приоритет важнейшим, а ведь в рабочей неделе всего 40 часов. В итоге — хаос, перегрузка, бесконечные переключения контекста и ощущение, что «все горит, но ничего не двигается».

В этом докладе посмотрим на DevRel как на продукт, а на ваш список задач — как на бэклог. Разберем, какие инструменты из мира продуктового менеджмента в IТ помогут вам:
* превратить поток разрозненных запросов во внятный и приоритизированный список задач,
* работать со стейкхолдерами без конфликтов,
* приоритизировать задачи так, чтобы была видна реальная ценность.

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

Вас ждет:
* синхронизация по основам комьюнити-менеджмента;
* 5 рабочих стратегий по работе с сообществами;
* принципы, по которым можно выбирать стратегии;
* примеры, откуда брать вдохновение.

Поделимся опытом и лайфхаками организации и выращивания внутренних профессиональных сообществ в составе экосистемы.

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

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

Название — это 70% успеха доклада. Оно будет во всех анонсах и расписаниях. Оно привлечет нужную аудиторию и отсеет ненужную. Оно задаст контекст и создаст настроение. Осталось только его придумать. Именно этим и займемся на воркшопе.

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

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

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

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

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

1. Бизнес-контекст: исследуем данные для успешной стратегии.
2. Cмежники — наши partner in crime в реализации DevRel-стратегии.
3. Cобираем и объединяем: кому? зачем?
4. Долгосрочный брифинг и щепотка вдохновения.
5. Не я, а мы: поиск win-win-решений между командами.
6. Типичные ошибки: повторять, но с осторожностью.
7. Правила и рекомендации для достижения результата.
8. Цепная реакция: команда, которая зажигает.

Представим идиллическую картину: главные конференции индустрии только объявили call for papers, а у вы уже знаете, кто пойдет на них выступать; у собственного мероприятия в разработке еще нет даты, а программа с резервом в 50% уже есть; хороший подкаст попросил эксперта — пару сообщений, и он у них будет.

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

В докладе обсудим:
* зачем нам «инфраструктура» и в чём ограничения работы «на ручном привод»;
* из каких этапов состоит работа деврела с публичными спикерами;
* где и какие заготовки помогут сэкономить себе время и нервы, а спикерам — не теряться и отваливаться;
* с кем сверять материал;
* зачем и как проводить репетиции;
* чем, вообще, докладчик отличается от амбассадора и почему нам на самом деле так нужны вторые.

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

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

Расскажу, как я перешла от «классического» деврела в новый для себя формат про продвижение продуктов для разработчиков. Покажу, где у них много общего, а где — нет (спойлер: ситуация напоминает времена, когда деврел был делом одного человека — бюджета мало, задач много, а зоны ответственности не определены).

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

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