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

И если стандартов управления DevRel-процессами ещё нет ввиду молодости функции, то ИТ-команды нарабатывали опыт решения подобных проблем давно. Используя их методы, за 1-3 месяца можно существенно повысить зрелость DevRel.

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

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

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

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

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

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

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

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

Доклад о том, как в ОДНОЙ АЙТИ-КОМПАНИИ завели внутреннее сообщество блогеров: от первых созвонов до запуска личных каналов у разработчиков. Расскажу, зачем бизнесу и разработчикам это нужно, с какими барьерами сталкивались и как выстроили формат, который не напрягает, но работает. Разберёмся, как организовать сообщество для тех, кто хочет рассказывать о своей экспертизе, но не знает, с чего начать.

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

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

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

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

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

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

В докладе поделюсь своим опытом ведения каналов технобрендов (Авито и Т-Банк) и расскажу:

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

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

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

3. Documentation as Code: принципы и инструменты
Хранение документации в markdown-формате в Git-репозиториях позволяет применять практики разработки: контроль версий, code review и автоматизированную сборку. Это превращает документацию в часть продукта, а не в отдельный ресурс.

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

5. Вовлечение сообщества через открытый контрибьюшн
Разрешение разработчикам вносить правки через pull request'ы ускоряет исправление ошибок и обогащает документацию реальными кейсами. Такой подход требует чётких правил, но значительно повышает актуальность материалов.

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

7. Эффективность подхода и ключевые инсайты
Как показала практика, переход на «Documentation as Code» ускоряет обновление документации и повышает ее качество. Тем не менее, успех зависит от интеграции процессов в workflow команды, а не только от выбора инструментов.

8. Documentation as Code как часть DevRel-стратегии
Такой подход делает документацию динамичным ресурсом, соответствующим принципам DevRel: прозрачность, вовлечение сообщества и измеримая эффективность. Это превращает её в важную часть продукта, а не просто в справочник.

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

Хочу рассказать, как я пришла к идее запускать исследования в рамках DevRel-стратегии — и зачем это вообще нужно. Поделюсь опытом двух проектов: первое исследование по проектному управлению (2022) и свежее — по русскоязычному комьюнити QA (2025). Расскажу, как это работает, что получилось, что не очень, и почему такие штуки могут быть полезны не только компании, но и экспертам, и сообществу. Будет честно, местами смешно, местами больно — но точно полезно.

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

Ключевая проблема аудитории:

Многие деврелы сталкиваются с одним и тем же:
• Непонятно, зачем бизнесу деврел
• Нет доверия и бюджетов
• Нет карьерных треков
• Нет перспектив роста
• Кажется, что отрасли как таковой нет

Позитивные кейсы есть, но они — скорее исключения.

1. Это не тупик, а нормальное состояние зарождающейся профессии.

DevRel в России — профессия, которая ещё формируется.
Это момент, когда правила игры можно установить.
Похожая история была с продактами 15 лет назад и с разработчиками 25 лет назад — они были людьми, которые не вполне понятно зачем нужны, непонятно, как их мерять и они делают всё подряд. По секрету: в некоторых IT-компаниях это до сих пор так.

2. Бизнесу нужна эта функция — но он не умеет её «готовить».

Именно деврелы должны показать, как это должно работать:
что мы делаем, в чём ценность, какие метрики, как это влияет на результат.
Это и есть ответственность тех, кто уже в профессии.

3. Примеры движения возможны уже сейчас.

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

Что нужно, чтобы это стало возможным:

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


Главная мысль: если профессия формируется — значит, вы можете её формировать.

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

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

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

Доклад будет полезен вам, если:

– вы хотите понять, как меняются процессы DevRel с ростом компании и как не потерять эффективность на каждом этапе
– вы только начинаете работать в DevRel и хотите заранее знать, что ждёт вас дальше (и как не сойти с ума)
– вы хотите понять, в каких компаниях предстоят перед вами задачи на самом деле и какое место работы будет лучше всего лично для вас.

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

Во время доклада разберём:
• Главные конфликты между DevRel и рекрутингом (откуда растут ноги и как вернуть всем крылья)
• Как KPI одной команды могут ломать процессы другой
• Реальные кейсы и аналитика: что не так в текущих взаимодействиях?
• Инструменты и подходы, которые помогут перейти от противостояния к партнёрству

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

В докладе расскажу о пяти стратегиях, которые помогут работать с внешними и внутренними сообществами на благо ваших целей.
Здесь расскажу план о том, что нас ждёт в докладе:
— Синхронизация по основам комьюнити-менеджмента
— 5 рабочих стратегий по работе с сообществами
— Принципы, по которым можно выбирать стратегии
— Примеры, откуда брать вдохновение

Расскажу о выращивании внутренних профессиональных сообществ в составе экосистемы и их развитии

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

• Поделюсь практиками, как находить единомышленников и заряжать на высокий результат команды смежников и подрядчиков;
• Что стоит планировать при формировании стратегии на год, а где оставлять пространство для маневра;
• Как находить ресурс там, где его нет;
• Как трекать эффективность своих проектов и вовремя менять курс;
• Как идти своим путем, находить свой стиль, отстраиваться от конкурентов и выходить в ТОП.

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

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

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

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

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

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

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