Семь лет я работаю с разработчиками и являюсь по сути DevRel специалистом. Споры о том, что такое DevRel не утихают. Последнее, что прочитала в чатике DevRel, что это "смесь пиара, эйчара, ивентов и

и комплекс активностей, направленных на развитие ИТ-комьюнити. А еще это технический специалист и..." прочее-прочее. Не знаю кто как, а я занимаюсь по сути маркетинговыми коммуникациями. Мои заказчики и целевая аудитория - технари. А цели могут быть совершенно разные: продвижение технологий и API, создание и поддержка комьюнити, развитие технологической экосистемы в регионе (например, под новый офис), employer brand, внутреннее обучение и мотивация разработчиков и т.д.
Я как никто другой знаю, что разработчики ненавидят, когда их «маркетят», потому что зрят в корень. Они про контент и качество, а не про форму. И инструменты работы с этой аудиторией очень ограничены. Тем не менее в работе лежат маркетинговые принципы сегментации, позиционирования, продвижения и т.п.

Developers Hate Marketing - 👍онлайн книга про построение developer relations для API и его продвижения. Это прекрасное пособие, которое позволяет взглянуть на коммуникации с разработчиками для любых целей. Рассматриваются и мотивация, и каналы, и форматы.
https://pages.apigee.com/global-ebook-developers-hate-marketing-confirmation-ty.html

“Немного о принципах коммуникации с аудиторией разработчиков, которые я всегда держу в уме.” by Natalia Makarova https://link.medium.com/FeyKsu5m2V

Кейс из практики построения региональной технологической экосистемы для офиса разработки. “Формат мероприятия под задачу.” by Natalia Makarova https://link.medium.com/eFrqPo6zaW

Пересматривая доклады с конференций Devrel, ловлю себя на мысли, что далеко не все выступления одинаково полезны. Но иногда только одна мысль во всей презентации достраивает целый пазл.

Anna Graham Keller. Доклад про внутреннюю армию https://devrel.net/dev-rel/building-internal-army
Зацепила мысль:
"Devrel-у или техническому адвокату нужен тоже адвокат, защитник, представитель интересов и транслятор" .
Другими словами, как я интерпретирую для себя, нужны те, кто будет помогать защищать и поддерживать идеи, разделять интересы, верить, что это нужно. Желательно чтобы это были и топы, и обычные  разработчики.

Масштабируемость!
Вот что не даёт мне покоя после просмотра этого доклада. Как разрабатывать проекты и программы с учётом этой характеристики? И возможно ли это вообще, учитывая специфику тех задач, с которыми мы работаем?
Мы тратим много сил и ресурсов, а ведь наверняка можно иначе и эффективнее. Правда, поменять нужно не только свою работу, но и видение и подходы компании в целом.
https://youtu.be/y2GKAjMpO5s

В своих проектах я использую такой инструмент, как привоз "звёзд" - гуру или даже просто известных специалистов в своей области. Такой приём я могла бы посоветовать не только крупным компаниям, но даже совсем небольшим, если есть бюджет.
Это даёт возможность заявить, что компания работает в определённой сфере, вкладывается в индустрию, создаёт условия не только своим, но и внешним специалистам встречаться и профессионально общаться с мировыми гуру в своей области.
Подробнее о возможностях, примерах и особенностях работы пишу здесь “Встречи со звёздами” by Natalia Makarova https://link.medium.com/beGC9HKiFW

​​КАК ОРГАНИЗОВАТЬ СООБЩЕСТВО
Очень хороший курс о комьюнити органайзинге, который помог мне структурировать знания и ответил на открытые вопросы.
Для меня лично было полезно:
- структурировать знания о построении сообщества и разработке стратегии;
- как построить команду, которая будет мотивирована активно участвовать в жизни сообщества и вкладываться своими временем и ресурсами;
- как делегировать и работать с волонтерами;
- поучиться писать вдохновляющие истории, чтобы мотивировать людей.

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

Поэтому положу ссылку сюда https://vector.education/course/11

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

А вот и этот самый рассказ про поиск данных о целевой аудитории.
Я постаралась вспомнить и описать всё. Но, если у вас все же есть вопросы к посту или по мобильщикам, то с радостью отвечу. А ещё буду рада идеям и даже критике 😇

“В поисках данных или как посчитать всех разработчиков” by Natalia Makarova https://link.medium.com/TjZPrCfPdX

​​Рассматривая аналитический отчет о devrel State of Developer Relations 2019 от компании Hoopy (большинство из вас, уверена, получают от них регулярную рассылку), мое внимание обратили на себя некоторые пункты.
Что меня удивило:
✅ Если раньше devrel службы были прерогативой технологических компаний, то теперь выделяется и растет доля компаний других профилей (финансы, телеком, бытовая техника и т.д.). Эта тенденция есть и в России, судя по чату DevRel.
✅ Была уверена, что службы devrel локализованы в технологических департаментах. А оказывается, большинство все же в маркетинге или автономны, подчиняясь CEO. Так или иначе разработчики рассматриваются как основная целевая аудитория для продажи технологического продукта или работы с ним.
✅ Нигде в отчете не идет речи о HR брендинговых целях. Таким образом, в мире devrel - это про взаимодействие с разработчиками для развития, продвижения и продажи тех.решений. Это наводит меня на мысль, что Employer brand все же дело департаментов HR.
✅ Любопытно, что наиболее популярный канал взаимодействия - ивенты и конференции, но при этом, самым эффективным назван контент-маркетинг :)
✅ А вот среди названных вызовов и сложностей я сталкивалась почти со всеми: от того, как увеличить комьюнити и базы до доказывания внутри, что мы являем реальную ценность и влияем на бизнес.

А вы уже читали эту брошюру https://bit.ly/2KvDYnK? Какие выводы для себя сделали?

⁉️Как вы относитесь к участию в конференциях со стендом?
Лично у меня очень противоречивое отношение.
Конференции - неотъемлемая часть работы devrel менеджера, но, если с эффективностью докладов более или менее понятно, то со стендами всегда возникают сложности. Такое участие очень затратно: приобретение спонсорского пакета, места под стенд, производство стенда, подготовка раздаточных материалов и разработка контента для вовлечения аудитории, обучение сотрудников, оплата участия и командировок и т.д. - набегает очень солидная сумма и комплекс затрачиваемых ресурсов. А в результате бывает сложно оправдать эффективность даже для себя. Особенно, когда речь идет о маркетинговых целях.
❇️Слагаю пост на эту тему, но хочется узнать еще мнения и вопросы. Пока в посте будет:
- цели компаний и цели конференций
- на что обращаю внимание при выборе конференций
- стенды по типу контента
- метрики эффективности

Вопросы и мнения пишите в личку @NataMakarova. Спасибо!

❓Нужен ли деврелу технический бэкграунд?
Моё мнение, все зависит от задач, которые стоят перед специалистом.
Developer Relations стОит рассматривать как общее направление работы с технологической аудиторией. А далее идёт разделение на адвокатов, евангелистов, технических писателей, менеджеров комьюнити/ивентов/программ/
проектов и др.
Таким образом, если это про организацию процессов взаимодействия с технической аудиторий, как то:
- разработка стратегии продвижения;
- организация митатов, конференций;
- создание сообществ;
- подготовка спикеров к выступлениям;
- построение каналов коммуникации;
- организация участия компании с докладами, стендами и др.активностями во внешних конференциях и т.д., то технические скилы совсем не обязательны. Это скорее полезное дополнение. Здесь важнее уметь задавать правильные вопросы правильным специалистам, заручиться поддержкой сильных специалистов продвигаемых технологий, видеть харизму в потенциальных спикерах, вдохновлять, анализировать, сегментировать, писать, поддерживать коммуникации. А умение программировать может быть плюсом, но никак не обязательным условием.
Но знание технологий определённо необходимо, если задача подразумевает непосредственное взаимодействие с целевой аудиторией. Адвокаты и евангелисты должны хорошо знать технологию, которую представляют, уметь отвечать на все вопросы относительно особенностей продукта и его разработки. Как правило, разработчики больше доверяют именно тем, кто непосредственно создаёт продукт и знает все детально.

"Люди всякие нужны, люди всякие важны..."
Я считаю, что тот, кто создаёт технологию на уровне кода, не должен отвлекаться на организационные вопросы. Достаточно с него того, что он готовит контент, представляет его в статье или в документации, дежурит в канале поддержки, развививает свои навыки докладчика. В то время как на менеджерах лежит ответственность за поиск целевой аудитории и то, как до неё достучаться, за создание каналов взаимодействия, за решение организационных вопросов, за создание положительного микроклимата для всех участников процесса.
❓А у вас есть тех.знания и скилы?